Bug 413573

Road-warrior scenario, using OpenSuse11 with current patches on a laptop:

If I start OpenVPN from the Gnome network manager to connect to my company LAN in bridged mode, then it doesn't setup the routing information provided by the server. This is fatal. I did not set any networks to restrict OpenVPN in the Advanced Options.

"netstat -nr" shows

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
xx.xx.xx.xx     192.168.1.3     255.255.255.255 UGH       0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 tap0


(instead of

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
xx.xx.xx.xx     192.168.1.3     255.255.255.255 UGH       0 0          0 eth0
172.19.108.0    0.0.0.0         255.255.252.0   U         0 0          0 tap0
192.168.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         172.19.108.1    0.0.0.0         UG        0 0          0 tap0

)

172.19.108/22 is the company lan, xx.xx.xx.xx is the OpenVPN server, and 192.168.1.3 is the gateway in the Internet Cafe. Of course I waited for the route-delay timeout.

Using a traditional client.conf config file to start OpenVPN there is no such problem. Here it is:

# client.conf on road-warrior laptop
client
ns-cert-type server
dev tun
dev-type tap
proto udp
remote xx.xx.xx.xx
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/public/OpenVPN_ca-cachain.pem
cert /etc/openvpn/public/client.crt
key /etc/openvpn/private/client.key
comp-lzo


And here is the server.conf file used for both tests:

# server.conf
local xx.xx.xx.xx
port 1194
proto udp
dev tun0
dev-type tap
ca /etc/openvpn/public/OpenVPN_ca-cachain.pem
cert /etc/openvpn/public/server.crt
key /etc/openvpn/private/server.key
dh /etc/openvpn/public/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 172.19.108.1 255.255.252.0 172.19.111.1 172.19.111.254
push "route-delay 30"
push "redirect-gateway"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log


Here is the log file on the server (using NetworkManager on the client):

openvpn[6380]: MULTI: multi_create_instance called
openvpn[6380]: yy.yy.yy.yy:61037 Re-using SSL/TLS context
openvpn[6380]: yy.yy.yy.yy:61037 LZO compression initialized
openvpn[6380]: yy.yy.yy.yy:61037 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
openvpn[6380]: yy.yy.yy.yy:61037 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
openvpn[6380]: yy.yy.yy.yy:61037 Local Options hash (VER=V4): 'f7df56b8'
openvpn[6380]: yy.yy.yy.yy:61037 Expected Remote Options hash (VER=V4): 'd79ca330'
openvpn[6380]: yy.yy.yy.yy:61037 TLS: Initial packet from yy.yy.yy.yy:61037, sid=ea84acc5 a97bf13c
openvpn[6380]: yy.yy.yy.yy:61037 VERIFY OK: depth=2, /C=DE/ST=NRW/L=Aachen/O=Aixigo/OU=IT/CN=CA/emailAddress=user@myhost
openvpn[6380]: yy.yy.yy.yy:61037 VERIFY OK: depth=1, /C=DE/ST=NRW/L=Aachen/O=Aixigo/OU=IT/CN=OpenVPN_ca/emailAddress=user@myhost
openvpn[6380]: yy.yy.yy.yy:61037 VERIFY OK: depth=0, /C=DE/ST=NRW/L=Aachen/O=Aixigo/OU=IT/CN=client/emailAddress=user@myhost
openvpn[6380]: yy.yy.yy.yy:61037 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[6380]: yy.yy.yy.yy:61037 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[6380]: yy.yy.yy.yy:61037 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
openvpn[6380]: yy.yy.yy.yy:61037 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
openvpn[6380]: yy.yy.yy.yy:61037 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
openvpn[6380]: yy.yy.yy.yy:61037 [client] Peer Connection Initiated with yy.yy.yy.yy:61037
openvpn[6380]: client/yy.yy.yy.yy:61037 PUSH: Received control message: 'PUSH_REQUEST'
openvpn[6380]: client/yy.yy.yy.yy:61037 SENT CONTROL [client]: 'PUSH_REPLY,route-delay 5,redirect-gateway,route-gateway 172.19.108.1,ping 10,ping-restart 120,ifconfig 172.19.111.1 255.255.252.0' (status=1)
openvpn[6380]: client/yy.yy.yy.yy:61037 MULTI: Learn: 00:ff:3c:8c:5d:2c -> client/yy.yy.yy.yy:61037



yy.yy.yy.yy is the NAT gateway of the Internet Cafe. As you can see, the server _does_ push the (requested!) routing settings to the client, but they are ignored.

How can I tell OpenVPN via NetworkManager to accept the settings provided by the server? 

I could not reproduce this problem with Ubuntu 8.04 (running on the same laptop).