redirect-gateway fails when default route does not use a gateway

Bug #771148 reported by Andreas Oberritter on 2011-04-26
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
openvpn (Debian)
Fix Released
Unknown
openvpn (Ubuntu)
Undecided
Unassigned
ppp (Ubuntu)
Undecided
TJ

Bug Description

Binary package hint: openvpn

When using a PPP connection to access the internet, OpenVPN fails to replace the default route.

Server's configuration:
push "redirect-gateway def1".

Client's default route:
default dev ppp0 scope link

Client's error message:
"NOTE: unable to redirect default gateway -- Cannot read current default gateway from system"

pppd doesn't set (and doesn't need) a gateway, but OpenVPN assumes that a gateway was needed for a default route.

Changed in openvpn (Debian):
status: Unknown → New
Andres Rodriguez (andreserl) wrote :

Hi Andreas,

Thank you for taking the time to report bugs and trying to make Ubuntu Server better.

Unfortunately, this doesn't really seem like a bug of OpenVPN but rather ppp is probably not setting the default gateway when it should. Reading [1], we can confirm that OpenVPN *needs* the default route in this case, to be able to function properly.

Now, in your PPP configuration you should be able to specify a default route a should set it as specified by [2] (since it seems like an old bug and fixed already)

Furthermore, there's a work around to generate the default gateway automatically and can be found at [3].

Based on the information above, I'd say this bug should be set to "Wont Fix".However, as there a related Debian bug, I'll keep it open as incomplete.

Thank you again

[1]: http://openvpn.net/archive/openvpn-users/2007-12/msg00029.html
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85426
[3]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592088#20

Changed in openvpn (Ubuntu):
status: New → Incomplete
Andreas Oberritter (obi++) wrote :

Hi Andres,

yes, OpenVPN needs a default route, and that route already exists. But you're mixing up route and gateway. PPP by definition does not need to specify a gateway, because all packets travel through the peer.

To function properly, OpenVPN should create a host route through ppp0. To do this, no gateway IP address is required at all. E.g. if your OpenVPN-server's address is 1.2.3.4, then the client should create a route like "ip route add 1.2.3.4/32 dev ppp0" instead of "ip route add 1.2.3.4/32 via $GATEWAY dev ppp0".

Of course, there are numerous ways to workaround this problem, but I'm more interested in solutions which work out of the box.

Regards,
Andreas

TJ (tj) wrote :

I agree with Andreas; this is a bug in openvpn. I have local office gateway servers with an internal PCI ADSL modem that runs embedded Linux and is configured in RFC 1483 LLC Bridge mode. The Host PC uses PPPoE to connect to the ISP via the embedded ADSL modem over the single ATM LLC available from BT in the U.K.

This results in the host PC creating the ppp0 interface which is the default route:

$ ip route show
default dev ppp0 scope link
62.3.82.17 dev ppp0 proto kernel scope link src 82.71.24.87
...

The OpenVPN server's configuration includes:

push "redirect-gateway def1"

When the local office connects it reports:

ovpn-01linode[24920]: TUN/TAP device tun0 opened
ovpn-01linode[24920]: TUN/TAP TX queue length set to 100
ovpn-01linode[24920]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
ovpn-01linode[24920]: /sbin/ifconfig tun0 10.254.252.18 pointopoint 10.254.252.17 mtu 1500
ovpn-01linode[24920]: NOTE: unable to redirect default gateway -- Cannot read current default gateway from system

There is (an invasive) patch in Debian bug #592088 by Lionel Elie Mamane in comment 10. A better solution that doesn't involve trying to get the OpenVPN project to substantially change the semantics of "redirect-gateway" to "redirect-default-route" is in a short PPP script mentioned by Vladislav Naumov in comment 20, and originally from the OpenVPN mailing list in 2007:

/etc/ppp/ip-up.d/default-gateway:
---------------8<--------------
#!/bin/bash

if [ $(ip route list exact default |\
  awk '/^default/ {print $2}') = dev ];
then
         IF=$(ip route | awk '/^default/ {print $3}')
         GW=$(ip address show $IF |\
  awk '/peer/ {print $4}' | cut -d"/" -f1)
         ip route replace default via $GW dev $IF
fi
-----------8<------------------

Now, when the PPP interface comes up

 default dev ppp0 scope link

is replaced by the PPP script with a route that includes the ISP gateway IP address:

 default via 62.3.82.19 dev ppp0

This allows OpenVPN to recognise and replace the default route when it starts:

default via 10.254.252.17 dev tun0
10.254.252.17 dev tun0 proto kernel scope link src 10.254.252.18

TJ (tj) wrote :

I've added the PPP package to this bug since it would the appropriate place to ship the workaround and, as far as I can see, shouldn't upset any existing PPP configurations.

It would actually save our users a lot trouble especially for those using portable devices over public WiFi or cellular data when they use OpenVPN since many cellular operates also do not provide a gateway IP for the default route.

I'll pass this on to Debian's PPP maintainer and see if we can get some movement on this.

Changed in ppp (Ubuntu):
status: New → In Progress
assignee: nobody → TJ (intuitivenipple)
TJ (tj) wrote :

I've attached the shell script for PPP so it can be downloaded. It should be put in the directory /etc/ppp/if-up.d/ and given execute permissions:

sudo mv ~/Downloads/default-gateway /etc/ppp/if-up.d/
sudo chmod +x /etc/ppp/if-up.d/default-gateway

TJ (tj) wrote :

Correction! I mistyped the PPP directory name as "iF-up.d" when it should be "iP-up.d". The instructions should be:

I've attached the shell script for PPP so it can be downloaded. It should be put in the directory /etc/ppp/ip-up.d/ and given execute permissions:

sudo mv ~/Downloads/default-gateway /etc/ppp/ip-up.d/
sudo chmod +x /etc/ppp/ip-up.d/default-gateway

This also suggests another script is needed for Ipv6. I'll investigate.

Changed in openvpn (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.