Bug 7596 - (dbts-535033) redirect-gateway broken with 2G/3G connections
(dbts-535033)
: redirect-gateway broken with 2G/3G connections
Status: RESOLVED WONTFIX
Product: openvpn
General
: 2.1~rc20
: N900 Maemo
: Medium major (vote)
: ---
Assigned To: AB
: general
:
: upstream
:
:
  Show dependency tree
 
Reported: 2010-01-03 03:29 UTC by Gregor Schaffrath
Modified: 2010-05-06 20:44 UTC (History)
2 users (show)

See Also:


Attachments
route -n snapshots of the individual steps (437 bytes, text/x-log)
2010-01-03 03:30 UTC, Gregor Schaffrath
Details
log of failing routing table rollback (740 bytes, application/octet-stream)
2010-01-06 14:59 UTC, Gregor Schaffrath
Details
workaround script (448 bytes, application/x-sh)
2010-01-07 14:15 UTC, Gregor Schaffrath
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Gregor Schaffrath (reporter) 2010-01-03 03:29:16 UTC
SOFTWARE VERSION:
(Settings > General > About product)
1.2009.42-11

EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. establish 2G/3G connection via grps0 interface
2. start openvpn-tunnel to a connection using redirect-gateway
3. 

EXPECTED OUTCOME:
default route replaced by route via tunnel

ACTUAL OUTCOME:
route to tunnel endpoint comes up, but default route is not replaced (new one
is missing, old one stays)

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
always

EXTRA SOFTWARE INSTALLED:
none relevant again ;)

OTHER COMMENTS:
Yet another one I'm unsure where to put. If I'm not mistaken (this is just a
guess, though), the problem probably occurs when the default route contains
0.0.0.0 as gateway - probably openvpn doesn't know how to handle this...
(I noticed that the routing table contains only
0.0.0.0   0.0.0.0   0.0.0.0   U    0   0   0   gprs0
upon 2G/3G connections)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6)
Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.0.8, Ant.com Toolbar 1.3
Comment 1 Gregor Schaffrath (reporter) 2010-01-03 03:30:48 UTC
Created an attachment (id=1896) [details]
route -n snapshots of the individual steps
Comment 2 AB 2010-01-03 20:48:03 UTC
Bug #7215 & bug #7217 & bug #7596 are apparently related to the
"redirect-gateway" keyword not working as expected in the case of a cellular
connection, because the corresponding route does not have the G flag.

This seems to be an issue with upstream as well:
http://openvpn.net/archive/openvpn-users/2007-12/msg00029.html
Comment 3 Gregor Schaffrath (reporter) 2010-01-06 14:42:00 UTC
Took the time to start openvpn on the console and browse the output.

I can confirm that openvpn fails to recognize the default route as such:
"NOTE: unable to redirect default gateway -- Cannot read current default
gateway from system"
Comment 4 Gregor Schaffrath (reporter) 2010-01-06 14:58:27 UTC
here as well:
openvpn doesn't recognize the  new grps0 route as default route and attempts a
(failing) rollback to the values corresponding to the wlan connection it had.
(will shortly create fail.log attachment)
Comment 5 Gregor Schaffrath (reporter) 2010-01-06 14:59:11 UTC
Created an attachment (id=1940) [details]
log of failing routing table rollback
Comment 6 AB 2010-01-06 20:37:05 UTC
Closing as WONTFIX since I believe this is something that should be fixed
upstream.

A possible workaround is shown here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=85426

Reports in SF bugtracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=2924351&group_id=48978&atid=454719
http://sourceforge.net/tracker/index.php?func=detail&aid=1542492&group_id=48978&atid=454719
Comment 7 Gregor Schaffrath (reporter) 2010-01-07 12:49:31 UTC
sorry - I cannot relate this bug to the workaround link you provided... what
the phonet driver is doing is exactly what the post you linked as workaround is
requesting...

The route is the equivalent of 
route add default dev gprs0

And if you're right about the missing G flag, this is exactly the cause of the
problem...
Comment 8 AB 2010-01-07 12:59:20 UTC
(In reply to comment #7)

> And if you're right about the missing G flag, this is exactly the cause of the
> problem...

Since Debian is my "upstream", I had a look the BTS and found this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535033

I am adding it as an alias, but not commenting on the original bug report since
we have nothing to add, really.
Comment 9 Gregor Schaffrath (reporter) 2010-01-07 14:15:08 UTC
Created an attachment (id=1946) [details]
workaround script

copy to 
/etc/openvpn/
use with 
ipchange /etc/openvpn/add_default_route.sh
and
script-security 2
in your config file

This basically creates an official default route based on the grps0
configuration, if gprs0 is up and no official default route (i.e. one with the
set G flag) exists.
Comment 10 Gregor Schaffrath (reporter) 2010-01-07 14:19:31 UTC
hehe - you were a bit quicker than I, Andrea ;)

I wonder whether it would make sense to request the connection component
developer to set default routes when gprs0 comes up. (not sure whether there
are other situation where this would break things, but I cannot readily think
of one)

I think they should at least be aware of this implication.

Would it make sense to reopen and move the bug to the connection component?
Comment 11 jsbigs.mail 2010-01-11 01:08:14 UTC
(In reply to comment #9)
> Created an attachment (id=1946) [details] [details]
> workaround script
> 
> copy to 
> /etc/openvpn/
> use with 
> ipchange /etc/openvpn/add_default_route.sh
> and
> script-security 2
> in your config file
> 
> This basically creates an official default route based on the grps0
> configuration, if gprs0 is up and no official default route (i.e. one with the
> set G flag) exists.
> 

Are you saying you got this to work with the above?  If so, any help you can
offer is appreciated as this is fairly new to me.  I did get openvpn to work
with my MacMini after many hours and much trial and error.  Like all/most here,
I cannot get "redirect-gateway def1" while on gprs. It doesn't work on my LAN
either though as it does work with a Viscosity/Witopia subscription on my LAN
and WAN, I'm hopeful that when I eventually leave the house and try to VPN to
my MacMini over WAN that it will work.  My conf file reads as follows after
trying to add the above lines correctly:

client
dev tun
proto udp
remote <ip_address> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
route add default dev gprs0
ipchange /etc/openvpn/add_default_route.sh
script-security 2
pull "redirect-gateway def1"
ns-cert-type server
cipher BF-CBC
comp-lzo
verb 3 

I get the following back when testing this:

Sun Jan 10 13:56:25 2010 [server] Peer Connection Initiated with
[AF_INET]<ip_address>:1194 
Sun Jan 10 13:56:25 2010 ip-change command failed: could not execute external
program 
Sun Jan 10 13:56:27 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) 
Sun Jan 10 13:56:27 2010 PUSH: Received control message:
'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.8.0.1,route
10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' 
Sun Jan 10 13:56:27 2010 ROUTE: default_gateway=UNDEF 
Sun Jan 10 13:56:27 2010 RESOLVE: Cannot resolve host address: add:
[HOST_NOT_FOUND] The specified host is unknown. 
Sun Jan 10 13:56:27 2010 OpenVPN ROUTE: failed to parse/resolve route for
host/network: add 
Sun Jan 10 13:56:27 2010 TUN/TAP device tun0 opened 
Sun Jan 10 13:56:27 2010 TUN/TAP TX queue length set to 100 
Sun Jan 10 13:56:27 2010 /sbin/ifconfig tun0 10.8.0.6 pointopoint 10.8.0.5 mtu
1500 
Sun Jan 10 13:56:27 2010 NOTE: unable to redirect default gateway -- Cannot
read current default gateway from system 
Sun Jan 10 13:56:27 2010 /sbin/route add -net 10.8.0.1 netmask 255.255.255.255
gw 10.8.0.5 
Sun Jan 10 13:56:28 2010 Initialization Sequence Completed 

Anything look right or wrong?
Comment 12 Gregor Schaffrath (reporter) 2010-01-11 11:21:54 UTC
Did you make sure the script is set to be executable? ;)

Sun Jan 10 13:56:25 2010 ip-change command failed: could not execute external
program 

ls -l will show the flags set (the x marks the spot ;) )
Comment 13 jsbigs.mail 2010-01-11 21:53:57 UTC
(In reply to comment #12)
> Did you make sure the script is set to be executable? ;)
> 
> Sun Jan 10 13:56:25 2010 ip-change command failed: could not execute external
> program 
> 
> ls -l will show the flags set (the x marks the spot ;) )
> 

I'm not sure how to do that or set that up.  Not a programmer but a Googler. 
Can you assist?
Comment 14 Mikko Vartiainen 2010-04-28 16:53:56 UTC
(In reply to comment #10)
> hehe - you were a bit quicker than I, Andrea ;)
> 
> I wonder whether it would make sense to request the connection component
> developer to set default routes when gprs0 comes up. (not sure whether there
> are other situation where this would break things, but I cannot readily think
> of one)
> 
> I think they should at least be aware of this implication.
> 
> Would it make sense to reopen and move the bug to the connection component?
> 

I'm im process of making some changes to openvpn-applet. It has now support for
libconic and can detect when network connections come up and down. I could run
the script everytime when connection comes up, do you think it'a absolute safe
(now when some time has passed) to do it?
Comment 15 Gregor Schaffrath (reporter) 2010-05-06 18:16:01 UTC
Hi Mikko!

Never had any problem with it, and don't see any conceptual reason for trouble
in common setups, as the addition of the default route only makes the implicit
explicit.

'common setups', as in principal you might also have custom setups with e.g.
several active network interfaces, multiple routing tables, possible hack $foo
reasons on why the gprs0 route is up, but not used as a full default gw...

If you consider adding the script to the package, and feel unsure about these
(somewhat exotic) setups, I'd recommend adding a tickbox enabling/disabling it
:)

Cheers, Gregor.
Comment 16 Mikko Vartiainen 2010-05-06 20:44:34 UTC
(In reply to comment #15)
> If you consider adding the script to the package, and feel unsure about these
> (somewhat exotic) setups, I'd recommend adding a tickbox enabling/disabling it
> :)
> 

The script is actually already included since openvpn-applet 0.6.0 (in
extras-testing). It is run when  GPRS connection is brought up and openvpn
process is running, and before openvpn is started when GPRS connection is
active. So far so good, haven't had any problems. It would be possible to run
it only when connection actually uses "redirect-gateway" parameter, but I just
got rid of requirement of configuration files being readable by user (applet is
run as user).

I don't support exotic setups, so there is no tickbox :)