2

I have a server hosting multiple bridged (i.e. tap) VPNs using openvpn, where each VPN has a different 10.8.X.0/24 subnet.

I wish to redirect traffic sent to a specific, unallocated IP address (e.g. 10.8.X.254) in each VPN to a fixed address on a different VPN (e.g. 10.8.1.10). The aim of this is to keep the client configuration relatively clean (i.e. it knows that certain traffic always goes to address 254 on its own subnet) by keeping the bulk of the routing configuration on the VPN server and also making it easier to modify the destination IP in the future.

Firstly, on the VPN server, I enabled IP forwarding in the kernel with

echo 1 > /proc/sys/net/ipv4/ip_forward

I then tried to set up NAT redirection using iptables on the VPN server for each VPN with e.g.

sudo iptables -t nat -A PREROUTING -s 10.8.2.0/24 -d 10.8.2.254 -j DNAT --to-destination 10.8.1.10

But ping requests to 10.8.2.254 from within the VPN fail with Destination Host Unreachable and the following network traffic is reported by tshark on the server's VPN interface

6.943311    10.8.2.12 -> 10.8.2.1     SSH 274 Encrypted response packet len=208
6.943347     10.8.2.1 -> 10.8.2.12    TCP 66 42926 > ssh [ACK] Seq=97 Ack=625 Win=563 Len=0 TSval=3930766820 TSecr=80207294
6.959100 9e:10:2c:67:91:2a -> Broadcast    ARP 42 Who has 10.8.2.254?  Tell 10.8.2.12
7.983824 9e:10:2c:67:91:2a -> Broadcast    ARP 42 Who has 10.8.2.254?  Tell 10.8.2.12

Which seems to suggest that the server doesn't know where to send the traffic, even though I have configured the redirection rule as above.

I thought that perhaps I should instead / also be configuring the routing through the VPN setup, but was unable to work out how to go about this for a system containing multiple, bridged VPNs; all VPN-specific information that I could find related to redirecting traffic was based on routed (tun) VPNs.

I wanted to avoid the solution of adding the destination host into each VPN, as this would get increasingly complicated when the number of VPNs hosted by the VPN server, and, eventually, the number of VPN servers increase.

tom-hd
  • 78
  • 5

1 Answers1

3

10.8.2.12 sees 10.8.2.254 as being on the same subnet, therefore it's requesting the MAC address of 10.8.2.254 to insert it as a dest MAC in future packets to 10.8.2.254. Since 10.8.2.254 doesn't exist, no one is replying and 10.8.2.12 never finds out what MAC to set as the dest MAC.

Try using proxy_arp on your main server. echo 1 > /proc/sys/net/ipv4/conf/ethXX/proxy_arp

Running tcpdump you should then see the VPN server respond to ARP queries for 10.8.x.254 with its own MAC address, which should get you a step further.

lionel
  • 46
  • 1
  • worth mentioning that you might have to add a null route (route add -host 10.8.2.254 gw 127.0.0.1 lo) for 10.8.2.254 on your vpn server (that'd be the cisco behaviour for proxy_arp, I'm not sure if Linux would answer a proxy_arp request without having a MAC for the queried IP) -- still, that would only require a change on your VPN server and no change on the client (that's what you want if I understand correctly) – lionel May 07 '14 at 16:45
  • This does indeed get me a step further, thanks (I replaced 'ethXX' with the relevant tap interface name). The ARP requests no longer fail and the ping requests get to the server. Once there they are successfully following the NAT rule (indicated by pkts / bytes columns in iptables) and then through the relevant FORWARD rules. – tom-hd May 08 '14 at 11:31