Open GoogleCodeExporter opened 9 years ago
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
بتاريخ ٠٩/٠٢/٢٠١٥ ١٢:٢٥ م، جاء من
<ics-openvpn@googlecode.com>:
connected to an IPv4-only VPN
automaitcally block IPv6.
Original comment by mohmoh20...@gmail.com
on 22 Feb 2015 at 1:14
Original issue reported on code.google.com by
lukas.ri...@gmail.com
on 15 Feb 2013 at 9:22