OpenVPN & ARP

[alexandru.bujor]

Hello,

After cleaning up my firewall script I am experiencing some interesting behavior for the remote access performed using OpenVPN. Things go on like that:

- the client connects and everything seems to be OK (no timeout/no error)
- when I try to ping or ssh a LAN server from the remote machine, it fails.

I have tcpdump-ed the server's interface and I have discovered that it asks for the VPN client's MAC address through an ARP request. However, no machine answers and things stop there.
I write a python script that listens for ARP requests and answers to them if they are questioning about an address in the VPN client's range. It answers indicating router's (VPN endpoint) MAC.
While this script is running, things work well. I can connect to servers and I can ping from the remote VPN machine a LAN machine and reverse.

However, when I roll back to the old version of the firewall, the VPN is working normal without that script. By tcpdump-ing server's interface I have discovered that there is no arp association for a remote client even when I am connected, so there is no ARP request-reply exchange.

My question is the following one: which is the normal OpenVPN behavior? Should arp reply-requests (for the remote VPN address) be exchanged when communicating between one LAN and one VPN computer?

Thanks,
Alex

[maikcat]

hi there,

can you please tell us more info about your setup?

(os used,openvpn configs,firewall configs etc.)

michael.

[alexandru.bujor]

The OpenVPN server is installed on a Red Hat 5.4 and the client is running Ubuntu 10.04. The firewall is composed by some IPTABLES rules.
This is the openvpn.conf file:

proto tcp
dev tun

ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret

crl-verify crl.pem

dh keys/dh1024.pem

server 10.21.4.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 10.21.0.1"
push "dhcp-option DOMAIN xxx"
push "route 10.21.0.0 255.255.255.0"
push "route 10.21.1.0 255.255.255.0"
push "route 10.21.2.0 255.255.255.0"
push "route 10.21.3.0 255.255.255.0"
push "route 10.21.5.0 255.255.255.0"
push "route 10.21.8.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo

persist-key
persist-tun

status openvpn-status.log
log openvpn.log

I suspect that it is a firewall (which I cannot reveal) issue, but I am curios about the default (normal) behavior of the ARP messages exchanged by router and internal servers.

[maikcat]

hi there,

is ip forwarding enabled on redhat 5.4? selinux is active?

your client receives all routes?


michael.

[alexandru.bujor]

Yes, forwarding is enabled and SELinux is disabled. I have no problem with the VPN as long as that script that sends arp replies is running on one of the machines in the LAN. The router worked perfectly until I have changed the firewall, which makes me believe that this is the problem, but I've heard that it is also possible be a problem caused by iptables itself. But first I need to clarify why with one version of the firewall VPN works with arp requests-reply and on the other one it works without those mechanisms.

Thanks,
Alex

[janjust]

on a tun-based VPN ARP requests are generally not used - ARP requests from the LAN stop at (and should be answered by) the VPN LAN IP, ARP requests from the VPN client stop at the VPN IP (IIRC). As long as the VPN server itself replies on the ARP request all should work well.
If you are using a TAP-based setup, forwarding ARP requests DO become important.
On the server, check the arp & proxy arp entries in /proc/sys/net/ipv4/conf/*