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.

gparent
  • 3,561
  • 2
  • 23
  • 28
  • 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 03 '13 at 06:53
  • The point is that I want to encrypt the traffic between two hosts, the gateway *is* the network I'm bridging. – gparent Apr 03 '13 at 07:27

2 Answers2

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

pupkinsen
  • 113
  • 2
  • 10
  • 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 03 '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 03 '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 04 '13 at 04: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 05 '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.

the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • 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 03 '13 at 07: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 03 '13 at 08: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 03 '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 03 '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 03 '13 at 15:45
  • I'll give it another thought if I can't get it to work, but unfortunately the only alternative is IPSec and one of the machine's kernel doesn't support it (OpenVZ VPS). If I really can't get it to work, I'll stick to having two sets of IPs but it's really annoying. I have a dev environment, so I don't need to test this in production. – gparent Apr 03 '13 at 17:55