1

I want to connect two servers to eachother over the internet. For various reasons I cannot use IPSec for this.

I would like traffic to be transparently encrypted as if I was using IPSec transport mode. I have decided to use routing for this (but I'm open to better alternatives)

My tunnel is up on 10.255.255.0/30, A uses .1, B uses .2. Let's say server A is at 192.168.0.100 and server B 172.16.0.200.

While I could add a route to encrypt all traffic (using on A ip route add 172.16.0.200/32 dev tun0 via 10.255.255.2), doing so kills the tunnel because OpenVPN traffic is using the same remote IP to keep the tunnel up.

I need a way to route the actual OpenVPN tunnel through eth0 but otherwise use tun0 to carry all traffic between server A and B. I have ip_forward enabled on both servers and appropriate firewall rules to allow the traffic, but I am not sure where to start in iptables to accomplish this.

  • There is either a typo in your question or a misunderstanding about routing - ip route add 172.16.0.200/32 is adding a host route to your remote OpenVPN gateway (so it is a route to the gateway only) through the tunneling interface. Which does not make any sense and as you have noted does not work out. – the-wabbit Apr 3 '13 at 6:53
  • The point is that I want to encrypt the traffic between two hosts, the gateway is the network I'm bridging. – gparent Apr 3 '13 at 7:27
3

I guess what you need is an additional routing table for all traffic between 2 hosts except openvpn. You may try something like this:

iptables -t mangle -A OUTPUT -d 172.16.0.200/32 -p <vpn_protocol> ! --dport <vpn_port> -j MARK --set-mark 2

ip route add default via 10.255.255.2 dev tun0 table 2

ip rule add fwmark 2 table 2

on either side of your tunnel

| improve this answer | |
  • Unfortunately this doesn't work. I see the packets are getting marked but the output interface is still eth0 on the filter table, and no packets reach my other box. Is it possible that my kernel may not support routing based on the ip rule ? Your solution matches with what I find using Google, but packets fail to be transmitted when I use it. – gparent Apr 3 '13 at 17:54
  • By the way, I did my testing by marking only ICMP packets and attempting to ping the remote box. – gparent Apr 3 '13 at 17:59
  • Try to add an explicit route to your remote box. ip route add 172.16.0.200/32 via 10.255.255.2 dev tun0 table 2 – pupkinsen Apr 4 '13 at 4:15
  • Still doesn't work. I'll mark your answer as accepted because you're on the right track and either way I managed to change my OpenVZ host to Xen (so ipsec is no longer a problem) – gparent Apr 5 '13 at 18:48
1

You should add a route to the remote network through the tunneling interface and a more specific route ensuring that your traffic to the remote OpenVPN gateway is not sent via the tunnel interface. Example:

ip route add 192.168.0.0/24 via 10.255.255.2 dev tun0
ip route add 192.168.0.100 via 172.16.0.1 dev eth0 

The first ip route is adding a route to the destination network while the second ip route is adding a host route to the OpenVPN gateway located in the same network. 172.16.0.1 is the gateway with a valid route to 192.168.0.100 and eth0 is the local interface connecting to the same network as the gateway. Note that the first ip route would be unnecessary if you have configured OpenVPN with route and push "route ..." statements as it would be added by the OpenVPN daemon upon startup / successful connection setup.

| improve this answer | |
  • The idea here is that the traffic I want to encrypt is the one sent to the VPN gateway, so I can't have a more specific route. I'm trying to find a way around that. Would otherwise be a good answer though! – gparent Apr 3 '13 at 7:29
  • This is a good answer, indeed, and I would suggest you follow it. If you can't though, in your particular case, you will need to set some policy routing (which I personally tend to avoid, as a matter of principle). See @pupkinsen answer for an example. – zorlem Apr 3 '13 at 8:42
  • @gparent in this case you simply should not reference the host addresses from the 192.168.0.0/24 and 172.16.0.0/24 networks but the OpenVPN-assigned addresses within the 10.255.255.0/24 network for communication. OpenVPN's routing is quite different from what you got used to from the Open/FreeSWAN implementations. The most notable advantage being that it is very easy to differentiate between encrypted and unencrypted traffic by interface and nexthop. You should not try to force OpenVPN into the OpenSWAN routing paradigm. – the-wabbit Apr 3 '13 at 15:32
  • But I don't want to have to use a special IP address. Are you telling me I should be using bind views instead? Also, there is no 172.16.0.0/24 and no 192.168.0.0/24 either. Note that I have yet to try the policy routing example, will do so tonight. – gparent Apr 3 '13 at 15:35
  • @gparent policy routing will do it for you then. But I am still not convinced that "I do not want" warrants the added complexity and a new technique yet unemployed in your network. Especially with security-relevant topics complexity is a toxic component and its risks have to be carefully weighted against the benefits of the features it brings, so you should give it another thought. – the-wabbit Apr 3 '13 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.