Opened 2 years ago

Closed 16 months ago

#614 closed Bug / Defect (worksforme)

Connect on iOS 9: IPv4 routing doesn't work with dual-stack

Reported by: ValdikSS Owned by: jamesyonan
Priority: major Milestone:
Component: OpenVPN Connect Version:
Severity: Not set (if unsure, select this one) Keywords: connect, ios 9, ipv6, tun-ipv6
Cc: samuli

Description

IPv4 routing on iOS 9 is broken if IPv6 is enabled inside the tunnel.
The tests were done with tun-ipv6 and redirect-gateway activated and all the IPv4 traffic bypasses VPN gateway, while IPv6 works fine.
Works as expected without tun-ipv6. Doesn't work with tun-ipv6 but no IPv6 address.

Attachments (1)

0001-Add-option-push-suppress-ipv6-to-stop-sending-IPv6-i.patch (4.8 KB) - added by cron2 2 years ago.
Add option to 2.x git master to selectively suppress sending IPv6 options in push reply

Download all attachments as: .zip

Change History (21)

comment:1 Changed 2 years ago by cron2

  • Cc samuli added
  • Owner set to jamesyonan
  • Status changed from new to assigned

comment:3 Changed 2 years ago by Tibbo

I can confirm this bug.

When running dual stack IPv4+IPv6 server side there is no IPv4 traffic routed through the tunnel on iOS9. IPv6 is working fine though. Haven't seen the issue before iOS9 were released.

comment:4 Changed 2 years ago by CallumA

I can also confirm this.

All IPv4 traffic just goes outside the tunnel with IPv6 enabled, and it appears the VPN is connected and working everywhere else. This is a pretty critical bug given that you may think you're connected when actually lots of traffic is leaking. Even with Seamless Tunnel enabled traffic still goes outside the tunnel which is very dangerous.

It essentially breaks OpenVPN on iOS, I've actually had to disable IPv6 on my OpenVPN server just to keep iOS 9 clients from leaking data.

comment:5 Changed 2 years ago by cron2

I can not influence how long it will take to sort out the issue between Apple and James - but might be able to code a quick workaround.

Would it help being able to tell the server (via ccd/ or client-connect script/plugin) "no-ipv6-push" (or something like that), which would then stop sending tun-ipv6 and ifconfig-ipv6 towards that client? A quick patch would not be too complicated, I think.

comment:6 Changed 2 years ago by ValdikSS

cron2, yes please. Actually, tun-ipv6 is not pushed or could be reset, so it's only necessary to be able to prevent ifconfig-ipv6 from pushing.

comment:7 Changed 2 years ago by cron2

Now this is interesting. I have an iPad Air (1) lying before me, with IOS 9.0.2, which handles IPv4 and IPv6 in parallel perfectly fine. This is OpenVPN 1.0.5 build 177.

I am not pushing redirect-gateway, just a few individual routes + ifconfig - this is what the server says:

Oct 19 19:20:07 gentoo openvpn[14453]: cron2-ithing/193.149.x.x SENT CONTROL [cron2-ithing]: 'PUSH_REPLY,ifconfig-ipv6 2001:608:3:814::f00d/64 2001:608:3:814::1001,route 194.97.144.0 255.255.255.0,route 193.149.44.0 255.255.255.0,route 195.30.3.0 255.255.255.0,route-ipv6 2001:608::/32,compress snappy,tun-ipv6,route-gateway 194.97.145.73,topology subnet,ping 10,ping-restart 30,echo,dhcp-option DNS 195.30.0.2,ifconfig 194.97.145.77 255.255.255.248' (status=1)

and checking connections (safari going to http://v6.de) I can see that it's indeed using VPN for both IPv4 and IPv6.

Another test with "push redirect-gateway" (in addition to the list above, with "no flag" or with "def1") confirms the problem, though - if I do that, even traffic to the IPv4 routes specifically listed goes via normal Internet, only v6 through the tunnel.

Yet another test pushing two /1 routes

 push "route 0.0.0.0 128.0.0.0"
 push "route 128.0.0.0 128.0.0.0"

makes it work perfectly fine for me - IPv4 ("the whole Internet") and IPv6 both go into the tunnel.

So - ValdikSS, CallumA, what is your config? Are you pushing individual routes or "redirect-gateway"? (From the MTU ticket, I assumed you would pushing individual routes, not redirecting all - but that "should work")

[patch is being tested, which is how I discovered that the problem does not always happen for me :-) ]

comment:8 Changed 2 years ago by cron2

Interesting enough, if I do "redirect-gateway" and do *not* send an ifconfig-ipv6, the VPN API will block all IPv6 access. So it's good enough to ensure no IPv6 traffic leaks around, but of course not overly satisfying if you've spent time to actually make IPv6 *in* the VPN work nicely...

Patch done, sent to list - not totally pretty, but gets the job done, filtering out *all* IPv6 related push options (tun-ipv6, ifconfig-ipv6, route-ipv6). To be attached.

Changed 2 years ago by cron2

Add option to 2.x git master to selectively suppress sending IPv6 options in push reply

comment:9 Changed 2 years ago by CallumA

My config was using 'push "redirect-gateway def1 bypass-dhcp"' (and removing "bypass-dhcp" makes no difference). Commenting that out and using your two /1 route workaround does appear to work.
Good catch!

comment:10 Changed 2 years ago by ValdikSS

Thanks, cron2! Will try two routes trick for iOS.

comment:11 Changed 23 months ago by cron2

my ipad got iOS 9.1 today, but the issue still persists - read: pushing "redirect-gateway def1" + "ifconfig-ipv6" makes it send IPv4 traffic outside the tunnel

comment:12 Changed 23 months ago by racemoto

I can also confirm this issue in a dual stack configuration for an iPhone 6S running iOS 9.1 (or any earlier build of 9.x).

However, my iPad Air running iOS 9.1 does not show any problems (and did not with the earlier builds of 9.x).

Please let me know if I can support you guys (e.g. by testing a development version).

comment:13 Changed 22 months ago by ValdikSS

Any updates?

comment:14 Changed 22 months ago by mediaguy

Is it fixed on iOS 9.2?

comment:15 Changed 22 months ago by ValdikSS

Just tested, no.

comment:16 Changed 22 months ago by fkooman

It seems the solution is documented in the iOS FAQ, you need the undocumented redirect-gateway ipv6: https://docs.openvpn.net/docs/openvpn-connect/openvpn-connect-ios-faq.html

Preliminary testing suggests that this makes iOS work again and at least doesn't break Windows, I didn't test Android yet.

server 10.10.10.1 255.255.255.0
push "redirect-gateway"

server-ipv6 fd00:4242:4242::/64
push "redirect-gateway ipv6"
push "route-ipv6 2000::/3" 
Last edited 22 months ago by fkooman (previous) (diff)

comment:17 Changed 21 months ago by kvic

Tested the solution found by fkooman above. Works in iOS 9.2

comment:18 Changed 21 months ago by doomedraven

thanks fkooman, just got it working on 9.2, my conf, the private key and rest was imported in secure way to keychain, as specified in your link

client
dev tun
proto udp
remote vpn_node 1194
float
cipher AES-256-CBC
comp-lzo yes
keepalive 15 60
auth-user-pass
redirect-gateway ipv6
mute-replay-warnings
ns-cert-type server
key-direction bidirectional
ca ca.cert
cert cert.cert
key private.key
resolv-retry infinite
nobind
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
<removed>
-----END OpenVPN Static key V1-----
</tls-auth>

nothing was modified on server, so server with normal configuration

comment:20 Changed 16 months ago by cron2

  • Resolution set to worksforme
  • Status changed from assigned to closed

--push-remove made it to git master today:

commit 970312f185012341cc5bcc9492ab3e1413c7b3c7
Author: Gert Doering <gert@…>
Date: Mon May 16 12:13:04 2016 +0200

Implement push-remove option to selectively remove pushed options.

so, just to conclude on this - if you want to selectively turn off IPv6 for a client, add this to ccd/$client or output it from --client-connect

push-remove tun-ipv6
push-remove ifconfig-ipv6
push-remove route-ipv6

and none of the IPv6 related options will be sent (this is what the patch above did when you did --suppress-ipv6 - too specific patch, thus this one is more general)

As there is not much we can do about Apple, but we at least have multiple documented workarounds for their VPN weirdness, I think I'll close this ticket now. (There is a new iOS version coming, so if someone want to test variants on this, please add to the ticket what works and what doesn't)

Note: See TracTickets for help on using tickets.