Can connect to VPN but can't ping clients behind the VPN

dadio

Hi,

I'm struggeling a wile now whit this problem. I can't find the problem. Can somebody help?
I can connect from my home office to the VPN-server at work but I can't ping anny ip behind the VPN-server.

Lets say the IP of my vpn-server at work is 10.3.1.173...

On my home office I can ping 10.3.1.173 but not a server at work, lets say 10.3.1.1
I can connect to the VPN-server through the VPN connection with ssh by 'ssh -C -X -l loginname 10.3.1.173'

On my VPN-server I can ping every client at work.

Some data:
VPN server is an Ubuntu on a VMware server. The host is a Windows server 2008.
The Clients are Ubuntu, Windows XP, Windows 7; All have the same problem.

server.conf:

mode server
port 1194
proto udp
dev tap0
up "/etc/openvpn/up.sh br0 tap0 1500"
down "/etc/openvpn/down.sh br0 tap0"
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt 
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.3.1.173 255.255.255.0 10.3.1.239 10.3.1.254
push "dhcp-option DNS 10.3.1.1"
push "dhcp-option WINS 10.3.1.1"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 6

My client.conf:

    client
    dev tap
    proto udp
    remote 84.199.45.138 1194
    float
    resolv-retry infinite
    nobind
    persist-key
    persist-tun
    ca /home/dadio/Bureaublad/dra/ca.crt
    cert /home/dadio/Bureaublad/dra/dra_thuis.crt
    key /home/dadio/Bureaublad/dra/dra_thuis.key
    comp-lzo
    verb 3

ifconfig on the VPN-server:

br0       Link encap:Ethernet  HWaddr 00:0c:29:1c:b9:0b  
          inet addr:10.3.1.173  Bcast:0.0.0.0  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe1c:b90b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:40975 errors:0 dropped:71 overruns:0 frame:0
          TX packets:26640 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:42210912 (42.2 MB)  TX bytes:3244768 (3.2 MB)

eth0      Link encap:Ethernet  HWaddr 00:0c:29:1c:b9:0b  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:78424 errors:0 dropped:8 overruns:0 frame:0
          TX packets:25273 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:50339502 (50.3 MB)  TX bytes:2945434 (2.9 MB)
          Interrupt:18 Base address:0x2000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3400 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3400 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:850275 (850.2 KB)  TX bytes:850275 (850.2 KB)

tap0      Link encap:Ethernet  HWaddr d6:4b:3f:4d:bd:c0  
          inet6 addr: fe80::d44b:3fff:fe4d:bdc0/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:2480 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5064 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:287998 (287.9 KB)  TX bytes:594724 (594.7 KB)

ifconfig on my (ubuntu)client:

eth0      Link encap:Ethernet  HWaddr 00:19:db:f7:ec:54  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:28 Base address:0xa000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2693 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2693 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:398763 (398.7 KB)  TX bytes:398763 (398.7 KB)

tap0      Link encap:Ethernet  HWaddr ee:f8:ae:23:c9:0f  
          inet addr:10.3.1.240  Bcast:10.3.1.255  Mask:255.255.255.0
          inet6 addr: fe80::ecf8:aeff:fe23:c90f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7811 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2838 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:826281 (826.2 KB)  TX bytes:338320 (338.3 KB)

wlan0     Link encap:Ethernet  HWaddr 00:1d:7e:05:eb:c0  
          inet addr:192.168.1.101  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:7eff:fe05:ebc0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:72273 errors:0 dropped:0 overruns:0 frame:0
          TX packets:72529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:54813083 (54.8 MB)  TX bytes:10950453 (10.9 MB)

Thanks in advance...

janjust

is ip forwarding enabled on the VPN server?
do clients on the server-side LAN know that when packets arrive from the 10.3 subnet that traffic should be sent back to the VPN server? or does the server-side LAN GW have a (static) route for this subnet?

dadio

janjust wroteis ip forwarding enabled on the VPN server?
do clients on the server-side LAN know that when packets arrive from the 10.3 subnet that traffic should be sent back to the VPN server? or does the server-side LAN GW have a (static) route for this subnet?

It's just a simple bridged connection according to http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

I've used it before and it worked perfectly.

The clients doesn't have to know anything. The vpn server just acts as a ethernet switch. Anyway, it should 🙁

On the server-side, my ip-tables are set to pass everything, not?

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

If also tried the iptable setting in the above link:

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

afterwards restarting the vpn, but no improvement. It is normal because my standard policy is 'accept'...

This configuration was so great. A simpel installation on the remote client and the user was working on our company network as if they were right here...

edit (10:11): Can it be possible the client openvpn version is to low? Server version is 2.2.0 and client version is 2.1.0...

janjust

I've used it before and it worked perfectly.

was that also on a VMware guest? or physical hardware? Virtual machines and bridging can cause problems...

dadio

It's the same physical server with the same VM software, only de guest OS is a newer version. I think last time the openvpn was installed on a Ubuntu 10.04. The OS was updraded a while ago to the latest release.
Last night I've build a fresh install, in case it has something to do with the dist-upgrade. If I have time today, I'll try to test the VM today, but I'm not realy convinced it wil make a difference.
Anny way, I'll post the result when I'm done...

dadio

I did a clean installation of the Ubuntu OS and installed Openvpn.

I've copied the configuration files.

The VPN works but still I cannot ping from a remote host to the network behind the vpn-server.

Does any one have a idea what I can do to resolve this issue?

janjust

run 'tcpdump -nnel -i br0' on the VPN server to see if the packets are forwarded out the right interface; also , try tunning something like tcpdump on wireshark on a PC behind the server (e.g. on the VM host) and watch for packets coming in from the VPN client.

dadio

If I capture the tcp-dump with a 'ping 10.3.1.1' on the remote client (10.3.1.240), I get this:

18:34:23.535556 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 22284, seq 22, length 64
18:34:23.535795 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 22284, seq 22, length 64
18:34:23.536085 00:23:7d:32:a8:3a > a2:de:15:08:97:22, ethertype IPv4 (0x0800), length 98: 10.3.1.1 > 10.3.1.240: ICMP echo reply, id 22284, seq 22, length 64

The ping is send and the reply is received by the vpn-server...

The tcp-dump on the remote client is:

19:08:10.263039 00:c0:b6:22:80:6c > 01:00:5e:03:04:05, ethertype IPv4 (0x0800), length 275: 10.3.1.11.2599 > 224.3.4.5.2599: UDP, length 233
19:08:10.278121 00:c0:b6:22:80:6c > 01:00:5e:03:04:05, ethertype IPv4 (0x0800), length 275: 10.3.1.11.2599 > 224.3.4.5.2599: UDP, length 233
19:08:10.926661 00:1a:4d:69:1f:bf > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.8 tell 10.3.1.174, length 46
19:08:11.372860 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:11.973959 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:12.426583 00:1a:4d:69:1f:bf > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.8 tell 10.3.1.174, length 46
19:08:12.455949 00:23:7d:32:a8:3a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.169 tell 10.3.1.1, length 46
19:08:12.525654 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 1, length 64
19:08:13.002340 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:13.533981 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 2, length 64
19:08:13.942012 00:1a:4d:69:1f:bf > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.8 tell 10.3.1.174, length 46
19:08:14.108719 00:19:99:18:6f:d8 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.11 tell 10.3.1.149, length 46
19:08:14.407948 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:14.541969 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 3, length 64
19:08:15.069460 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:15.549979 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 4, length 64
19:08:16.101915 00:21:5a:af:1d:9e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.175 tell 10.3.1.13, length 46
19:08:16.164367 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:16.173585 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:16.557967 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 5, length 64
19:08:17.171619 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:17.178217 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:17.523886 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype ARP (0x0806), length 42: Request who-has 10.3.1.1 tell 10.3.1.240, length 28
19:08:17.565966 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 6, length 64
19:08:18.166265 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:18.171323 00:0c:29:1c:b9:0b > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 10.3.1.137 tell 10.3.1.173, length 46
19:08:18.523886 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype ARP (0x0806), length 42: Request who-has 10.3.1.1 tell 10.3.1.240, length 28
19:08:18.573951 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype IPv4 (0x0800), length 98: 10.3.1.240 > 10.3.1.1: ICMP echo request, id 35854, seq 7, length 64
19:08:19.523887 a2:de:15:08:97:22 > 00:23:7d:32:a8:3a, ethertype ARP (0x0806), length 42: Request who-has 10.3.1.1 tell 10.3.1.240, length 28

Am I right, the vpn-server doesn't send the ICMP echo reply back to my remote client?

And now?

edit:
I just remembered that I still had a copy of the image of the vpn-server from a year ago. Guess what? If I started that vpn-server, I couldn't reach the company network neither...
I 100% shore the copy was made when the vpn-server was in use. So it's not a problem with Openvpn!!

I guess it's a setting on the host server of my VM. Difficult problem :cry:

Does any body know if there is a setting on a windows server what can cause this problem? Maybe in combination with the VMware server?

If nothing else comes out of this tread... Thanks for your input Janjust!

Mimiko

In VMware its important the virtual network configuration. Not all options are suitebl with VPN installations. Try this approach: http://communities.vmware.com/thread/37024 and search this site for additional answers.