Disable local IPv6 while connected to an IPv4-only VPN

[GoogleCodeExporter]

When connecting to an IPv4-only VPN while connected to a dual stack local 
network, new connections to hosts reachable over IPv6 are still established 
using the local address (verified by accessing various "what is my IPv6"-sites 
- they all report my local address).

Is there a way to disable IPv6 connectivity for the duration of the VPN 
connection from within the VPN API? Cisco AnyConnect seems to be able to do it, 
since on the same network, when connecting to the Cisco VPN, IPv6 hosts become 
unreachable.

There should be at least an option for that, since unreachable IPv6 hosts are 
preferable to traffic being routed over the local address from a security 
viewpoint.

Or can this possibly fixed by a server-side setting, maybe by pushing an 
invalid IPv6 route?

If it helps, I can post the output of 'ip route' when connected to AnyConnect 
and OpenVPN later today - I don't have IPv6 connectivity right now.

Original issue reported on code.google.com by lukas.ri...@gmail.com on 15 Feb 2013 at 9:22

[GoogleCodeExporter]

I am not sure how the Cisco AnyConnect  manages to do that. Pushing an invalid 
IPv6 route is an option but that might break more than it helps.

An ip route while being connected to Anyconnect could be helpful

Original comment by arne@rfc2549.org on 15 Feb 2013 at 9:33

[GoogleCodeExporter]

I'll post the "ip route" output as soon as possible.

Meanwhile, I've opened a bug in the Android bug tracker 
(http://code.google.com/p/android/issues/detail?id=48417), but I don't think 
we'll see a reaction or even a patch anytime soon; a workaround with the 
existing API would be great.

Original comment by lukas.ri...@gmail.com on 15 Feb 2013 at 9:54

[GoogleCodeExporter]

I've done the tests; the important difference seems to be the following route 
configured by AnyConnect:

fe80::/64 dev wlan0  proto kernel  metric 256
fe80::/64 dev tun0  proto kernel  metric 256 (inserted)

ff00::/8 dev wlan0  table local  metric 256
ff00::/8 dev tun0  table local  metric 256 (inserted)

This seems to be a hack, but do the trick.

Could you possibly enable that as an advanced preference? I would be very 
grateful!

Original comment by lukas.ri...@gmail.com on 15 Feb 2013 at 5:11

[GoogleCodeExporter]

ff00:/8 is the ipv6 multicast range. e.g. the common 20xx range is not even 
include in ff00:/8. The client must be doing something else. It would be 
interesting to have a traceroute6. or ip route get someipv6 to show how it is 
really routed

Original comment by arne@rfc2549.org on 15 Feb 2013 at 5:24

[GoogleCodeExporter]

I've tried to use ip route get, but the Android version of ip doesn't seem to 
support that... Here are the relevant IPv6 routes with OpenVPN instead:

shell@android:/ $ ip -6 route show table all
2001:470:xxxx:1::/64 [my local IPv6 subnet's public address] dev wlan0  proto 
kernel  metric 256  expires 86400sec
fe80::/64 dev wlan0  proto kernel  metric 256
default via fe80::56xx:xxxx:xxxx:xxf5 [my local IPv6 uplink router's link-local 
address] dev wlan0  proto kernel  metric 1024  expires 1500sec
ff00::/8 dev wlan0  table local  metric 256

For Cisco, they are identical except for the two additional routes:
fe80::/64 dev tun0  proto kernel  metric 256 (inserted)
ff00::/8 dev tun0  table local  metric 256 (inserted)

It seems to work because the default gateway for IPv6 is always some address in 
the fe80::/64 network (default via fe80:...) and if that network is routed to 
the gateway, IPv6 connectivity breaks. Maybe routing ff00::/8 also breaks IPv6 
stateless autoconfiguration because it messes with neighbor and router 
discovery.

It really is a nasty hack (traffic for any IPv6 destinations will probably be 
forwarded to the VPN server and then hopefully dropped there - or worse), but 
it seems like the best that's possible with the API (as far as I understand it, 
the only thing that's possible is to add routes to the tun0 device).

Still, I would prefer that hack over the alternative, which is a partially 
insecure connection on any IPv6 Wifi network...

I've tried putting the routes in the OpenVPN settings, but they are rejected. 
It seems that this has to be solved by OpenVPN for Android manually inserting 
the false routes via the VpnService API.

Ideally, when that option is turned on, OpenVpn should drop all IPv6 packets on 
the client without transmitting them over the network (to save bandwidth and 
for cases where the server would forward those packets to its local network).

Original comment by lukas.ri...@gmail.com on 15 Feb 2013 at 10:07

[GoogleCodeExporter]

I think there something else which breaks IPv6 under Cisco Anyconnect. I alos 
have the linklocal (fe80::/64) and multicast (ff00::/8) on tun1 when using 
OpenVPN. Perhaps the Cisco VPN provider you with a nameserver which does not do 
IPv6 queries.

You can add the default route to tun0 and send IPv6 ICMP unreachable for all 
incoming packets. But that is a hack that still needs to be implemeted and I 
don't know how well it would work

Original comment by arne@rfc2549.org on 15 Feb 2013 at 10:41

[GoogleCodeExporter]

DNS responses still contain (unmodified) AAAA responses when using AnyConnect, 
so that can't be it... Their trick also seems to be implemented in the Android 
client, since OpenConnect on Linux also routes IPv6 traffic via the local 
connection just like OpenVpn.

I've now tried some false routes on my Linux host, "ip -6 route add ::/0 dev 
tun0" works just fine - all packets are forwarded to the VPN server, where they 
are dropped.

This route can't be pushed to the OpenVPN Android client, however - the log 
says "do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=1" and 
"add_route_ipv6(): not adding ::/0, no IPv6 on if (null)". Is IPv6 forwarding 
not available/enabled in the binary (tun-ipv6 not set)? If I manually enable it 
in the manual configuration options, the client crashes upon connection 
establishment.

So the only option to enable that route is manually setting it in the 
VpnManager's addRoute() method. Could you enable an expert option for that, or 
just build a version that does it by default? I'd be happy to test it.

Original comment by lukas.ri...@gmail.com on 16 Feb 2013 at 12:05

[GoogleCodeExporter]

The client should not crash. I am using an IPv6 enabled OpenVPN setup myself.

Can you send me the log and if generated the minidump?

Original comment by arne@rfc2549.org on 16 Feb 2013 at 1:22

[GoogleCodeExporter]

Sorry, I haven't had a chance to retry the setup until now. The log disappears 
before I have a chance to save it; how can I send a minidump?

Original comment by lukas.ri...@gmail.com on 6 Mar 2013 at 10:12

[GoogleCodeExporter]

The log should not disappear. Does the whole app crash or just openvpn?

Original comment by arne@rfc2549.org on 6 Mar 2013 at 10:17

[GoogleCodeExporter]

The whole app crashes, and I'm shown the Google report-a-bug dialog, with just 
a Dalvik stack trace (which I suspect is not very useful to you, since OpenVPN 
resides mainly as a binary executable?).

This only happens when pushing the false route from the server—just enabling 
tun-ipv6 in the client doesn't trigger it.

Original comment by lukas.ri...@gmail.com on 6 Mar 2013 at 10:22

[GoogleCodeExporter]

That stacktrace should be useful. If you report the bug via the google rport 
option I will see the stacktrace in the developer console. Or you can just send 
me the stacktrace. There must be something with the route you are pushing that 
trigger a bug in my UI.

Original comment by arne@rfc2549.org on 6 Mar 2013 at 11:19

[GoogleCodeExporter]

And if you can give me the exact push statement you are doing on the server 
that would be great too.

Original comment by arne@rfc2549.org on 6 Mar 2013 at 11:20

[GoogleCodeExporter]

Sorry, I haven't been able to look at my VPN issues for a while. I've now 
reconfigured my server to hand out bogus IPv6 addresses and routes to all 
clients by specifying 'server-ipv6 ::1/64' and 'tun-ipv6' on the server.

This has the desired effect - IPv6 connectivity breaks for all connected 
clients, instead of bypassing the VPN.

I haven't been able to reproduce the crash so far.

Original comment by lukas.ri...@gmail.com on 29 Mar 2013 at 4:11

[GoogleCodeExporter]

I solved the problem by installing iptables and then adding the following to my 
/data/local/userinit.sh:
ip6tables -A OUTPUT -j DROP
ip6tables -A INPUT -j DROP

Original comment by florian....@fnkr.net on 19 Apr 2014 at 9:55

[GoogleCodeExporter]

This issue is still happening in the Android AnyConnect client.  I found that I 
normally have IPv6 capability, but when I connect to the ASA VPN, I can no 
longer use IPv6 on the internet.  It's like the ASA is creating a null IPv6 
split tunnel, and redirects all IPv6 traffic where it then gets dropped.

Bottom line, when I'm connected to the ASA VPN with my phone, a lot of other 
functionality stops working.

Is there a workaround for this?

Original comment by br...@mainsequence.net on 1 Oct 2014 at 10:40

[GoogleCodeExporter]

I just realized, if the Anyconnect software is creating a FF00::/8 route, that 
would suck up all multicasts.  Since IPv6 uses FF02:: instead of ARP to find 
neighbors, that entry would kill any neighbor discovery.  I'm betting the phone 
can no longer find any IPv6 next hop once that happens.

Original comment by br...@mainsequence.net on 1 Oct 2014 at 10:43

[GoogleCodeExporter]

For reference in Android 5.0 deselecting "Allow LAN access" now automaitcally 
block IPv6.

Original comment by arne@rfc2549.org on 9 Feb 2015 at 9:25

[schwabe]

I will not implement this since it is not needed on my devices with 5.0+. That said implementing this in OpenVPN should be /relatively/ straight forward by sending icmpv6 unreachable.