Well, finally got an Android device and managed to push in the OpenVPN. Everything went paintless, the connection is made (for now manually) without errors. Route, ifconfig, redirect-gateway is working. But, but...
As Android kernel does not have a lot of usefull commands, "busybox" is needed, which emulates the commands like route, ifconfig, and other. So, the problem with traceroute. I made two test, when server's tun adapted is in dhcp mode and when server's tun has the static ip set.
The tunnel IP mask is 192.168.3.0/24. The private IP gaved by windows systems is 169.254.220.0/24. When tun adpather on server (windows based) is bring up, it gets two IPs: 192.168.3.1/255.255.255.252 and 169.254.220.180/255.255.255.0.
Having OpenVPN already running for remote sites, I just added a new certificate and connected the Android. The IP it gets is 192.168.3.14/255.255.255.252 and gw 192.168.3.13. Also I push servers LAN 192.168.0.0/24.
Now, first client is a windows (working already). The routing table looks like this:
Network Mask Gateway Interface Metric
0.0.0.0 0.0.0.0 public.189 public.190 20
public.188 255.255.255.252 public.190 public.190 20
public.255.255.255 255.255.255.255 public.190 public.190 20
169.254.61.0 255.255.255.0 169.254.61.215 169.254.61.215 20
169.254.61.215 255.255.255.255 127.0.0.1 127.0.0.1 20
169.254.255.255 255.255.255.255 169.254.61.215 169.254.61.215 20
192.168.0.0 255.255.255.0 192.168.3.25 192.168.3.26 1
192.168.3.0 255.255.255.0 192.168.3.25 192.168.3.26 1
192.168.3.24 255.255.255.252 192.168.3.26 192.168.3.26 30
192.168.3.26 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.3.255 255.255.255.255 192.168.3.26 192.168.3.26 30
224.0.0.0 and 255.255.255.255 part
The routing table on Android without redirect-gateway:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.13 * 255.255.255.255 UH 0 0 0 tun0
public.136 * 255.255.255.252 U 0 0 0 rmnet0
192.168.3.0 192.168.3.13 255.255.255.0 UG 0 0 0 tun0
192.168.0.0 192.168.3.13 255.255.255.0 UG 0 0 0 tun0
default public.138 0.0.0.0 UG 0 0 0 rmnet0
And the routing table for windows server (with dinamic IP on tun adapter):
Network Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 public.33 public.38 20
public.32 255.255.255.248 public.38 public.38 20
public.255.255.255 255.255.255.255 public.38 public.38 20
169.254.0.0 255.255.0.0 169.254.220.180 169.254.220.180 30
169.254.220.180 255.255.255.255 127.0.0.1 127.0.0.1 30
169.254.255.255 255.255.255.255 169.254.220.180 169.254.220.180 30
192.168.0.0 255.255.255.0 192.168.0.250 192.168.0.250 20
192.168.255.255 255.255.255.255 192.168.0.250 192.168.0.250 20
192.168.3.0 255.255.255.252 192.168.3.1 169.254.220.180 30
192.168.3.0 255.255.255.0 192.168.3.2 169.254.220.180 1
192.168.3.1 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.3.255 255.255.255.255 169.254.220.180 169.254.220.180 30
224.0.0.0 and 255.255.255.255 part
and windows server with static IP on tun adapter:
Network Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 public.33 public.38 20
public.32 255.255.255.248 public.38 public.38 20
public.255.255.255 255.255.255.255 public.38 public.38 20
192.168.0.0 255.255.0.0 192.168.0.250 192.168.0.250 20
192.168.255.255 255.255.255.255 192.168.0.250 192.168.0.250 20
192.168.3.0 255.255.255.252 192.168.3.1 192.168.3.1 30
192.168.3.0 255.255.255.0 192.168.3.2 192.168.3.1 1
192.168.3.1 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.3.255 255.255.255.255 192.168.3.1 192.168.3.1 30
224.0.0.0 and 255.255.255.255 part
Now with the problem. A ping to 192.168.0.252 (in servers LAN) works from windows client and adroid:
Pinging 192.168.0.252 with 32 bytes of data:
Reply from 192.168.0.252: bytes=32 time=9ms TTL=127
Reply from 192.168.0.252: bytes=32 time=5ms TTL=127
PING 192.168.0.252 (192.168.0.252) 56(84) bytes of data.
64 bytes from 192.168.0.252: icmp_seq=1 ttl=127 time=496 ms
64 bytes from 192.168.0.252: icmp_seq=2 ttl=127 time=516 ms
The strange thing is with trace the path to 192.168.0.252:
From windows client when on server tun adapter has a dinamic IP:
Tracing route to 192.168.0.252 [192.168.0.252]
over a maximum of 30 hops:
1 * * * Request timed out.
2 19 ms 11 ms 8 ms 192.168.0.252 [192.168.0.252]
From android when on server tun adapter has a dinamic IP:
busybox traceroute -I 192.168.0.252
traceroute to 192.168.0.252 (192.168.0.252), 30 hops max, 38 byte packets
1 169.254.220.180 (169.254.220.180) 377.441 ms 488.678 ms 460.236 ms
2 * * *
3 * * *
4 * * *
5 * * *
From windows client when on server tun adapter has a static IP:
Tracing route to 192.168.0.252 [192.168.0.252]
over a maximum of 30 hops:
1 10 ms 1 ms 14 ms 192.168.3.1 [192.168.3.1]
2 2 ms 2 ms 1 ms 192.168.0.252 [192.168.0.252]
From android when on server tun adapter has a static IP:
busybox traceroute 192.168.0.252
traceroute to 192.168.0.252 (192.168.0.252), 30 hops max, 38 byte packets
1 192.168.3.1 (192.168.3.1) 312.775 ms 278.626 ms 409.668 ms
2 * * *
3 * * *
4 * * *
busybox traceroute -I 192.168.0.252
traceroute to 192.168.0.252 (192.168.0.252), 30 hops max, 38 byte packets
1 192.168.3.1 (192.168.3.1) 277.923 ms 478.668 ms 399.933 ms
2 * * *
3 * * *
4 * * *
So the question to experts in linux (and maybe android) - why the trace does not succed from Android? Is this a busybox command problem? Or in linux is the same and this is the behavior? However:
busybox traceroute 178.17.163.132
traceroute to 178.17.163.132 (178.17.163.132), 30 hops max, 38 byte packets
1 169.254.220.180 (169.254.220.180) 392.150 ms 448.578 ms 569.977 ms
2 server_public_ip.33 (server_public_ip.33) 529.724 ms 519.836 ms 559.784 ms
3 195.22.224.2 (195.22.224.2) 479.950 ms 479.859 ms 529.846 ms
4 195.22.253.10 (195.22.253.10) 499.817 ms 499.817 ms 549.865 ms
5 178.17.163.130 (178.17.163.130) 489.899 ms 469.757 ms 489.960 ms
6 * * *
7 * * *
8 * * *
It's definatelly passing behiond OpenVPN server on going to internet. But the last scop is missed.
