redirect-gateway and route at the same time - possible?

svenfried

Hi,

I'm using OpenVPN for 8 years now, on Linux systems only. When I faced something I would like to configure, I was always able to do it myself.

Now I installed "OpenVPN Connect for Android" on my mobile (Cyanogenmod CM10 = Android 4.1.2 installed) and am facing a problem I was unable to solve.

My home OpenVPN server pushes a "redirect-gateway def1" to the clients. So I have the usual 0.0.0.0/1 and 128.0.0.0/1 routes as well as the host route to my home OpenVPN server set. Everything fine so far.

My home network uses 10.1.0.0/8, while my 3G provider uses 10.0.0.0/8 as network for their 3G clients. The routing table looks like (extract):

10.0.0.0/8 via rmnet0   (that's the 3G interface)
0.0.0.0/1 via tun0      (that comes from redirect-gateway def1)
128.0.0.0/1 via tun0    (that comes from redirect-gateway def1, too)

When trying to ping 10.1.0.11 (desktop computer), the ping goes out to the 3G network because it matches the 3G route.

So I tried to push "route 10.1.0.0 255.255.0.0" (in addition to "redirect-gateway def1") to the Android mobile. But it doesn't show up in the routing table. It only shows up when I remove "redirect-gateway def1".

To make it clear: pushing "route" works fine, pushing "redirect-gateway" works fine, too - but pushing both options together result in the pushed "route" being ignored.

In most cases this may make sense, since "def1" sets a route to everything not being explicitely routed elsewhere - but that exactly is my problem, since the 3G provider sets a route of 10.0.0.0/8 which includes my home subnet (10.1.0.0/16).

Question:
It seems to me that additional routes are ignored by OpenVPN when it sees a "redirect-gateway" option. Am I right? Or is there a workaround?

Thanks for any hints!
S.

JoshC

My home network uses 10.1.0.0/8, while my 3G provider uses 10.0.0.0/8 as network for their 3G clients.

This is very foolish on both your parts, and the source of your problem. The fix in a moment, but first some details on why this is a problem (and why fixing it resolves your issue.)

Do you really have a need to put 16.8 Million hosts on your single network at home? Assuming not, you've used far too large of a network. Routing table entries are matched by the most specific entry, which is why the two /1 routes override (without replacing) the default gateway in a --redirect-gateway setup.

The upshot of this is that if you use a more sane network, say 10.1.0.0/24, this will be more specific and thus preferred over the /8 route your uplink on the phone uses. It may be wise to pick a more obscure network though, just in case the ISP uses common ones for something important, like DNS; try picking a network in the middle of the vast 10/8 space. You also have 172.16/12 and 192.168/16 to choose from as well, per RFC1918.

Why your network provider puts a /8 on-link is beyond me; individual networks (at least traditional ones) simply don't scale to handle millions of clients. It looks like they haven't much clue what they're doing.

svenfried

Hi Josh,

thanks for your reply and the detailed explanations.

I agree with you that a /8 subnet doesn't make sense at home. In fact, I have 9 physical networks, each with a /16 netmask. Instead of pushing 9 times a /16 route, I decided to push a /8 route. That is no senseful idea, you are right.

I also agree with you that the most specific route gets preferred. But if you look at my initial post, you see that I pushed a /16 route, which should take precedence over the provider's /8 route. It shows up in android's routing table. But it does not show up if "redirect-gateway def1" is pushed, too.

So my thought was that pushing a route does not work when pushing "redirect-gateway def1". Do you know whether that's intended / correct?

Thanks again,
S.

JoshC

In fact, I have 9 physical networks, each with a /16 netmask. Instead of pushing 9 times a /16 route, I decided to push a /8 route.

Ah, okay, this is called a supernet (the opposite of a subnet: a network range that aggregates downstream networks.) This said, even a /16 on-link is "too much" (64k clients costs a lot in switches.) Try a /22 or so per LAN allowing 1021 clients, then supernet into a single /16. This has the wonderful advantage of not inherently colliding with every network out of your control that also use something in the popular 10/8 (ideally, make the 2nd octet more obscure, but that's obviously not as convenient.) The goal is to avoid overlap of networks.

So my thought was that pushing a route does not work when pushing "redirect-gateway def1". Do you know whether that's intended / correct?

This should work fine. Do you see the route being pushed in the server logs, and picked up by the client? Try using --verb 4 at both ends and look for the PUSH_REPLY. If the client has an error adding a route, it will list it in the log output as well.

Note that you will get an error if attempting to add a duplicate route and the 2nd one won't be added. This is perhaps the strongest reason to avoid using/pushing 10.1/16 as your supernet, since it's more likely to be used "on-link" by braindead ISPs than, say, 10.117/16. You could hack around the issue if you assign your /22's in the upper range and push 10.1.128/17 or something and hope no one uses a more-specific route in this range on their own networks.

svenfried

Thanks again, Josh!

This should work fine. Do you see the route being pushed in the server logs, and picked up by the client? Try using --verb 4 at both ends and look for the PUSH_REPLY. If the client has an error adding a route, it will list it in the log output as well.

If I exclude "redirect-gateway def1", I see in the server log:

SENT CONTROL [svenfried-mobile]: 'PUSH_REPLY,persist-tun,topology subnet,explicit-exit-notify 2,ping 30,ping-restart 90,route-gateway 10.1.101.1,route 10.1.0.0 255.255.0.0,route 10.2.0.0 255.255.0.0,route 10.3.0.0 255.255.0.0,ifconfig 10.1.101.15 255.255.255.0' (status=1)

The routes are shown in the phone's OpenVPN log file and are successfully set on the Android phone (I verified by typing "ip route" on the phone), but of course I miss the two "default gateway override" routes.

If I add "redirect-gateway def1", I see in the server log:

SENT CONTROL [svenfried-mobile]: 'PUSH_REPLY,persist-tun,topology subnet,explicit-exit-notify 2,ping 30,ping-restart 90,route-gateway 10.1.101.1,route 10.1.0.0 255.255.0.0,route 10.2.0.0 255.255.0.0,route 10.3.0.0 255.255.0.0,redirect-gateway def1,ifconfig 10.1.101.15 255.255.255.0' (status=1)

The Android phone still shows the routes in it's OpenVPN log file, but does not set them. As requested, it sets the two gateway overriding rules.

In short words: the routes are always shown in the server's and the client's logfile, but only applied if "redirect-gateway def1" is NOT pushed.

So I thought that this may be an Android related problem, but I get the same behaviour on my iPad with OpenVPN.

I have no routing errors in the client's logs. I double-checked it.

Do you have any further ideas on this?

Thanks a lot!
S.

JoshC

I just realized you are using the "OpenVPN Connect" product on your client. You should be aware this is not the same codebase as the GPL (open-source) product as it has been completely re-written. This may very well be a bug in that particular implementation. My guess is the closed-source Connect product attempts to take a shortcut and ignore all other routes when --redirect-gateway is used and your case breaks that assumption (I can't verify any of this since it's a closed-source product.)

For what it's worth, there's an Android implementation of the GPL code called "OpenVPN for Android" in the market. This section of the forums is for the GPL product, while you'd need to talk to the corporate side for support/problems with the non-free stuff.

Can you see what happens when you use a GPL OpenVPN on both sides of your connection? Use of a "full" computer (any OS is fine) may be far easier since it'll be easier to get logs and such.

To move forward, logs from both sides of the connection at --verb 4 will be helpful, although I'm betting use of GPL at both ends makes it all work.

svenfried

My guess is the closed-source Connect product attempts to take a shortcut and ignore all other routes when --redirect-gateway is used and your case breaks that assumption (I can't verify any of this since it's a closed-source product.)

Your guess was totally right. I tried a Debian Wheezy client and the routes are set, no matter whether "redirect-gateway" is pushed or not. :-)

although I'm betting use of GPL at both ends makes it all work.

Bet won. ;-)

Thanks a lot for your help! I will see that I'll post a bug against the "OpenVPN Connect" product.
S.

svenfried

I just installed "OpenVPN for Android" by Arne Schwabe, as you suggested. Works like a charm and the routes I push work as expected. Thanks again for the hint!

S.