Fixed
Status Update
Comments
js...@android.com <js...@android.com>
mi...@gmail.com <mi...@gmail.com> #2
The issue still exists in Android 4.4.1. Tested with strongSwan VPN Client 1.3.3.
mi...@gmail.com <mi...@gmail.com> #3
Android 4.4.2 (on Nexus 5) doesn't seem to solve it either.
gu...@gmail.com <gu...@gmail.com> #4
For me connecting to openVPN server both IPv4 and IPv6 go through the tunnel on Android 4.3 using OpenVPN for Android.
But on KitKat (4.4 and 4.4.2, exact same app+settings as in 4.3) IPv6 does not work anymore, looking with Wireshark shows: no IPv6 in the tunnel...
But on KitKat (4.4 and 4.4.2, exact same app+settings as in 4.3) IPv6 does not work anymore, looking with Wireshark shows: no IPv6 in the tunnel...
d....@gmail.com <d....@gmail.com> #5
I am facing the more general problem, no default routes at all for VPN, described in https://code.google.com/p/android/issues/detail?id=65738
rg...@google.com <rg...@google.com> #6
Internal issue 36949180 created to track this.
gu...@gmail.com <gu...@gmail.com> #7
[Comment deleted]
gu...@gmail.com <gu...@gmail.com> #8
On 4.4.3 ipv6 still does not go into the tunnel after connecting with openVPN
ip -6 route
shows there's no route for the tunnel interface
after manually adding route:
ip -6 route add ::/1 dev tun0
it works..
ip -6 route
shows there's no route for the tunnel interface
after manually adding route:
ip -6 route add ::/1 dev tun0
it works..
pe...@googlemail.com <pe...@googlemail.com> #9
As nobody in the Android project seems to care for this class of defects, I suggest to remove VPN support from Android officially!
BTW, in contrast to this topic's subject, VPNService even fails to route (at least IPv6 traffic) through a VPNService if the target was reachable without VPN. It fails to update routing tables and whatever is intended with tagged routing only leads traffic disruption.
BTW, in contrast to this topic's subject, VPNService even fails to route (at least IPv6 traffic) through a VPNService if the target was reachable without VPN. It fails to update routing tables and whatever is intended with tagged routing only leads traffic disruption.
ar...@rfc2549.org <ar...@rfc2549.org> #10
@9 Android needs IPv6 NAT support for VPNService and IPv6. Unfortenately the Android kernel that are used to toaday lack IPv6 NAT.
pe...@googlemail.com <pe...@googlemail.com> #11
@10 thanks for the information. This could have taken into consideration before changing a framework for building VPN clients that used to work just fine. Personally I would never have missed NAT over VPN. I'd strongly advice to never open a VPN on Android device level for other devices via tethering!
ab...@gmail.com <ab...@gmail.com> #12
Thanks for the advice.
we...@gmail.com <we...@gmail.com> #13
Is it possible to make an xposed module that could fix this issue?
ar...@rfc2549.org <ar...@rfc2549.org> #14
@13 I have have xposed you probably have root; if you have root you can also use the workaround of @6
ec...@gmail.com <ec...@gmail.com> #15
This issue has been around for over a year. Why has it not been resolved
je...@gmail.com <je...@gmail.com> #16
I experienced this issue on Android 4.4.4 on a Nexus 5 with the strongSwan app.
Now after upgrading to Android 5.0, both IPv4 and IPv6 work inside the tunnel, even when I am on an IPv4–only network.
Now after upgrading to Android 5.0, both IPv4 and IPv6 work inside the tunnel, even when I am on an IPv4–only network.
rg...@google.com <rg...@google.com> #17
Jeremy, you confirm that this issue is fixed on 5.0 for you?
je...@gmail.com <je...@gmail.com> #18
As far as I can tell, yes.
IPv6 inside the tunnel was broken on 4.4.4, but works on 5.0. Same version of the strongSwan app, and the same server configuration.
You may want to collect more data before marking this one as closed though. :-)
IPv6 inside the tunnel was broken on 4.4.4, but works on 5.0. Same version of the strongSwan app, and the same server configuration.
You may want to collect more data before marking this one as closed though. :-)
sl...@gmail.com <sl...@gmail.com> #19
IPv4 and IPv6 are now routed inside an OpenVPN tunnel. Like Jeremy, was not working since 4.4.x and now works fine in 5.0.
su...@gmail.com <su...@gmail.com> #20
So apps like drony, psiphon, shadowsocks, are working okey on upgraded 5.0 devices?
Not that is related to ipv6 routing but something is changed on 5.0 that makes problems.
Not that is related to ipv6 routing but something is changed on 5.0 that makes problems.
rg...@google.com <rg...@google.com> #21
Supp.Sandrob, what problem do you mean in #20?
Thx Jeremy. Glad we got something right on this. We did reach out to a number of VPN makers to verify things this round - maybe it helped.
Thx Jeremy. Glad we got something right on this. We did reach out to a number of VPN makers to verify things this round - maybe it helped.
Description
2. Connect to a VPN providing IPv6 connectivity
3. All IPv6 routes (apart from those directly on the interface) are unreachable.
I think this bug is realted to MTU. I think what happens is:
The route is lookuped up in the main route table. It is not found in there giving destinationen unreachable.
Therefore the packet is never sent, never gets the fwmark mark and rule
from all fwmark 0x3d lookup 61
cannot match the packet.