Using OpenVPN only for specific applications

November 29, 2013 8:51 PM

I have a working PPTP VPN with very specific routing requirements that I need to replace with OpenVPN due to issues with our ISP, and I am having issues adapting my Linux routing table rules to OpenVPN.

I only want to use the VPN in very specific circumstances:

1. To respond to inbound VPN traffic through the VPN interface (instead of through the default gateway.)
2. To only send outbound traffic through the VPN interface when applications explicitly bind to the VPN interface.
3. To do these regardless of the source/destination IP address - there are no static routes.

Basically, there is one application I wrote that needs to send all traffic via the VPN, and everything else on the server should use the default gateway for performance reasons.

I am running Linux, and have a separate routing table created in /etc/iproute2/rt_tables called "vpn". The routing rules I am using to make this work with my current PPTP VPN are added by a script in /etc/ppp/ip-up.d:

#!/bin/bash
ip route add default via $PPP_REMOTE dev ppp0 table vpn
ip rule add from $PPP_LOCAL/32 table vpn
ip rule add to $PPP_LOCAL/32 table vpn

This allows me to send and receive traffic correctly on both my ppp0 and eth0 interfaces when I specify them explicitly, evidenced by the following test (normally one would fail because of the default route):

ping -I eth0 google.com
ping -I ppp0 google.com

The problem is that the above routing rules do not seem to work with OpenVPN. I set "route-noexec" in my OpenVPN client config and use a custom "up" script that does the following:

#!/bin/bash
ip route add default via $route_vpn_gateway dev tun0 table vpn
ip rule add from $ifconfig_local/32 table vpn
ip rule add to $ifconfig_local/32 table vpn

The variables resolve correctly to the OpenVPN-provided IP addresses (and I've also tried setting them manually to verify), but no traffic is being routed or responded to through tun0 using the previous ping test.

Is there something fundamentally different about how PPTP and OpenVPN handle routing that I'm not taking into account? How can I configure OpenVPN routing to meet my needs? Note that I do not have control of the OpenVPN server, just the client.

posted by chundo to Technology (4 answers total)

Best answer: Only half sure about this, I use something similar for a multi-homed server. The things that stick out in your configuration (maybe). I think the PPTP worked because it was point-to-point while the vpn is probably on a subnet, and you don't have a forwarding rule for the subnet, but I may just have read different instructions for the fancy-dancy routing.

ip route flush table 1 # em1
ip route add 192.168.88.64/27 dev em1 table 1
ip route add default via 192.168.88.65 dev em1 table 1
ip rule add from 192.168.88.68/32 table 1 priority 2
ip route flush cache

Since your tun0 is probably something like 5.5.12.8/255.255.252.0 gw 5.5.12.1 you might need to add the subnet route.

Not sure why you need a 'ip rule add to ...'

Your #3 sounds weird: regardless of the source/destination IP address
Do you really mean sending packets with a source address that's different than your end of the vpn? Spoofing?

You might be running into the Linux evil where it answers ARP for all IPs on the machine on all interfaces (but I don't know why this wouldn't affect PPTP as well).

# fix nasty linux answers ARP for all IPs on all interfaces.
echo 1 > /proc/sys/net/ipv4/conf/em1/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/p1p1/arp_ignore
posted by zengargoyle at 12:15 AM on November 30, 2013

Response by poster: At first this was a forehead-slapper because I realized I did not actually route the gateway subnet over tun0. But after looking at it that appears to be the one piece OpenVPN was still setting up itself despite route-noexec, and having added it explicity I still get no response.

If remove "route-noexec" from my config and let OpenVPN be the default for everything, tun0 works fine, so I know it is just my routing configuration that is the problem. If you want to take a closer look, here's a buncha Gists with additional details, this really has me stumped:

OpenVPN client config

ifconfig tun0 (after OpenVPN connect)

Results of my routing attempts

OpenVPN env variables available to "up" script

/etc/iproute2/rt_tables

There is one error in the third Gist that I can't figure out why it is happening, and it may be the root of all my problems:

# ip route add default via 46.246.33.1 dev tun0 table vpn
RTNETLINK answers: No such process

posted by chundo at 2:04 PM on November 30, 2013

Response by poster: Changing the subnet routing to the line below gets rid of the gateway error mentioned above (guess I need to route the subnet in the main table so it could find the gateway in the first place!), but still no joy on the tun0 ping:

# ip route add 46.246.33.0/24 dev tun0
posted by chundo at 2:16 PM on November 30, 2013

Best answer: Tracked it down based on your info and some more googling. Here's my final routing command list:

ip route add 46.246.44.0/24 dev tun0 table vpn
ip rule add to 46.246.44.1 table vpn
ip rule add from 46.246.44.218 table vpn
ip route add default via 46.246.44.1 dev tun0 table vpn

It appears the important missing piece was #2: ip rule add to [gateway] table vpn.
posted by chundo at 2:57 PM on November 30, 2013