Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#993 closed Bug / Defect (fixed)

iOS: long sleep leaves tunnel Dead on v.1.2.6

Reported by: nullbandit Owned by: Antonio Quartulli
Priority: blocker Milestone:
Component: OpenVPN Connect Version: OpenVPN Connect for iOS v1.2.6
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

The iOS sleep loop which puts app to background leaves the tunnel dead without any connectivity. IMO it's the iOS kernel which is leaving the OpenVPN app tunnel dead once the app has been pushed to background.
Tested this on Iphone 8P, Iphone 7, Iphone X all running 11.2.2 on OpenVPN v 1.2.6

  1. Connect to VPN (TCP)
  2. Push the side button to lock/sleep your iphone
  3. Let it stay for 10 mins or plus

You will see OpenVPN quickly comes back to indicate visually connected on the UI upper left or upper right corner. But actually the tunnel is dead with no traffic being able to pass through. My assumption here is, the iOS puts the OpenVPN app to background where in the tcp session goes to idle state without any traffic flowing through. When woken up from sleep the awake action tries to reuse the existing tunnel. The possibility here is either the server has closed the tunnel with no routes available to flow for the traffic, or the iOS has flushed all the routes to that flow path.

Visually the UI indicates the tunnel is active by showing the icon but the paths are long gone.

Note: This will happen when you force close the app by swiping the app up there by putting the app to background. The tunnel is winded down instantaneously in this case well.

See the screenshots and logs attached from the client. I don't have access to server logs :-/

Attachments (5)

openvpn-logs.txt (64.2 KB) - added by nullbandit 6 years ago.
log-files from openvpn connect
bug1.png (117.3 KB) - added by nullbandit 6 years ago.
UI Indicates connected but Tunnel is not connected
bug2.png (65.1 KB) - added by nullbandit 6 years ago.
UI Visual Indicator says VPN Connected but VPN is still attempting to connect, stays for as long as it takes
bug3.png (22.4 KB) - added by nullbandit 6 years ago.
Again false visual indicator while VPN has not actually connected/Tunnel is Dead.
working-v1.2.5.log (63.8 KB) - added by nullbandit 6 years ago.
Unfortunately these logs are highly verbose because I kept it at level 5 for testing. Hope this helps.

Download all attachments as: .zip

Change History (46)

Changed 6 years ago by nullbandit

Attachment: openvpn-logs.txt added

log-files from openvpn connect

Changed 6 years ago by nullbandit

Attachment: bug1.png added

UI Indicates connected but Tunnel is not connected

Changed 6 years ago by nullbandit

Attachment: bug2.png added

UI Visual Indicator says VPN Connected but VPN is still attempting to connect, stays for as long as it takes

Changed 6 years ago by nullbandit

Attachment: bug3.png added

Again false visual indicator while VPN has not actually connected/Tunnel is Dead.

comment:1 Changed 6 years ago by Antonio Quartulli

Owner: set to Antonio Quartulli
Status: newassigned

Hi there, when was the log exactly taken? I don't see any sleep event in the log.
Also, when bug1 screenshot was taken, what did the log say?

About the OpenVPN behaviour: when iOS goes to sleep mode, the OpenVPN app *stops* the VPN connection, because it can't be maintained while sleeping.
Upon wakeup, the VPN is re-established and this may take 2 to 3 seconds (normally). If you check the log in this case you should clearly see the SLEEP and WAKEUP event. Do you?

Edit: does the same happen when using UDP?

Please bring the SSL verbosity back to 0 as it makes the log difficult to read (we don't need that unless we know it's an SSL lib problem, but in this case it is not), thanks!

Last edited 6 years ago by Antonio Quartulli (previous) (diff)

comment:2 Changed 6 years ago by Antonio Quartulli

Summary: long sleep leaves tunnel Dead on v.1.2.6iOS: long sleep leaves tunnel Dead on v.1.2.6

comment:3 Changed 6 years ago by Nuno18

The temporary solution I found to this problem was in the application settings turn off the option "Seamless tunnel (iOS8 +)." Then the connection will resume after the mobile phone exits the standby mode.

So the problem must be in that option!

comment:4 Changed 6 years ago by Ewbtciast

I have the exact same issue. However, turning off the seamless tunnel option doesn't appear to help.

Last edited 6 years ago by Ewbtciast (previous) (diff)

comment:5 in reply to:  1 ; Changed 6 years ago by nullbandit

Replying to ordex:

Hi there, when was the log exactly taken? I don't see any sleep event in the log.

I kept logs in on my notes app and aggregated them. The sleep event doesn't seem to be visible but the app goes back to sleep.
Note: Background App Refresh on the Phones and Ipads were turned off on purpose to prevent background apps connecting to internet

Also, when bug1 screenshot was taken, what did the log say?

No activity visible on the logs

About the OpenVPN behaviour: when iOS goes to sleep mode, the OpenVPN app *stops* the VPN connection, because it can't be maintained while sleeping.
Upon wakeup, the VPN is re-established and this may take 2 to 3 seconds (normally). If you check the log in this case you should clearly see the SLEEP and WAKEUP event. Do you?

I dont see SLEEP and WAKEUP events at all on IP8+, IPhone X, IP7, IPad.

Edit: does the same happen when using UDP?

Yes today whole day I spent time testing on UDP. Its the same behavior on UDP as well.

Please bring the SSL verbosity back to 0 as it makes the log difficult to read (we don't need that unless we know it's an SSL lib problem, but in this case it is not), thanks!

I will bring down the verbosity back to 0.

One Important note. This behavior doesn't happen on IP7+ 128 GB. This model of Iphone on 11.2.2 keeps connection alive for ever. Its behavior is absolutely fantastic in fact much better 1.1.1.

In all my testing all the phones have same apps, same settings of OpenVPN and IOS across all devices. The tests I have run were mostly on commercial VPN providers. However I am trying to spin up VPN on a server but have no spare devices to tests. I will update back with verbosity of 0 when I get a chance.

comment:6 in reply to:  5 Changed 6 years ago by Antonio Quartulli

Replying to nullbandit:

Replying to ordex:

Hi there, when was the log exactly taken? I don't see any sleep event in the log.

I kept logs in on my notes app and aggregated them. The sleep event doesn't seem to be visible but the app goes back to sleep.

The sleep event is triggered by iOS directly to let OpenVPN Connect know that the whole system is about to sleep. If you don't see that event, I think the device is not really going to full sleep.

Note: Background App Refresh on the Phones and Ipads were turned off on purpose to prevent background apps connecting to internet

Also, when bug1 screenshot was taken, what did the log say?

No activity visible on the logs

ok

About the OpenVPN behaviour: when iOS goes to sleep mode, the OpenVPN app *stops* the VPN connection, because it can't be maintained while sleeping.
Upon wakeup, the VPN is re-established and this may take 2 to 3 seconds (normally). If you check the log in this case you should clearly see the SLEEP and WAKEUP event. Do you?

I dont see SLEEP and WAKEUP events at all on IP8+, IPhone X, IP7, IPad.

Weird. Normally the device should go to sleep within 20/30 seconds from when you locked the screen. I normally monitor that by pinging the device IP (when I am on wifi) and I assume it is sleeping when it stops replying.

Edit: does the same happen when using UDP?

Yes today whole day I spent time testing on UDP. Its the same behavior on UDP as well.

ok

Please bring the SSL verbosity back to 0 as it makes the log difficult to read (we don't need that unless we know it's an SSL lib problem, but in this case it is not), thanks!

I will bring down the verbosity back to 0.

One Important note. This behavior doesn't happen on IP7+ 128 GB. This model of Iphone on 11.2.2 keeps connection alive for ever. Its behavior is absolutely fantastic in fact much better 1.1.1.

In all my testing all the phones have same apps, same settings of OpenVPN and IOS across all devices. The tests I have run were mostly on commercial VPN providers. However I am trying to spin up VPN on a server but have no spare devices to tests. I will update back with verbosity of 0 when I get a chance.

Thanks a lot. Any additional information will surely help

comment:7 Changed 6 years ago by Hunterx1

I was able to duplicate by just switching from wifi to LTE with seamless tunnel turned on using control center toggles. 1-2 switches is all it takes on my device. iPhone 6s 128.

comment:8 in reply to:  7 ; Changed 6 years ago by Antonio Quartulli

Replying to Hunterx1:

I was able to duplicate by just switching from wifi to LTE with seamless tunnel turned on using control center toggles. 1-2 switches is all it takes on my device. iPhone 6s 128.

when you say switching from wifi to LTE, do you mean switcihng wifi on and off from the control panel? Or are you talking about the "connect-via" setting in the OpenVPN settings pane?

Last edited 6 years ago by Antonio Quartulli (previous) (diff)

comment:9 in reply to:  8 Changed 6 years ago by Hunterx1

Replying to ordex:

Replying to Hunterx1:

I was able to duplicate by just switching from wifi to LTE with seamless tunnel turned on using control center toggles. 1-2 switches is all it takes on my device. iPhone 6s 128.

when you say switching from wifi to LTE, do you mean switcihng wifi on and off from the control panel? Or are you talking about the "connect-via" setting in the OpenVPN settings pane?

Via the iOS control center. I’m running iOS 11.2.2.
Edit: to clarify, all I did was use the control center to disconnect the wifi so that the LTE connection would reconnect. It seems that the reconnection triggers the issue. It’s pretty immediate. It only occurs using seamless tunnel. One odd observation is that starting with LTE then enabling wifi will not kill the connection, but while it’s conneced to wifi, turning off LTE kills the connection (I can’t explain this, but I can reproduce). The new control center only disconnects rather than a full disable if that matters. Turning wifi off fully in the wifi settings has the same effect. I hope this helps instead of adding confusion. I made sure to repeat each test before posting.

Last edited 6 years ago by Hunterx1 (previous) (diff)

comment:10 Changed 6 years ago by JamesPacson

I have this issue as well and I registered to report it. I was just about to create a new bug report but this one seems to match my issue exactly. I can reproduce the issue systematically, I don't need 10 minutes, a few minutes actually does it.

here's my log, don't know if it will help.
pastebin: https://filetrip.net/view?eP1DufsuiW

I'm on the latest version of iOS 10, don't really want to upgrade to iOS 11 because of the slowdowns and all (iPhone 6S).

Note: everything was fine until I installed the 1.2.6 update yesterday.

Last edited 6 years ago by JamesPacson (previous) (diff)

comment:11 Changed 6 years ago by lambo117

Hello. I registered to add this comment.

I'm running the latest OpenVPN Connect app for iOS (1.2.6) on an iPhone X running iOS 11.2.2, and I am having exactly the same issue described by the users above. Upon waking after a sleep (any sleep longer than say 20-30 seconds), the VPN connection appears to be "alive", but there is no connectivity. Like the above users noted, there are no errors or other indicators in the log.

This behavior only started happening after updating to the most recent version of the OpenVPN Connect app. The update fixed a host of issues for me personally but spawned this issue, which is actually quite crippling to regular use of the iPhone (since I sleep / wake dozens and dozens of time per day -- the VPN loses internet connectivity almost immediately, very consistently).

I can provide log details if needed, though it should be noted that my log looks nearly identical to the logs above. If it helps, I am using the default iOS profiles provided by Private Internet Access, with Seamless Tunnel ENABLED. For the next few hours, I will be testing for this issue with that option DISABLED and will report back with my findings.

Thanks for all your hard work!

comment:12 Changed 6 years ago by JamesPacson

After testing for the past half day, I can confirm that disabling the "seamless tunnel" option solves the problem. All works as expected. Personally I forgot why I had enabled this option. I cant remember what it does and disabling it doesnt seem to cause me any issue. I'll read the documentation to find out what I've lost :-)

comment:13 Changed 6 years ago by nullbandit

Okay here is the difference in log for IP7+ on v1.2.5

2018-01-21 19:55:23 OPTIONS:
0 [redirect-gateway] [def1]
1 [redirect-gateway] [def1]
2 [dhcp-option] [DNS] [209.222.18.222]
3 [dhcp-option] [DNS] [209.222.18.218]
4 [ping] [10]
5 [comp-lzo] [no]
6 [route] [10.39.10.1]
7 [topology] [net30]
8 [ifconfig] [10.39.10.6] [10.39.10.5]
9 [block-ipv6]

2018-01-21 19:55:23 PROTOCOL OPTIONS:
  cipher: AES-256-CBC
  digest: SHA256
  compress: LZO_STUB
  peer ID: -1
2018-01-21 19:55:23 EVENT: ASSIGN_IP
2018-01-21 19:55:23 NIP: preparing TUN network settings      
2018-01-21 19:55:23 NIP: init TUN network settings with endpoint: 2607:7700:0:1c::68c8:9752
2018-01-21 19:55:23 NIP: adding IPv4 address to network settings 10.39.10.6/255.255.255.252
2018-01-21 19:55:23 NIP: adding (included) IPv4 route 10.39.10.1/32
2018-01-21 19:55:23 NIP: redirecting all IPv4 traffic to TUN interface
2018-01-21 19:55:23 NIP: adding DNS 209.222.18.222
2018-01-21 19:55:23 NIP: adding DNS 209.222.18.218
2018-01-21 19:55:23 Connected via NetworkExtensionTUN
2018-01-21 19:55:23 LZO-ASYM init swap=0 asym=1
2018-01-21 19:55:23 Comp-stub init swap=0
2018-01-21 19:55:23 EVENT: CONNECTED XXXX@XXXX.com:1197 (2607:7700:0:1c::68c8:9752) via /UDPv6 on NetworkExtensionTUN/10.39.10.6/ gw=[/]

Above is the log messages from IP7+ and it works flawless no matter how much ever time I sleep, and come back to wake up. The IP7+ is on iOS 11.2.2 and OpenVPN v1.2.5

The Key difference here with working OpenVPN Connect app (v1.2.5) on IP7+ vs non working OpenVPN Connect app (v1.2.6) IP7,IP8+,IPX I see are

EVENT: ASSIGN_IP
adding (included) IPv4 route
redirecting all IPv4 traffic to TUN interface
Connected via NetworkExtensionTUN

These above log events are not present in v.1.2.6 after the event SLEEP and WAKE UP. Does this mean that v1.2.6 doesn't redirect the traffic after waking up and re-connecting to the tunnel. The test is on UDP though, not on TCP.

comment:14 in reply to:  12 Changed 6 years ago by nullbandit

Replying to JamesPacson:

After testing for the past half day, I can confirm that disabling the "seamless tunnel" option solves the problem. All works as expected. Personally I forgot why I had enabled this option. I cant remember what it does and disabling it doesnt seem to cause me any issue. I'll read the documentation to find out what I've lost :-)

@JamesPacson? I wouldn't recommend disabling "seamless Tunnel" That will lead to traffic leak.
I tried it on IP7,IP7+, IP8+ and IPx, IPAD Pro, it doesnt work for me.

comment:15 in reply to:  13 Changed 6 years ago by Antonio Quartulli

Replying to nullbandit:
Connect app (v1.2.6) IP7,IP8+,IPX I see are

EVENT: ASSIGN_IP
adding (included) IPv4 route
redirecting all IPv4 traffic to TUN interface
Connected via NetworkExtensionTUN

These above log events are not present in v.1.2.6 after the event SLEEP and WAKE UP. Does this mean that v1.2.6 doesn't redirect the traffic after waking up and re-connecting to the tunnel. The test is on UDP though, not on TCP.

Those lines are not expected to appear when Seamless Tunnel is ON because the tun interface should re-use the settings that were already configured on the tunnel (the tunnel is not destroyed when seamless tunnel is ON, thus it will retain all its settings).

Do you have a full log of the "working" app? from its connection to its successful reconnection?

edit: I am wondering if the server is assigning different IPs across the two sessions and thus seamless tunnel is breaking up

edit2: from one log above, this seems the case. Normally this is not really expected, but this condition can definitely break the seamless tunnel feature as implemented right now

Last edited 6 years ago by Antonio Quartulli (previous) (diff)

Changed 6 years ago by nullbandit

Attachment: working-v1.2.5.log added

Unfortunately these logs are highly verbose because I kept it at level 5 for testing. Hope this helps.

comment:16 Changed 6 years ago by Antonio Quartulli

In this case the client is reconnecting to a different server (maybe due to DNS load balancing) and it is getting a different IP. However the interface was getting reconfigured.

In 1.2.6 the interface is not getting reconfigured at all after the reconnection (but it retains the old settings).

This is probably the core of the issue you are witnessing.

comment:17 in reply to:  16 Changed 6 years ago by nullbandit

Replying to ordex:

In this case the client is reconnecting to a different server (maybe due to DNS load balancing) and it is getting a different IP. However the interface was getting reconfigured.

You are correct, I see that in case of working version v1.2.5, I always get a new server IP and local IP, when re-connected. while the non-working version v1.2.6, I retain the same IP public and local IP.

In 1.2.6 the interface is not getting reconfigured at all after the reconnection (but it retains the old settings).

This is probably the core of the issue you are witnessing.

I am using two different VPN's to test. I will try to get same VPN on the 1.2.6 to get the perfect parity for your reference.

comment:18 Changed 6 years ago by pim1896

Just registered to say I have the exact same issue as decribed here. I have seamless tunnel always 'ON' (as advised by my VPN provider) and never had any problems with it until I updated to latest OpenVPN Connect. On iPhone X 11.2.2.

Version 0, edited 6 years ago by pim1896 (next)

comment:19 Changed 6 years ago by lambo117

Hello.

I wrote comment #11. After spending the weekend testing various configs, I can say with certainty that, in my case, DISABLING Seamless Tunnel does NOT fix the issue. With Seamless Tunnel enabled, the iPhone appears connected after sleeping but actually yields no connectivity. With Seamless Tunnel disabled, the iPhone appears disconnected after sleeping and does not reconnect upon wake unless done manually.

Thanks

comment:20 Changed 6 years ago by nullbandit

Tested with same VPN provider on both versions v1.2.6 and v.1.2.5 the results are same.
Not trying to derail the issue at hand, but I was wondering if its possible for forcing the code to flow the same way as connect would help. I am beginning to think that this is more of iOS sleep issue than the OpenVPN Connect App issue.

comment:21 in reply to:  19 ; Changed 6 years ago by Antonio Quartulli

Replying to lambo117:

Hello.

I wrote comment #11. After spending the weekend testing various configs, I can say with certainty that, in my case, DISABLING Seamless Tunnel does NOT fix the issue. With Seamless Tunnel enabled, the iPhone appears connected after sleeping but actually yields no connectivity. With Seamless Tunnel disabled, the iPhone appears disconnected after sleeping and does not reconnect upon wake unless done manually.

Thanks

Can you provide the log of this test?

comment:22 in reply to:  20 Changed 6 years ago by Antonio Quartulli

Replying to nullbandit:

Tested with same VPN provider on both versions v1.2.6 and v.1.2.5 the results are same.
Not trying to derail the issue at hand, but I was wondering if its possible for forcing the code to flow the same way as connect would help. I am beginning to think that this is more of iOS sleep issue than the OpenVPN Connect App issue.

Might be a combination of unexpected iOS behaviour + the app not handling it properly. However, a fix for the seamless tunnel is in the work (it will fix situations where the change of IPs was breaking stuff).

comment:23 Changed 6 years ago by pduin

I seem to have the same problem.

  1. Lock phone
  2. Wait a while and unlock phone
  3. VPN badge shows in top, but the connection seems to be down.

Logs don't seem to show anything useful when the connection supposedly 'drops'.

In my case, only DNS requests do not seem to work when the VPN connection 'drops'. Using ip addresses to connect to anything works fine.

On initial connection to the VPN server, the phone gets custom DNS settings pushed, maybe these settings are lost after the phone is locked for a while?

Please let me know if you need any logs or more info.

comment:24 Changed 6 years ago by Antonio Quartulli

This issue with the DNS getting lost during sleep has been nailed down and a fix will be available in the next release

comment:25 in reply to:  21 Changed 6 years ago by lambo117

Replying to ordex:

Replying to lambo117:

Hello.

I wrote comment #11. After spending the weekend testing various configs, I can say with certainty that, in my case, DISABLING Seamless Tunnel does NOT fix the issue. With Seamless Tunnel enabled, the iPhone appears connected after sleeping but actually yields no connectivity. With Seamless Tunnel disabled, the iPhone appears disconnected after sleeping and does not reconnect upon wake unless done manually.

Thanks

Can you provide the log of this test?


Yes. Here is the log for [Seamless Tunnel ENABLED > Connect to VPN > Sleep > Wait a few mins > Wake]:

https://pastebin.com/LFfm4681

Again, the behavior for the above is that the VPN appears connected (both in OpenVPN app and according to iOS status bar) but does not offer any connectivity.


Here is the log for [Seamless Tunnel DISABLED > Connect to VPN > Sleep > Wait a few mins > Wake]:

https://pastebin.com/4dDmeSaz

The behavior for this test is that the VPN is disconnected upon waking (usually not after first wake -- maybe after 3rd/4th wake or 30mins - 1hr) and does not reconnect unless done so manually.


comment:26 in reply to:  24 Changed 6 years ago by ewbtciast

Replying to ordex:

This issue with the DNS getting lost during sleep has been nailed down and a fix will be available in the next release

Any eta on the next release?

comment:27 Changed 6 years ago by hunterx1

Updating to iOS 11.2.5 didn’t help. Logs do show up now instead of just listing connected.
I repeated a similar test of connecting with wifi, with LTE enabled. It does go into a connected state, but the connection is dead. The below log starts with a good connection, and is the result of me switching off wifi. Connection was dead immediately. Log is extremely long, so most is excluded.

2018-01-23 16:55:41 EVENT: CONNECTED p5353695@…:1198 (104.200.154.18) via /UDPv4 on NetworkExtensionTUN/10.5.10.10/ gw=/
2018-01-23 16:55:48 OS Event: NET UNAVAILABLE (PAUSE): Internet:NotReachable/-R tc-----
2018-01-23 16:55:48 UDP send error: SYSTEM/Can't assign requested address
2018-01-23 16:55:48 Transport Error: EADDRNOTAVAIL: Can't assign requested address
2018-01-23 16:55:48 EVENT: TRANSPORT_ERROR EADDRNOTAVAIL: Can't assign requested address [ERR]
2018-01-23 16:55:48 Client terminated, restarting in 5000 ms...
2018-01-23 16:55:48 EVENT: PAUSE
2018-01-23 16:55:48 OS Event: NET AVAILABLE (RESUME): Internet:ReachableViaWWAN/WR t------ allow=1
2018-01-23 16:55:51 RECONNECT TEST: Internet:ReachableViaWWAN/WR t------
2018-01-23 16:55:51 ACTIVE PAUSE
2018-01-23 16:55:52 RESUME TEST: Internet:ReachableViaWWAN/WR t------
2018-01-23 16:55:52 STANDARD RESUME
2018-01-23 16:55:52 EVENT: RESUME
2018-01-23 16:55:52 EVENT: RECONNECTING
2018-01-23 16:55:52 Contacting [104.200.154.18]:1198/UDP via UDP
2018-01-23 16:55:52 EVENT: WAIT
2018-01-23 16:55:52 Connecting to [us-seattle.privateinternetaccess.com]:1198 (104.200.154.18) via UDPv4
2018-01-23 16:55:53 EVENT: CONNECTING

comment:28 Changed 6 years ago by Antonio Quartulli

Thanks for the log. However, 1.2.7 is due sometime soon (currently under review by Apple). Therefore I'd suggest to postpone any additional test to when this new version is out.

Thanks a lot for the support so far!

comment:29 Changed 6 years ago by Antonio Quartulli

Status: assignedaccepted

comment:30 in reply to:  28 ; Changed 6 years ago by ewbtciast

Replying to ordex:

Thanks for the log. However, 1.2.7 is due sometime soon (currently under review by Apple). Therefore I'd suggest to postpone any additional test to when this new version is out.

Thanks a lot for the support so far!

Is there an update on the Apple review or an ETA for release?

comment:31 in reply to:  30 Changed 6 years ago by Antonio Quartulli

Replying to ewbtciast:

Replying to ordex:

Thanks for the log. However, 1.2.7 is due sometime soon (currently under review by Apple). Therefore I'd suggest to postpone any additional test to when this new version is out.

Thanks a lot for the support so far!

Is there an update on the Apple review or an ETA for release?

Not yet unfortunately. It's the first time that Apple is taking so long to review the app.

comment:32 Changed 6 years ago by Antonio Quartulli

v1.2.7 is being rolled out to the various AppStore? as we speak. Please test it once you have a chance to upgrade and update this ticket accordingly, if possible. Thanks!

comment:33 in reply to:  32 Changed 6 years ago by ewbtciast

Replying to ordex:

v1.2.7 is being rolled out to the various AppStore? as we speak. Please test it once you have a chance to upgrade and update this ticket accordingly, if possible. Thanks!

I just updated! I’ll test it tomorrow and report back. Thank you guys for all the hard work.

comment:34 in reply to:  32 ; Changed 6 years ago by hunterx1

Replying to ordex:

v1.2.7 is being rolled out to the various AppStore? as we speak. Please test it once you have a chance to upgrade and update this ticket accordingly, if possible. Thanks!

So far my use case above is resolved. I will post back tomorrow after having it on for at least 18 hours.

comment:35 Changed 6 years ago by nullbandit

This can be safely closed (helps not to stray the issues around) as most of my issues were resolved after v1.2.7 release.

comment:36 Changed 6 years ago by girgle

I just updated to 1.2.7 on my iPhone (iOS 11.2.2) and while I've noticed some improvement, the issue seems to still occur. VPN stays active on some short sleeps, but longer sleeps result in the VPN logo disappearing and changing to LTE. Sometimes it autoreconnects, other times I have to manually reconnect via the application. I've tried this with TCP-443 and with UDP-1197.

2018-01-31 18:59:16 SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
2018-01-31 18:59:16 Session is ACTIVE
2018-01-31 18:59:16 EVENT: GET_CONFIG
2018-01-31 18:59:16 Sending PUSH_REQUEST to server...
2018-01-31 18:59:17 Sending PUSH_REQUEST to server...
2018-01-31 18:59:19 Sending PUSH_REQUEST to server...
2018-01-31 18:59:19 OPTIONS:
0 [redirect-gateway] [ipv6]
1 [redirect-gateway] [def1] [bypass-dhcp]
2 [dhcp-option] [DNS] [XX.X.X.X]
3 [route-ipv6] [XXXX::/2]
4 [route-ipv6] [XXXX::/2]
5 [route-ipv6] [XXXX::/2]
6 [route-ipv6] [XXXX::/2]
7 [route-gateway] [XX.X.X.X]
8 [topology] [subnet]
9 [socket-flags] [TCP_NODELAY]
10 [ifconfig-ipv6] [xxxx:xxxx:xxxx:443::xxxx/64] [xxxx:xxxx:xxxx:443::]
11 [ifconfig] [xx.x.x.x] [xxx.xxx.x.x.]
12 [peer-id] [0]
13 [cipher] [AES-256-GCM]

2018-01-31 18:59:19 PROTOCOL OPTIONS:

cipher: AES-256-GCM
digest: SHA1
compress: LZO_STUB
peer ID: 0

2018-01-31 18:59:19 EVENT: ASSIGN_IP
2018-01-31 18:59:19 NIP: preparing TUN network settings
2018-01-31 18:59:19 NIP: init TUN network settings with endpoint: XX.XX.XX.XX
2018-01-31 18:59:19 NIP: adding IPv4 address to network settings XX.X.X.X/XXX.XXX.X.X
2018-01-31 18:59:19 NIP: adding (included) IPv4 route XX.X.X.X/16
2018-01-31 18:59:19 NIP: adding IPv6 address to network settings xxxx:xxxx:xxxx:443::XXXX/XX
2018-01-31 18:59:19 NIP: adding (included) IPv6 route xxxx:xxxx:xxxx:443::XXXX/XX
2018-01-31 18:59:19 NIP: adding (included) IPv6 route ::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: redirecting all IPv4 traffic to TUN interface
2018-01-31 18:59:19 NIP: redirecting all IPv6 traffic to TUN interface
2018-01-31 18:59:19 NIP: adding DNS XX.X.X.X
2018-01-31 18:59:19 Connected via NetworkExtensionTUN
2018-01-31 18:59:19 LZO-ASYM init swap=0 asym=1
2018-01-31 18:59:19 Comp-stub init swap=0
2018-01-31 18:59:19 EVENT: CONNECTED XXXXXXX via /TCPv4 on NetworkExtensionTUN/XXXXXXXX gw=/
2018-01-31 19:02:32 OS Event: SLEEP
2018-01-31 19:02:32 EVENT: PAUSE
2018-01-31 19:02:33 OS Event: WAKEUP
2018-01-31 19:02:36 RESUME TEST: Internet:ReachableViaWiFi/-R t------
2018-01-31 19:02:36 STANDARD RESUME
2018-01-31 19:02:36 EVENT: RESUME
2018-01-31 19:02:36 EVENT: RECONNECTING
2018-01-31 19:02:36 Contacting [XX.XX.XXX.XXX]:443/TCP via TCP
2018-01-31 19:02:36 EVENT: WAIT
2018-01-31 19:02:36 Connecting to XXXXX:443 via TCPv4
2018-01-31 19:02:36 EVENT: CONNECTING
2018-01-31 19:02:36 Tunnel Options:V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client
2018-01-31 19:02:36 Creds: Username/Password?
2018-01-31 19:02:36 Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 1.2.7-4
IV_VER=3.1.2
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_IPv6=1

comment:37 in reply to:  36 Changed 6 years ago by Antonio Quartulli

Replying to girgle:

2018-01-31 18:59:16 SSL Handshake: TLSv1.2/TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
2018-01-31 18:59:16 Session is ACTIVE
2018-01-31 18:59:16 EVENT: GET_CONFIG
2018-01-31 18:59:16 Sending PUSH_REQUEST to server...
2018-01-31 18:59:17 Sending PUSH_REQUEST to server...
2018-01-31 18:59:19 Sending PUSH_REQUEST to server...
2018-01-31 18:59:19 OPTIONS:
0 [redirect-gateway] [ipv6]
1 [redirect-gateway] [def1] [bypass-dhcp]
2 [dhcp-option] [DNS] [XX.X.X.X]
3 [route-ipv6] [XXXX::/2]
4 [route-ipv6] [XXXX::/2]
5 [route-ipv6] [XXXX::/2]
6 [route-ipv6] [XXXX::/2]
7 [route-gateway] [XX.X.X.X]
8 [topology] [subnet]
9 [socket-flags] [TCP_NODELAY]
10 [ifconfig-ipv6] [xxxx:xxxx:xxxx:443::xxxx/64] [xxxx:xxxx:xxxx:443::]
11 [ifconfig] [xx.x.x.x] [xxx.xxx.x.x.]
12 [peer-id] [0]
13 [cipher] [AES-256-GCM]

2018-01-31 18:59:19 PROTOCOL OPTIONS:

cipher: AES-256-GCM
digest: SHA1
compress: LZO_STUB
peer ID: 0

2018-01-31 18:59:19 EVENT: ASSIGN_IP
2018-01-31 18:59:19 NIP: preparing TUN network settings
2018-01-31 18:59:19 NIP: init TUN network settings with endpoint: XX.XX.XX.XX
2018-01-31 18:59:19 NIP: adding IPv4 address to network settings XX.X.X.X/XXX.XXX.X.X
2018-01-31 18:59:19 NIP: adding (included) IPv4 route XX.X.X.X/16
2018-01-31 18:59:19 NIP: adding IPv6 address to network settings xxxx:xxxx:xxxx:443::XXXX/XX
2018-01-31 18:59:19 NIP: adding (included) IPv6 route xxxx:xxxx:xxxx:443::XXXX/XX
2018-01-31 18:59:19 NIP: adding (included) IPv6 route ::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: adding (included) IPv6 route XXXX::/2
2018-01-31 18:59:19 NIP: redirecting all IPv4 traffic to TUN interface
2018-01-31 18:59:19 NIP: redirecting all IPv6 traffic to TUN interface
2018-01-31 18:59:19 NIP: adding DNS XX.X.X.X
2018-01-31 18:59:19 Connected via NetworkExtensionTUN
2018-01-31 18:59:19 LZO-ASYM init swap=0 asym=1
2018-01-31 18:59:19 Comp-stub init swap=0
2018-01-31 18:59:19 EVENT: CONNECTED XXXXXXX via /TCPv4 on NetworkExtensionTUN/XXXXXXXX gw=/

did the sleep happen at this time?

2018-01-31 19:02:32 OS Event: SLEEP
2018-01-31 19:02:32 EVENT: PAUSE
2018-01-31 19:02:33 OS Event: WAKEUP
2018-01-31 19:02:36 RESUME TEST: Internet:ReachableViaWiFi/-R t------
2018-01-31 19:02:36 STANDARD RESUME
2018-01-31 19:02:36 EVENT: RESUME
2018-01-31 19:02:36 EVENT: RECONNECTING
2018-01-31 19:02:36 Contacting [XX.XX.XXX.XXX]:443/TCP via TCP
2018-01-31 19:02:36 EVENT: WAIT
2018-01-31 19:02:36 Connecting to XXXXX:443 via TCPv4
2018-01-31 19:02:36 EVENT: CONNECTING
2018-01-31 19:02:36 Tunnel Options:V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client
2018-01-31 19:02:36 Creds: Username/Password?
2018-01-31 19:02:36 Peer Info:
IV_GUI_VER=net.openvpn.connect.ios 1.2.7-4
IV_VER=3.1.2
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO_STUB=1
IV_COMP_STUB=1
IV_COMP_STUBv2=1
IV_IPv6=1

did the log stop here? It looks like it stopped in the middle of a reconnection

comment:38 Changed 6 years ago by Antonio Quartulli

Another question: Are you connected via wifi when this happens or LTE? Or do you actually move from a place with wifi to a place without it ?

comment:39 in reply to:  34 ; Changed 6 years ago by hunterx1

Replying to hunterx1:

Replying to ordex:

v1.2.7 is being rolled out to the various AppStore? as we speak. Please test it once you have a chance to upgrade and update this ticket accordingly, if possible. Thanks!

So far my use case above is resolved. I will post back tomorrow after having it on for at least 18 hours.

When I returned home, it disconnected sometime after connecting to wifi after being stable on both for many hours. It just seemed to randomly drop with an EVENT WAIT. It never recovers, and I don’t know how long it was disconnected for. It could have disconnected the moment I woke it to look. The vpn icon was not displayed. This issue is unrelated to the original bug, so I have been unable to duplicate this bug after the update.

comment:40 in reply to:  39 Changed 6 years ago by Antonio Quartulli

Resolution: fixed
Status: acceptedclosed

Replying to hunterx1:

Replying to hunterx1:

Replying to ordex:

v1.2.7 is being rolled out to the various AppStore? as we speak. Please test it once you have a chance to upgrade and update this ticket accordingly, if possible. Thanks!

So far my use case above is resolved. I will post back tomorrow after having it on for at least 18 hours.

When I returned home, it disconnected sometime after connecting to wifi after being stable on both for many hours. It just seemed to randomly drop with an EVENT WAIT. It never recovers, and I don’t know how long it was disconnected for. It could have disconnected the moment I woke it to look. The vpn icon was not displayed. This issue is unrelated to the original bug, so I have been unable to duplicate this bug after the update.

Being stuck like in the log or on EVENT WAIT, means that the App was able to reach the server, but for some reason something occurred and it couldn't continue talking to it (that's why I was wondering about passing from one network to another in the middle of the reconnection).

Still, it should properly switch. Would you mind opening a new bug for this? We can properly track it there.

I am closing this ticket as the original problem is finally gone.

Thanks everybody

comment:41 in reply to:  38 Changed 6 years ago by girgle

Replying to ordex:

Another question: Are you connected via wifi when this happens or LTE? Or do you actually move from a place with wifi to a place without it ?

Correct - I was connected to WiFi? at the time. Phone was stationary at home. I've noticed it did this on occasion in several previous versions, although the VPN logo never dropped when it switched from LTE to WiFi? (leading me to assume the connection to the VPN was maintained throughout).

Regarding your question about the logs - yes, this is where the event occurred and I had to manually go back to the app and turn the connection back on. Everything else after the log showed it reconnect ok. I'll try and find another example where it auto-disconnects and I have to reconnect. Thanks for your help.

Note: See TracTickets for help on using tickets.