Connection timeout when using cellular data

[bryangwilliam]

I have been fighting with this for awhile so it would be great if someone could shed some light on this...

I have OpenVPN Connect set up on my iPhone and it works great as long as I am connected to wifi, however when I try it using my cellular data plan the connection times out. I have contacted my service provider (AT&T) multiple times to see if they can see what is happening, but they are confident there is nothing they are doing that would prevent the traffic from flowing normally.

This morning I hooked my phone up to my computer to view the console logs during successful and unsuccessful connection attempts and see if I could find anything different between the two from the phone's perspective. Here is what I discovered:

This is the log at the beginning of a successful connection (on wifi):
Sep 23 14:51:38 Ichabod configd[55] <Notice>: network changed.
Sep 23 14:51:38 Ichabod OpenVPN[1010] <Warning>: VPNConfig: setEnabled:1
Sep 23 14:51:38 Ichabod vpnagent[1075] <Notice>: VPN Plugin starting
Sep 23 14:51:38 Ichabod vpnagent[1075] <Error>: VPNTunnelInit
Sep 23 14:51:38 Ichabod vpnagent[1075] <Error>: VPNTunnelInit: tun sock=2
Sep 23 14:51:38 Ichabod vpnagent[1075] <Error>: VPNTunnelInit: Service ID = 1A280649-106D-469E-BED1-39A1C23BE71F
Sep 23 14:51:38 Ichabod vpnagent[1075] <Error>: OpenVPNCoreThread service_id=1A280649-106D-469E-BED1-39A1C23BE71F tun_sock=2
Sep 23 14:51:38 Ichabod vpnagent[1075] <Error>: VPNTunnelEnvironmentEvent: IPC ATTACHED

And this is the log at the beginning of an unsuccessful connection (on cellular data):
Sep 23 14:05:49 Ichabod configd[55] <Notice>: network changed.
Sep 23 14:05:49 Ichabod OpenVPN[1010] <Warning>: VPNConfig: setEnabled:1
Sep 23 14:05:49 Ichabod kernel[0] <Debug>: Sandbox: OpenVPN(1010) deny iokit-get-properties IOMACAddress
Sep 23 14:05:49 Ichabod vpnagent[1045] <Notice>: VPN Plugin starting
Sep 23 14:05:49 Ichabod kernel[0] <Debug>: Sandbox: OpenVPN(1010) deny iokit-get-properties IOMACAddress
Sep 23 14:05:49 Ichabod vpnagent[1045] <Error>: VPNTunnelInit
Sep 23 14:05:49 Ichabod vpnagent[1045] <Error>: VPNTunnelInit: tun sock=2
Sep 23 14:05:49 Ichabod vpnagent[1045] <Error>: VPNTunnelInit: Service ID = 1A280649-106D-469E-BED1-39A1C23BE71F
Sep 23 14:05:49 Ichabod vpnagent[1045] <Error>: OpenVPNCoreThread service_id=1A280649-106D-469E-BED1-39A1C23BE71F tun_sock=2
Sep 23 14:05:49 Ichabod vpnagent[1045] <Error>: VPNTunnelEnvironmentEvent: IPC ATTACHED

It looks like OpenVPN is trying to access information about the network connection but while on cellular data the IOS "Sandbox" is preventing it and possibly causing the connection to fail.

My device is an iPhone 5 and I am running IOS 7 (although I had the same issues on IOS 6). Has anyone else experienced anything like this and is there a way to fix it? Looks to me like it could be either an error in OpenVPN Connect or in IOS (or could possibly not be an error at all and I am barking up the wrong tree), however after scouring the Internet I have not found much to go on.

[rsmits]

I experienced the same issue on a Dutch Vodafone cellular network. (Both 2G and 3G.) However, on Swedish Telia network OpenVPN service is 'paused', preventing any network traffic on cellular. Wifi works fine, no paused service here. I can switch off VPN and switch it back on, then it works again for a short while. The Dutch and Swedish network is tested with the same iPhone 4s running IOS7.

[bryangwilliam]

I have more information to add:

It would appear that this is not an iPhone issue after all. After getting nowhere with my phone company and not being able to stir up any ideas here, I ended up trying it out on my wife's phone (Samsung Galaxy 2, also using the AT&T network). Sure enough, exact same scenario: on WiFi the app works great, however switching over to the cellular data network makes it so that the phone cannot talk to my VPN server. This leaves me to believe that it couldn't possibly be the phone, as the situation was duplicated on another completely unrelated device.

Additionally, I tried importing the exact same config file into Arne Schwabe's app "OpenVPN for Android" and it was able to connect no trouble at all, both on WiFi and mobile data. This kind of rules out the network as the culprit. Considering the network is able to carry the same traffic without any issue when using a different app, I am inclined to blame OpenVPN Connect, however here is the final mystery: I have a co-worker who uses an iPhone on the Verizon network and he is able to use the OpenVPN Connect app without any trouble on both wireless and mobile data connections. Which leaves me with only one logical conclusion: my issue is caused by a bug (or perhaps a purposely left out feature) in OpenVPN Connect that is only evident on the AT&T network (and perhaps others set up in a similar manner, although I have no means to test them).

Which leads me to a burning question: are there any AT&T customers out there that have successfully connected using OpenVPN Connect on the mobile data network? If so, did you have to do anything in particular?

I have been scouring the Internet for any little morsel of information on this and have come up empty handed, so if anyone has anything they can add to the discussion I would certainly be appreciative. I may just need to figure out how to submit a bug report and see if the developers can reproduce and eventually fix it.

[rsmits]

I'm starting to think, since the issue showed up on IOS7 for me... A lot of providers updated operator settings for IOS7, including mine in the Netherlands. When I switched to my Swedish operator, I also received an operator update.
What about your collegue with iPhone on a different network, where the issue does not occure. Did he receive an operator update as well? Is he running IOS7?

I'm not an expert in this area, but I can imagine operators make use of new networking functionality in IOS7 causing this issue. If that's the case, then I agree that it can be fixed within the app.

[BellComp]

Did anybody figure out any solutions or work-arounds for this? I have a similar issue. OpenVPN Connect worked perfectly, even after updating to iOS7. The problem started after updating to a newer version of OpenVPN Connect (I'm not sure of the exact version, but the most current version as of this posting). I can easily duplicate the issue, by switching back and forth between WiFi and cellular data (AT&T). Another iPad has the same issue. I believe this other iPad has Verizon data, but I can't be 100% sure. The OpenVPN server is on a pfSense firewall. It works perfect from the Ipad over WiFi and from a PC. The odd thing is, that I have many other OpenVPN profiles, that connect to other servers, that work perfectly over cellular data. I have tried changing many settings to no avail. This is the only one that is having an issue. Here is what the log shows:

2013-11-18 08:37:34 EVENT: CONNECTION_TIMEOUT [ERR]
2013-11-18 08:37:34 EVENT: DISCONNECTED
2013-11-18 08:37:34 Raw stats on disconnect:
BYTES_IN : 9616
BYTES_OUT : 45042
PACKETS_IN : 72
PACKETS_OUT : 101
KEEPALIVE_TIMEOUT : 1
CONNECTION_TIMEOUT : 1
N_RECONNECT : 1

[BellComp]

I have confirmed that the Andriod OpenVPN Connect app acts the same. But when using OpenVPN for Andriod (by Arne Schwabe) works perfect over cellular data.

This seems to be an issue with the OpenVPN Connect app for Andriod and iOS over cellular data. It's possible that this is also a server side issue. Any suggestions?

[redradioflyer]

Sorry guys but I'm going to throw a wrench in your theory.
I have an iPhone 5 (iOS 7.0.4) on AT&T's network with the current version of the OpenVPN app (v1.0.1).

I am able to connect to my VPN server using wifi and cellular data.
However, I have noticed that --nobind and --float (used on server and client) do not allow the client to stay connected to the VPN when switching between cell data and wifi. It also appears to take longer than normal to reconnect if this data mode transition is made with the VPN on. Almost as if the fist reconnect attempt fails, but the second attempt goes through.

I'm curious as to the problem that could be causing this, but I'm not convinced that the OpenVPN app is to blame in this case.

[foreverzer0]

iPhone 5 on AT&T as well, OVN 1.0.1, same issue (and I've posted about this in another thread topic14055.html which didn't have any results, and another individual that collected several similar threads about this posted on there stating so topic14055.html).

Sorry guys but I'm going to throw a wrench in your theory.
I have an iPhone 5 (iOS 7.0.4) on AT&T's network with the current version of the OpenVPN app (v1.0.1).

I am able to connect to my VPN server using wifi and cellular data.
However, I have noticed that --nobind and --float (used on server and client) do not allow the client to stay connected to the VPN when switching between cell data and wifi. It also appears to take longer than normal to reconnect if this data mode transition is made with the VPN on. Almost as if the fist reconnect attempt fails, but the second attempt goes through.

I'm curious as to the problem that could be causing this, but I'm not convinced that the OpenVPN app is to blame in this case.

Have you tried turning on VPN while on wifi, then turning off wifi? Does it reconnect properly? Perhaps it's commercial VPN configurations not allowing it?

[redradioflyer]

iPhone 5 on AT&T as well, OVN 1.0.1, same issue (and I've posted about this in another thread topic14055.html which didn't have any results, and another individual that collected several similar threads about this posted on there stating so topic14055.html).

Have you tried turning on VPN while on wifi, then turning off wifi? Does it reconnect properly? Perhaps it's commercial VPN configurations not allowing it?

Yes, that is the exact procedure I used to test the VPN's ability to maintain a connection, and no it could not maintain the connection. I don't know what u mean about the commercial VPN configuration not allowing it. I am the administrator for the VPN server and I have not put any such limitations in place (that I am aware of!) To the contrary, this is an annoying problem I'd like to resolve. The VPN shouldn't cut out and need to be reconnected all of a sudden just because somone walked into or out of a wifi area...

Regarding the other problem mentioned in the posts you cited (VPN disconnects when iPhone is in idle/sleep mode) my understanding from scouring apple and VPN forums is that this is a "feature" enforced by iOS for the encryption processes and cannot be circumvented. To save battery life iOS stops the required encryption and decryption processes when the phone is asleep. No iPhone VPN by any provider can function while the iPhone is asleep. This is inherent in the device and there is even a proof of concept device that can capture the "leaked" data sent while the iPhone is asleep (or before the VPN is manually re-activated) called CreapyDOL.

[bincat]

I have been unable to connect to my VPN client as well on iPad

I am unable to connect to VPN when I am on Verizon's Cellular plan on my iPad and haven't been for a very long while now, and I don't think it is due to my frames are being fragmented, I believe on iOS 7.0.2, they have made deliberate efforts to break/nullify a VPN connection if it is encrypted traffic.

Unfortunately I won't be able to access the iPad's modem since the Mav5 modem inside it is built in, unlike the Dongle version. So I will have to buy a Verizon Data enabled Dongle and I am going to try and debug this by collecting a QXDM log of the devices modem itself by collecting PPP Logs from Data Services, and then convert the ISF log to UM logs using PPP Extractor and then use Wireshark to find out that the &nbsp; is going on. Thankfully I know how to enable QXDM diagnostic logging of modem inside the Verizon Data Dongle.

[redradioflyer]

I believe on iOS 7.0.2, they have made deliberate efforts to break/nullify a VPN connection if it is encrypted traffic.

I find that really hard to believe. It would completely destroy Apple's ability to attract corporate and government customers.

I have been using an encrypted VPN (certificate based, AES-256-CBC, dh2048, and tls-auth) in iOS 7.0.2, 7.0.3, and 7.0.4.

I don't buy these conspiracy theories, and I don't think they're constructive. It sounds like something in how iOS manages these processes has changed... Let's focus on finding and understanding it.

[bryangwilliam]

I have verified that the initial packets are being received by the server. The server logs a message for "TLS: Initial packet", but then it just sits there waiting and says that the TLS handshake failed. It seems to me like the server is saying "Go ahead, I'm listening" and then the client just stops responding.

The most interesting point of all this to me is that "Sandbox" error I mentioned before in the console on the iPhone:
Sep 23 14:05:49 Ichabod kernel[0] <Debug>: Sandbox: OpenVPN(1010) deny iokit-get-properties IOMACAddress

As I said, that seems to be the only noticeable difference between the two connection attempts, so I cant help but think that has something to do with it. I know nothing about iOS app development, but that seems to me like the app is requesting information from iOS about the connection that it is supposed to use but is getting denied. I would be interested to see if there is a similar message in the Android logs, but so far have not found a way to find that out.

[markymarrow]

I have verified that the initial packets are being received by the server. The server logs a message for "TLS: Initial packet", but then it just sits there waiting and says that the TLS handshake failed. It seems to me like the server is saying "Go ahead, I'm listening" and then the client just stops responding.

The most interesting point of all this to me is that "Sandbox" error I mentioned before in the console on the iPhone:
Sep 23 14:05:49 Ichabod kernel[0] <Debug>: Sandbox: OpenVPN(1010) deny iokit-get-properties IOMACAddress

The sandbox message shouldn't actually break anything, it will simply return a fake MAC address.
UDP can easily be problematic on certain connections where there's a lot of NAT involved, as often appears to be the case with cellular connections - and I've seen it manifest numerous times as receiving an initial packet but very little else.
If you still haven't tried using TCP as your transport instead, you really should give it a go.

[jamesyonan]

Any info on whether this problem persists with OpenVPN Connect 1.0.2?

Also, regarding the "Pause" state, OpenVPN Connect only enters this state when it gets a notification from iOS telling it that the network is unavailable. Unless you manually disconnect and reconnect, OpenVPN will stay in the Pause state until it gets another notification from iOS that the network is available, in which case it will attempt to reconnect.

OpenVPN Connect on Android also has the same behaviour, however it keys off of different (but roughly equivalent) Android notifications about network availability.

One subtle change between 1.0.0 and 1.0.1 is that in 1.0.1+ when OpenVPN gets a notification from iOS about a network reconfiguration (such as WiFi <-> Cellular data transition), it will attempt an immediate reconnect on the newly available network. In 1.0.0 it would ignore network reconfiguration notifications and stay connected to the current network until a timeout or loss-of-connection forces a reconnect. The 1.0.1+ behaviour is designed to switch off of cellular data and onto WiFi at the first available opportunity, to reduce unnecessary cellular data usage.

James

[neujeff]

Take a look at this from TMobile: http://support.t-mobile.com/thread/60804?tstart=0

I tried going back to IPv4 on Verizon, but I still have the disconnect problem.

[tubby_bartles]

I have this only when the cell shows connected but no data actually flows (happens on Verizon and AT&T occasionally when the signal is weak).

The only issue I have is that OpenVPN just times out rather than keeping trying until the signal comes back. It doesn't seem to do that any other time.

[tubby_bartles]

By the way, for reference, it times out even though I have the setting "Connection Timeout" set to "None". It does eventually stop retrying anyway, so when you come back to use the phone after going through a bad connectivity patch in which it also changes network, it simply is no longer VPN. The "connect on wake" doesn't kick in anymore, and the VPN is done until I manually turn it on again.

[Deimos]

I'm have same/very similar problems - actually two issues

1. I've found that changing networks loses the old connection and does not establish a new connection over the new network. Due to building issues I have a lot of WiFi networks in my house - so moving between rooms often changes WiFi network and OpenVPN always disconnects on loss of one network and fails to connect on new network. Manually go into the app and switch the "connect" switch and it immediately connects without problems.

2. Same happens on moving out of WiFi and into GSM - loses VPN connection and fails to establish a new connection. Except that in the case of a GSM data connection, over a 3G connection I cannot get any connection through. Logs don't show anything but every connect attempt immediately fails, no delay or timeout - like it's not seeing the 3G as a data network (other network functions work, though obviously not through the VPN). However, move into 4G coverage and try connecting and it immediately connects fine.

I've tried with Seamless Tunnel enabled and disabled and no difference. With Seamless Tunnel enabled also tried with and without Level 2 Reachability enabled and disabled and no difference - though all those tests have only been done on WiFi (i.e. not Cellular)

[fjser1976]

Has anyone found a solution or cause to this issue of connections working fine over WiFi but not over celluar? We are aware of the t-mobile network issues, but this is happening for us over Verizon and AT&T as well. It works fine when connecting to one server at one location, but fails to connect at another location. We are running iOS 11.x.