Change of default gateway doesn't work

[yvesf]

Change of default gateway doesn't work

[angrierhorse]

I am also having this issue. I can ping my iodined server but routing is not set up automatically.

[yvesf]

Thank you for the confirmation. However, I'm still unable to reproduce this bug with my device.

For setting the default route there is a log statement in, in src/org/xapek/andiodine/IodineVpnService.java Line 310-311

Log.d(TAG, "Set default route");
b.addRoute("0.0.0.0", 0); // Default Route

which results in a logging message like:

D/VPN_SERVICE( 6565): Handshake successful
D/VPN_SERVICE( 6565): Send: Intent { act=org.xapek.andiodine.IodineVpnService.STATUS_CONNECTED (has extras) }
D/VPN_SERVICE( 6565): Build tunnel for configuration: ip=172.16.1.11 netbits=24 mtu=1130
D/VPN_SERVICE( 6565): Set default route
D/VPN_SERVICE( 6565): Build tunnel interface
D/Vpn     (  550): setting state=CONNECTING, reason=establish
D/VpnJni  (  550): Address added on tun0: 172.16.1.11/24
D/VpnJni  (  550): Route added on tun0: 0.0.0.0/0

and results in a routing configuration like

shell@p880:/ $ ip route
0.0.0.0/1 dev tun0  scope link 
default via 192.168.1.1 dev wlan0 
128.0.0.0/1 dev tun0  scope link 
172.16.1.0/24 dev tun0  proto kernel  scope link  src 172.16.1.11 
192.168.1.0/24 dev wlan0  scope link 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.225 
192.168.1.1 dev wlan0  scope link 

Maybe you can verify this with your device. Currently I've no idea whats wrong here.

[yvesf]

This could be related: https://code.google.com/p/ics-openvpn/issues/detail?id=161 and https://code.google.com/p/android/issues/detail?id=35431

[angrierhorse]

yvesf, thank you for replying. I will attempt to create a proper bugreport instead of a 'me too!'. I will take a look at it this weekend.

[bjoern-r]

on my device the ip r output shows that the default route is still set to my default gateway however traffic goes via the tunnel. Of course you have to enable masquarding on the tunnel server box.

[faxm0dem]

I have the same issue, but only since the NTU bug: when I upgraded my CM to Android 4.4.4.
With Magictunnel all works seamlessly.

[yvesf]

Magictunnel is technically equivalent to executing the iodine binary by hand (in fact the very same binary, at least we hope it's the same, is included in the repository).
I recommend not to use apps requiring root without thoroughly checking for security implications, if you can't trust the binary-apk provider 100% then at least build it yourself.

andiodine uses the Android VPN Framework to configure the network interface (ip-addres,gateway/routes). On contrary, the iodine binary calls the system utilities directly, this way bypassing the android system configuration (i don't think that this is a good idea, this is like messing with 'ip addr/ip route' on interfaces managed by linux network-manager daemon).

Since using the VPN Framework requires only the relevant android.permission.VPN..., andiodine can execute as a usual, restricted user-level process. Different from using iodine directly, which requires root-privileges to open and configure the tun-device, hence the whole binary must execute with system-privileges. In my opinion every application working like this is subverting the android permissions model and should carry a big fat warning sign, "Experimental: no to be used on production devices". Not speaking of the very small percentage of 'rooted' devices actually supporting this type of app.

In Android 4.4.x there seem to be some bug related to setting MTU (here the case of setting the interface's MTU lower than the minimum required for ipv6-iptables rules, is not correctly handled, see #4). Also there is this issue about setting the default route (this issue #1, reason unknown).

To push the solution of this issue about the default gateway, please attach/link your 'adb logcat' log of the connection process. Also the output of 'ip addr show' and 'ip route show' might be helpful. Please censor your private addresses if needed.

[faxm0dem]

I am aware of the differences with Magictunnel, and I didn't mean to offend - I know andiodine is a far better design. I was merely refering to the other project to indicate that my server setup (especially the ip.forward setting) was fine.

[mcastillof]

Routing is working for me, and I can browse the web without problem (just a bit slow).

Remember to allow IP forwarding in your kernel with:
# echo 1 > /proc/sys/net/ipv4/ip_forward

And configure iptables to forward the packets:

# iptables -A FORWARD -i dns0 -o eth0 -j ACCEPT
# iptables -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED  -j ACCEPT 
# iptables -t nat -A POSTROUTING  -o eth0 -j MASQUERADE

[yvesf]

unfortunately nothing can do about the speed :) Thanks for this feedback.

Just to be clear: @mcastillof is talking about the server-side in the comment above.

[segganeadel]

Same here can ping and ssh to server but no internet
Tried to change route same thing no Internet

Actually I'm curious how slowdns and your-freedom do it

[yvesf]

@segganeadel things you could try:

• check if it works from a linux machine with standard iodine
• adb shell on the phone to see if the routing wasn't set up properly (wrong/no default gateway)
• record the output of adb logcat of the connection process, put it in a gist and share it.
• tcpdump on the iodine interface on the server side to see if pings to an external address are arriving at the iodine server

I'm not sure what you mean by your last sentence. If you're asking about how the speed of the working tunnel will be: yes it will be quite slow.

[angrierhorse]

About 3 years and many android devices later I have revisited this.

It has finally dawned on me that the majority of the routing issues faced by users are due to NAT not being set-up on the server. Most of the online guides for getting a working iodine setup working omit this step.

See: http://ip-dns.info/

Specifically the last part about setting up NAT and IP masq.

Again, if your setup has the default route set correctly on the client and you can ping the server however no traffic appears to be getting through, make sure you have configured NAT and IP masq correctly on your server.

[yvesf]

I'm closing this as it's quiet old and the more or less solved. Thanks for all the contributions to this discussion.