Everything is routed via default route

[lexus45]

Hello all.
I faced a problem - everything is routed via default route, either Wi-Fi or mobile internet.
I need access to another vpn client only ('client-to-client' and ip_forwarding are enabled on server, firewall allows this traffic either).

Other OpenVPN clients (Linux and Win) work well, there are no any routing problems with them, they are available to each other.
The problem is with Android client only.

Even the ping/traceroute to server's vpn address goes via wrong route.

I tried to add a route manually, but the smartphone needs to be rooted for that.
This problem makes my Android client useless.

Tried to find here the same problem, but the word 'route' is prohibited in search as too general, and searching manually gives the results as "how to route all traffic via vpn" but this is not what I need.

Lenovo A2010-a
Android 5.1
OpenVPN Connect from Google Play
server OpenVPN 2.4.4 @ Debian9

Thanks in advice,
BR Alexey

[TinCanTech]

Even the ping/traceroute to server's vpn address goes via wrong route

What do your log files say ?

[lexus45]

Hello TinCanTech ,
thank you for the reply.

I haven't noticed anything wrong in logfiles, and I'm sure I will not, because the connection itself is OK.
I just installed traceroute application to my Android phone and see that traffic tries to go via anything else but not OpenVPN route/interface.

So, as I understand, this is not an OpenVPN Connect issue, but an Android one. But I don't know how to solve it right.

By the way, what log file exactly do you mean?

When I add to _client's_ config (Android) "route 10.89.222.5 255.255.255.255 10.89.222.1 " I see in client's logfile:

Code: Select all

[10.89.222.5] [255.255.2555.255] [10.89.222.1] : tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported

But I think it's odd to add the VPN's network itself as an option of client's config, isn't it?! This is just a trying to solve my problem. At the starting point I havent' had this option in client's config of course.

Well, let's remove this wrong "route ..." option it from client's config, because 10.89.222.5 is another (well working) OpenVPN client machine. (10.89.222.1 is an OpenVPN server and 10.89.222.4 - is Android). The logfile (verb 3) is ideal!


upd: [img] code not working. this is the link to screenshot with connection log of Android client ibb.co/bQ5nAc

[TinCanTech]

what log file exactly do you mean?

Openvpn server and client log files at verb 4 ..

When I add to _client's_ config (Android) "route 10.89.222.5 255.255.255.255 10.89.222.1 " I see in client's logfile:

Code: Select all

[10.89.222.5] [255.255.2555.255] [10.89.222.1] : tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported

In this case vpn_gateway is the desired gateway (which is the default I believe)

[lexus45]

In this case vpn_gateway is the desired gateway (which is the default I believe)

Yes, it is, but other clients (Windows and Linux) can reach each other without such options.

Openvpn server and client log files at verb 4 ..

This is from server:

Code: Select all

]
Mon Feb  5 18:04:14 2018 us=624315 MULTI: multi_create_instance called
Mon Feb  5 18:04:14 2018 us=624548 31.173.103.59:51418 Re-using SSL/TLS context
Mon Feb  5 18:04:14 2018 us=624741 31.173.103.59:51418 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Feb  5 18:04:14 2018 us=624771 31.173.103.59:51418 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Mon Feb  5 18:04:14 2018 us=624882 31.173.103.59:51418 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Feb  5 18:04:14 2018 us=624979 31.173.103.59:51418 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Feb  5 18:04:14 2018 us=625048 31.173.103.59:51418 TLS: Initial packet from [AF_INET]31.173.103.59:51418, sid=f1a15c1a 8f8284b9
Mon Feb  5 18:04:16 2018 us=98047 31.173.103.59:51418 VERIFY OK: depth=1, C=RU, ST=45, L=Kgn, O=XM, OU=XmUnit, CN=XM CA, name=EasyRSA, emailAddress=XXX@YYY.ZZ
Mon Feb  5 18:04:16 2018 us=98507 31.173.103.59:51418 VERIFY OK: depth=0, C=RU, ST=45, L=Kgn, O=XM, OU=XmUnit, CN=XXXX-cell, name=EasyRSA, emailAddress=XXX@YYY.ZZ
Mon Feb  5 18:04:16 2018 us=171519 31.173.103.59:51418 peer info: IV_GUI_VER=net.openvpn.connect.android_1.1.27-96
Mon Feb  5 18:04:16 2018 us=171808 31.173.103.59:51418 peer info: IV_VER=3.1.2
Mon Feb  5 18:04:16 2018 us=171926 31.173.103.59:51418 peer info: IV_PLAT=android
Mon Feb  5 18:04:16 2018 us=172047 31.173.103.59:51418 peer info: IV_NCP=2
Mon Feb  5 18:04:16 2018 us=172186 31.173.103.59:51418 peer info: IV_TCPNL=1
Mon Feb  5 18:04:16 2018 us=172309 31.173.103.59:51418 peer info: IV_PROTO=2
Mon Feb  5 18:04:16 2018 us=172457 31.173.103.59:51418 peer info: IV_IPv6=0
Mon Feb  5 18:04:16 2018 us=172574 31.173.103.59:51418 peer info: IV_AUTO_SESS=1
Mon Feb  5 18:04:16 2018 us=172694 31.173.103.59:51418 peer info: IV_BS64DL=1
Mon Feb  5 18:04:16 2018 us=237378 31.173.103.59:51418 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mon Feb  5 18:04:16 2018 us=237658 31.173.103.59:51418 [XXXX-cell] Peer Connection Initiated with [AF_INET]31.173.103.59:51418
Mon Feb  5 18:04:16 2018 us=237845 XXXX-cell/31.173.103.59:51418 MULTI_sva: pool returned IPv4=10.89.222.4, IPv6=(Not enabled)
Mon Feb  5 18:04:16 2018 us=238010 XXXX-cell/31.173.103.59:51418 MULTI: Learn: 10.89.222.4 -> XXXX-cell/31.173.103.59:51418
Mon Feb  5 18:04:16 2018 us=238116 XXXX-cell/31.173.103.59:51418 MULTI: primary virtual IP for XXXX-cell/31.173.103.59:51418: 10.89.222.4
Mon Feb  5 18:04:16 2018 us=243507 XXXX-cell/31.173.103.59:51418 PUSH: Received control message: 'PUSH_REQUEST'
Mon Feb  5 18:04:16 2018 us=243756 XXXX-cell/31.173.103.59:51418 SENT CONTROL [XXXX-cell]: 'PUSH_REPLY,route-gateway 10.89.222.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.89.222.4 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)
Mon Feb  5 18:04:16 2018 us=243939 XXXX-cell/31.173.103.59:51418 Data Channel: using negotiated cipher 'AES-256-GCM'
Mon Feb  5 18:04:16 2018 us=244113 XXXX-cell/31.173.103.59:51418 Data Channel MTU parms [ L:1549 D:1450 EF:49 EB:406 ET:0 EL:3 ]
Mon Feb  5 18:04:16 2018 us=244431 XXXX-cell/31.173.103.59:51418 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Feb  5 18:04:16 2018 us=244567 XXXX-cell/31.173.103.59:51418 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

And from Android:
http://ibb.co/bLB7dx
http://ibb.co/jEezrH
http://ibb.co/ebv5WH
http://ibb.co/giYykc
http://ibb.co/mhhr5c


So, the Android system does not route even for the inner VPN address trough the tun interface.
This is the screenshot when I access the Internet via corporate WiFi, and we see that the phone tries to reach 10.89.222.1 (inner VPN server's address) through the default route, as I traceroute some Internet public address. http://ibb.co/hLoWMH
But it has to reach it just in one hop, because this is the same network.

I'm absolutely sure this is an Android routing issue, not the OpenVPN Connect one. I just don't know how to solve it.

[ordex]

When I add to _client's_ config (Android) "route 10.89.222.5 255.255.255.255 10.89.222.1 " I see in client's logfile:

Code: Select all

[10.89.222.5] [255.255.2555.255] [10.89.222.1] : tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported

But I think it's odd to add the VPN's network itself as an option of client's config, isn't it?! This is just a trying to solve my problem. At the starting point I havent' had this option in client's config of course.

Well, let's remove this wrong "route ..." option it from client's config, because 10.89.222.5 is another (well working) OpenVPN client machine. (10.89.222.1 is an OpenVPN server and 10.89.222.4 - is Android). The logfile (verb 3) is ideal!

it may be a problem with the default routes being added to Android.
However, please try the route command in the client config again, but without the last IP "10.89.222.1". As tincantech said, this is already the default.
Moreover, you can't specify an ip there, but you need to use the keywords vpn_gateway or net_gateway. However, not putting any IP is ok too.

[lexus45]

Tried with '--route' option in client's config:

client
dev tun
proto udp
remote XX.YY.ZZ.ZZ 1194

route 10.89.222.5 255.255.2555.255

resolv-retry infinite
persist-key
persist-tun
ca ca.crt
cert xxx-cell.crt
key xxx-cell.key
remote-cert-tls server
verb 4

Nothing changed...
The traceroute still tries to route to another client's vpn address via WiFi interface, not tun.

This routing problem makes Android application for me absolutely useless, as it just connects and this is all I can do with it.
I'm sure that somebody else also faced such a problem in Android.

[TinCanTech]

client

route 10.89.222.5 255.255.2555.255

First, you do not require that route, it is included in the VPN subnet.

Second, please post your server config file.

[ordex]

Can you also post the full android log?

[lexus45]

TinCanTech, yes, I understand it.
That was a try, after normal config, because something is wrong with routing in Android.

And this is a server config:

Code: Select all

local		X.X.153.152
port		1194
dev		tun
server	10.89.222.0 255.255.255.0
client-to-client
persist-key
persist-tun
topology subnet
proto     udp
keepalive 10 120
ca	/etc/openvpn/ca/keys/ca.crt
cert	/etc/openvpn/ca/keys/server.crt
key	/etc/openvpn/ca/keys/server.key
dh	/etc/openvpn/ca/keys/dh2048.pem
explicit-exit-notify 1
user	nobody
group	nogroup
ifconfig-pool-persist	ipp.txt
management		localhost 7505
status			openvpn-status.log
log		/var/log/openvpn.log
verb		4

ordex, yes, I can show clients logfile, this is with 'verb 5'. (haven't found how to export it in txt, and can not select & copy, so only as screenshots):
http://ibb.co/eUShYx
http://ibb.co/dHNALc
http://ibb.co/iYeJ6H
http://ibb.co/jDrLLc
http://ibb.co/fTPkmH


With this server config and absolutely alike client's 3 configs (for Linux, for Windows and for iPad - differences only in keys/certs) - everything works on those 3 platforms. Only Android fails.

[ordex]

Can you also provide the log when applying the "route" statement we discussed above? In theory that should make it work. Can you also specify how you are testing the route? Are you only using this traceroute app or do you also have another way?

[lexus45]

Can you also provide the log when applying the "route" statement we discussed above? In theory that should make it work. Can you also specify how you are testing the route? Are you only using this traceroute app or do you also have another way?

Sure I can.

Log with "route ". And we can see an error because of this wrong option (last two screens)
http://ibb.co/gc5c0c
http://ibb.co/edLc0c
http://ibb.co/bJzn0c
http://ibb.co/ms8rRH
http://ibb.co/dupn0c
http://ibb.co/iM8fLc

How I tested:
1. there's a webserver listening on that vpn client (10.89.222.5). it is unreachable only from Android via VPN (Win/Lin/iPad vpn clients work OK).

2. that's why I checked with traceroute application. Both mobile Internet and WiFi.
3. 'ip r', both mobile Internet and WiFi:

mobile internet:
http://ibb.co/kzRH0c
http://ibb.co/cwURtx
http://ibb.co/jokMRH

wifi:
http://ibb.co/ghyfLc
http://ibb.co/eoX70c
http://ibb.co/hFdrRH

in case of traceroute via WiFi we see how traffic goes to my corporate WiFi router (10.145.18.1). This shows obviously that there's a routing problem in Android.

In case of mobile internet there are no any hops seen (don't know exactly why, something depending on connection type or maybe some of ICMP/UDP ping is restricted in my cell operator's network - but anyhow another vpn client's address 10.89.222.5 (and 10.89.222.1 either) is unreachable).

I'm very sad. Any other clients with the same config file work excellent (Windows, Linux, iPad).
I think we can stop this thread, it's obvious that the problem is not with OpenVPN software but with Android routing.

Manyt hanks to everybody who was eager to help me.

[ordex]

Can you also provide the log when applying the "route" statement we discussed above? In theory that should make it work. Can you also specify how you are testing the route? Are you only using this traceroute app or do you also have another way?

Sure I can.

Log with "route ". And we can see an error because of this wrong option (last two screens)
http://ibb.co/gc5c0c
http://ibb.co/edLc0c
http://ibb.co/bJzn0c
http://ibb.co/ms8rRH
http://ibb.co/dupn0c
http://ibb.co/iM8fLc

Of course: 255.255.*2555*.255 is not a valid netmask.

[lexus45]

Of course: 255.255.*2555*.255 is not a valid netmask.

Oh... shame on me.
A typo.

Now works!
Thank you all.

[TinCanTech]

And now you have deleted all the information so we cannot see what was wrong.

Where was "The Typ0" ?

[ordex]

Of course: 255.255.*2555*.255 is not a valid netmask.

in the netmask ^^^^ of the route config option

[TinCanTech]

In the client config I presume ?

[ordex]

yep. if you check the log in comment viewtopic.php?f=33&p=76678#p76577 , the typ0 was already there

[TinCanTech]

Wow .. Sharp eyes needed to see that .. even reviewing took me a while to spot it !

So now, do you have a bug report for that ? eg. "Invalid netmask detected!"