How does OpenVPN determine the WAN adapter

RobMeades

I am trying to run an OpenVPN client, out of which most of my traffic is routed, along with an OpenVPN bridge for a specific subnet. These work separately but as soon as I bring up the OpenVPN client the OpenVPN bridge stops working. As I have two routes out to the big wide world (the OpenVPN client and my WAN adapter), I would like to understand how OpenVPN determines which adapter to write outgoing traffic to.

Can anyone help me on this, or point me to a reference? I can't see anything obvious in my .ovpn files (which were written largely automagically by Tomato).

Rob

RobMeades

Note: I have seen the "local" directive but that specifies only an IP address which doesn't help as mine aren't static.

mwandelaar

I don't think openvpn does this for you (i'm not a programmer, nor do i know the sourcecode!). This is the job of the network-stack, which routes packets the right way.
Only on redirecting the gateway, openvpn requests the default gateway and adds a static route to the openvpn-server via the default gateway.

RobMeades

OK, if it is not possible to tie OpenVPN to an adapter I'll have to use a Dynamic DNS service to tie down my real WAN IP address and use the "local" directive with that. It seems less intuitive though: OpenVPN is behind a tun already, being able to specify which interface it then stuffs the packets down seems like a natural thing to be able to do.

TinCanTech

RobMeades wroteI would like to understand how OpenVPN determines which adapter to write outgoing traffic to

Currently, this is the status of your enquiry.

Generally, binding to all local IP addresses (without --local) is sufficient for most servers.

OTOH, generally servers are deemed to have static IP addresses which means you can bind to that local IP address regularly.

However,

RobMeades wroteI am trying to run an OpenVPN client, out of which most of my traffic is routed, along with an OpenVPN bridge for a specific subnet. These work separately but as soon as I bring up the OpenVPN client the OpenVPN bridge stops working.

the problem you are having is that the client instance changes the routing and that breaks the server.

We get this question quite regularly and the consensus of opinion is to use policy based routing.

RobMeades

Thanks, I see that it is being considered but is not something that OpenVPN can naturally do from where it sits in the architecture. My problem is that I can't see anything in the routing table that suggests that what I'm doing should not work. Here is the routing table when the OpenVPN bridge (server end) is not working (i.e. when the OpenVPN client through which most of my traffic is routed is active):

10.50.10.1 via 10.50.10.5 dev tun11
10.50.10.5 dev tun11  proto kernel  scope link  src 10.50.10.6
10.8.0.2 dev tun21  proto kernel  scope link  src 10.8.0.1
82.24.196.1 dev vlan2  scope link
46.166.188.241 via 82.24.196.1 dev vlan2
10.10.0.0/24 via 10.8.0.2 dev tun21
10.10.1.0/24 dev br0  proto kernel  scope link  src 10.10.1.1
82.24.196.0/22 dev vlan2  proto kernel  scope link  src 82.24.197.229
127.0.0.0/8 dev lo  scope link
0.0.0.0/1 via 10.50.10.5 dev tun11
128.0.0.0/1 via 10.50.10.5 dev tun11
default via 82.24.196.1 dev vlan2

...and here is the routing table when the OpenVPN bridge (server end) is working (i.e. the OpenVPN client is inactive):

10.8.0.2 dev tun21  proto kernel  scope link  src 10.8.0.1
82.24.196.1 dev vlan2  scope link
10.10.0.0/24 via 10.8.0.2 dev tun21
10.10.1.0/24 dev br0  proto kernel  scope link  src 10.10.1.1
82.24.196.0/22 dev vlan2  proto kernel  scope link  src 82.24.197.229
127.0.0.0/8 dev lo  scope link
default via 82.24.196.1 dev vlan2

In both cases the route to my OpenVPN bridge (10.8.0.1/10.8.0.2) and the route between the two LANs (10.10.1.0/24 is my local LAN, 10.10.0.0/24 is the bridge LAN) are present. I can't see a route that is more specific (and so higher up the precedence order) that would clash with them...?

The OpenVPN bridge is plainly up because the moment I stop the OpenVPN client everything begins working, there is no reestablishment delay, so I agree that it must be a routing problem, I just can't see the problem!

TinCanTech

RobMeades wrote My problem is that I can't see anything in the routing table that suggests that what I'm doing should not work

RobMeades wrote

0.0.0.0/1 via 10.50.10.5 dev tun11
128.0.0.0/1 via 10.50.10.5 dev tun11
default via 82.24.196.1 dev vlan2

See --redirect-gateway in The Manual v23x

RobMeades

So I guess you're saying that the VPN server that my OpenVPN client is connecting to is pushing redirect-gateway to me (I'm not doing this myself on the client); I need to launch the OpenVPN client with --route-nopull and then figure out for myself how to route everything to the OpenVPN client except the stuff that is meant to go over the OpenVPN bridge. I will read on...

RobMeades

My apologies, I still don't understand this. Surely those new entries in the list, 0.0.0.0/1 and 128.0.0.0/1, each having only one bit of subnet mask, are less specific than the bridged LAN IP address 10.10.0.0/24 with 24 bits of subnet mask, and so must come after it during IP route evaluation? What am I missing here?

RobMeades

I'm going to post a new, more specific, question on this topic as the title is now misleading.

RobMeades

TinCanTech wrote
RobMeades wrote My problem is that I can't see anything in the routing table that suggests that what I'm doing should not work
RobMeades wrote
0.0.0.0/1 via 10.50.10.5 dev tun11
128.0.0.0/1 via 10.50.10.5 dev tun11
default via 82.24.196.1 dev vlan2
See --redirect-gateway in The Manual v23x

I think I now understand what you mean, here it is in "long hand" for others who have the same problem:

An OpenVPN client on Router B establishes a connection to an OpenVPN server on Router A on the external interface of Router A that you specify, let's say for example it is the static public IP address allocated to Router A by the ISP (or some Dynamic DNS version of the same). In general, the way OpenVPN works is that it absorbs packets over a virtual interface (the "tun"), wraps them up in VPNness, and then drops them back into the kernel to be routed to the IP address of the far end of the VPN link. So when a VPN packet is created by OpenVPN on Router A, it will normally be routed out of the ISP interface of Router A to get to the public IP address of Router B on the internet, since that's what the routing table says. This is normally fine.

However, what if Router A has TWO external IP addresses? In my case Router A has the ISP interface and an additional interface, which is my Private Internet Access service, going off via another instance of OpenVPN. When this second interface is created it adds routes to Router A's routing table so that all internet traffic goes out via that interface. Hence the packets that OpenVPN creates, rather than going out through the ISP interface, will go out through the Private Internet Access interface. The problem, I think, is that the OpenVPN client running on Router B then doesn't receive this packet because it is coming from the wrong source IP address; it has set up a route to get things from a specific IP address, in my case the ISP IP address, so packets coming via the Private Internet Access IP address don't get where they should.

The obvious solution would be to get the OpenVPN server running on Router A to put things only down the "ISP" interface, which for me is vlan2. However, OpenVPN sits above a sockets interface in the Linux architecture, through which is it not possible to dictate the device it uses; this must be done instead using Policy Based Routing.

So I think I need to create a new routing table specifically for the source address of the OpenVPN tun on Router A (IP address 10.8.0.1 in my case), copy all the normal rules into that routing table but deleting the new routes created by the Private Internet Access OpenVPN client in the process. Then the stuff coming from that OpenVPN client will get to the right place. I think. :-)

TinCanTech

TinCanTech wroteWe get this question quite regularly and the consensus of opinion is to use policy based routing.

:roll:

RobMeades

I thought it could do with just a little more explanation as to what the problem was, since one needs to figure what policy to apply and doing that requires a technical understanding of how OpenVPN works :-).

TinCanTech

What you need to understand is routing priority and why --redirect-gateway routes over-ride your expectations. If you intend to pursue your current method I expect you will be frustrated.

There are some excellent books available to help:
https://openvpn.net/index.php/open-source/books.html

RobMeades

So I think I need to create a new routing table specifically for the source address of the OpenVPN tun on Router A (IP address 10.8.0.1 in my case)...

A correction to this, having now got things working properly: packets from the OpenVPN bridge server on Router A don't come out of 10.8.0.1, of course, they are plopped into the router from the port the OpenVPN bridge server is attached to, 1194 in my case. So, after creating the new routing table that omits the OpenVPN client interface, I used iptables to mark any packet that is from port 1194. The marked packets can then be directed to the new routing table.

Hence a line of the form:

iptables -t mangle -A OUTPUT -p udp --sport 1194 -j MARK --set-mark 0x88

...did the trick, with the new rule:

ip rule add fwmark 0x88 table 200

...where 200 is the modified routing table.

NOTE: OUTPUT is the correct iptables list for packets generated locally on the router.