Koozali.org: home of the SME Server

Using OPENVPN

Offline hanscees

  • *
  • 267
  • +0/-0
    • nl.linkedin.com/in/hanscees/
Using OPENVPN
« Reply #15 on: April 05, 2006, 12:00:06 AM »
Quote from: "pcdoc"
maybe more information is required as well.

server a > > router > > internet > > router > > server b
192.168.59.222 / 192.168.5.3 > > 192.168.5.1 / xx.xx.xx.xx > > xx.xx.xx.xx / 192.168.3.1 > > 192.168.3.20 / 192.168.60.222

tunnel should be
192.168.59.222 / 192.168.0.1 > > 192.168.0.2 / 192.168.60.222

does this make the previous post make more sense??


You need to have two routes across the tunnel then. For the 192.168.5.0/24 and the 192.168.69.0/24. Both to the 192.168.0.2 gateway acrosse the tunnel.
nl.linkedin.com/in/hanscees/

jaydub

Unable to connect to machines behind openvpn server
« Reply #16 on: April 06, 2006, 07:11:38 PM »
I followed the sme7 tutorial for linking two sme7 servers with openvpn as told here: http://hanscees.com/sme7/openvpnsitetositetunnelsme7.html

I am able to ping from either the sme gateway/openvpn server to the client and vice versa. I am unable to ping from any machines on the server's internal network to machines on the client's internal network. Same holds for the reverse.

Conf files are:

server.conf

remote 219.142.220.16
ifconfig 10.4.0.1 10.4.0.2

proto udp
port 1194

dev tun
tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key

comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (server side)

route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.4.0.2
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


client.conf

remote 219.142.219.48 1194
ifconfig 10.4.0.2 10.4.0.1

proto udp
dev tun
tls-client
dh dh1024.pem
ca ca.crt
cert client.crt
key client.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (client side)

route add -net 192.168.3.0 netmask 255.255.255.0 gw 10.4.0.1

iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Both client and server can ping the remote gateway both eth0 and tun0 addresses. But any clients whether windows or linux on either side cannot ping other machines across the vpn.

specifically we are looking to allow machines on the client network to be able to access one machine on the server network via SMB.

any advice on where to start looking? We suspect it may be due to the iptables rules in sme7rc1 but are not really sure where to look.

-Jeff

Offline hanscees

  • *
  • 267
  • +0/-0
    • nl.linkedin.com/in/hanscees/
Re: Unable to connect to machines behind openvpn server
« Reply #17 on: April 06, 2006, 11:21:16 PM »
Quote from: "jaydub"
I followed the sme7 tutorial for linking two sme7 servers with openvpn as told here: http://hanscees.com/sme7/openvpnsitetositetunnelsme7.html

I am able to ping from either the sme gateway/openvpn server to the client and vice versa. I am unable to ping from any machines on the server's internal network to machines on the client's internal network. Same holds for the reverse.

Conf files are:

server.conf

remote 219.142.220.16
ifconfig 10.4.0.1 10.4.0.2

proto udp
port 1194

dev tun
tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key

comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (server side)

route add -net 192.168.4.0 netmask 255.255.255.0 gw 10.4.0.2
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


client.conf

remote 219.142.219.48 1194
ifconfig 10.4.0.2 10.4.0.1

proto udp
dev tun
tls-client
dh dh1024.pem
ca ca.crt
cert client.crt
key client.key
comp-lzo
user nobody
group nobody
daemon
keepalive 10 60
ping-timer-rem

up ./openvpn.up

persist-tun
persist-key
status-version 2
status /var/log/openvpn/openvpn-status.log
verb 3

openvpn.up (client side)

route add -net 192.168.3.0 netmask 255.255.255.0 gw 10.4.0.1

iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -p udp --sport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -p icmp -j ACCEPT
iptables -A OUTPUT -o tun+ -p icmp -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT


Both client and server can ping the remote gateway both eth0 and tun0 addresses. But any clients whether windows or linux on either side cannot ping other machines across the vpn.

specifically we are looking to allow machines on the client network to be able to access one machine on the server network via SMB.

any advice on where to start looking? We suspect it may be due to the iptables rules in sme7rc1 but are not really sure where to look.

-Jeff


Hi,

could you check if the routing is ok on both servers when the tunnel is up:
netstat -r
and post that back?

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?
nl.linkedin.com/in/hanscees/

jaydub

Using OPENVPN
« Reply #18 on: April 12, 2006, 02:25:37 PM »
Quote

Hi,

could you check if the routing is ok on both servers when the tunnel is up:
netstat -r
and post that back?

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?


Server A (Server) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     10.4.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.4.0.0        192.168.3.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

Server B (Client) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0
10.4.0.0        192.168.4.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

If I run tcpdump on the server's internal interface ( I am assuming
the tunneling interface tun0 as there is no traffic visible on eth0
from the client network) I can see the attempts at pinging or trying to view SMB shares:

20:22:05.893588 IP 192.168.4.204.38714 > 192.168.3.2.microsoft-ds: S 1780914548:1780914548(0) win 5840 <mss 1366,sackOK,timestamp 29016041 0,nop,wscale 2>
20:22:16.459340 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 1
20:22:17.459759 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 2

etc...

ok so where do I go from here?

Offline hanscees

  • *
  • 267
  • +0/-0
    • nl.linkedin.com/in/hanscees/
Using OPENVPN
« Reply #19 on: April 12, 2006, 07:42:44 PM »
Quote from: "jaydub"
Quote

Can you post the outcome of
tcpdump -nlpi insideinterface
of server A when you ping from the network behind server B?


Server A (Server) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     10.4.0.2        255.255.255.0   UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.4.0.0        192.168.3.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

Server B (Client) Routing table

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.4.0.1        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0
10.4.0.0        192.168.4.1     255.255.255.0   UG    0      0        0 eth0
219.142.216.0   0.0.0.0         255.255.248.0   U     0      0        0 eth1
0.0.0.0         219.142.216.1   0.0.0.0         UG    0      0        0 eth1

If I run tcpdump on the server's internal interface ( I am assuming
the tunneling interface tun0 as there is no traffic visible on eth0
from the client network) I can see the attempts at pinging or trying to view SMB shares:

20:22:05.893588 IP 192.168.4.204.38714 > 192.168.3.2.microsoft-ds: S 1780914548:1780914548(0) win 5840 <mss 1366,sackOK,timestamp 29016041 0,nop,wscale 2>
20:22:16.459340 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 1
20:22:17.459759 IP 192.168.4.204 > 192.168.3.2: icmp 64: echo request seq 2

etc...

ok so where do I go from here?


Lets see if I got this right.
You ping from host 192.168.4.204 to 192.168.3.2.

192.168.4.204 is behind server b.
traffic arives at eth0 of server b. It is then routed into the tunnel, because of the route on server B:
192.168.3.0     10.4.0.1        255.255.255.0   UG    0      0        0 tun0

It then arives at tun0 at server a.
It should then go to eth0 becuase of route on ser er a:
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

But if you tcpdump on eth0 you see no traffic.

This very likely mean there is some iptables rule in the way.

Can you try on server A:
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT

and see if you now see traffic when tcpdumping eth0?
tcpdump -nlpi eth0

If that does not work we can also try:

iptables -A INPUT -i eth0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT

please let me know what, if anything, works.
nl.linkedin.com/in/hanscees/