Created an attachment (id=1896) [details]
route -n snapshots of the individual steps

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

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"

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)

Created an attachment (id=1940) [details]
log of failing routing table rollback

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

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...

(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.

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.

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?

(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?

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 ;) )

(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?

(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?

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.

(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 :)