Troubleshooting L2TP connectivity when using iPhone, iPod, iPad
03/26/2020
26 People found this article helpful
447,806 Views
Description
Troubleshooting L2TP connectivity when using iPhone, iPod, iPad
Resolution
List of IPSec and L2TP client proposals
Important: To successfully establish a VPN tunnel the L2TP (VPN) client and the Remote VPN device must agree upon the same set of Proposals/Transform Payloads (differs from client to client), please refer the following article for complete details: UTM - VPN: List of IPSec and L2TP client proposals
Problem Definition:
- L2TP tunnels between Sonicwall Appliances and Apple iphones, iPods and iPads are dropped by the Apple devices when not in use:
L2TP tunnels between Sonicwall Appliances and Apple iPhones, iPods and iPads are dropped by the Apple devices unless continuously used. This is a power saving feature. This behavior is found on all iOS devices. VPN tunnels will disconnect if the iOS device is put to sleep (the screen is off). In addition, WiFi disconnects, and MOST data will stop passing, after the screen is turned off. 3G will still be up and available though, as it is used for push notifications/push mail, iCloud/MobileMe synchronization, etc. 3G may also be used to retrieve email on a timer using the fetch feature even when the screen is off. This is not applicable if the iOS device is WiFi only, like iPod touch and some iPads
- iPhone, iPod, iPad L2TP connectivity fails when connecting to SonicWall UTM appliances:
Transformations that iPhone, iTouch, iPad Support for L2TP connectivity:
On iOS version 3.x:
Pre-shared key
Phase 1- IKE Transformations :
· Pre-shared key/3DES/SHA1/Group2
Phase 2 - IPSec Transformations :
· AES128/SHA1
· AES 128/MD5
· 3DES/SHA1
· 3DES/MD5
PFS: NO
On iOS Version 4:
Phase 1- IKE Transformations
· Pre-Shared/AES 256/SHA /Group 2
· Pre-Shared/AES 256/ MD 5/ Group 2
· Pre-Shared/AES 128/ SHA/Group 2
· Pre-Shared/AES 128/MD 5/ Group 2
· Pre-Shared/3DES/SHA1/Group 2
SonicWall Default Phase 1 Transformations: Pre-Shared/3DES/SHA1/Group 2
Phase 2 - IPSec Transformations :
· AES256/SHA1
· AES256/MD5
· AES128/SHA1
· AES128/MD5
· 3DES/SHA1
· 3DES/MD5
SonicWall Default Phase 2 Transformations: 3DES/SHA1/Group 2
Troubleshooting:
Resolution 1:
The new Accept Multiple Proposals for Clients checkbox allows multiple VPN or L2TP clients using different security policies to connect to a firewall running SonicOS 5.8.0.5 and above. The option is on the Advanced tab when configuring a GroupVPN policy from the VPN > Settings page in SonicOS.
![Image](https://sonicwall.rightanswers.com/portal/app/portlets/results/onsitehypermedia/090170801708857.png?linkToken=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzb25pY3dhbGwiLCJleHAiOjE3NTY2MTAxNjQsImlhdCI6MTcyNTA3NDE2NH0.RlbXopyaUDfGL6hoLAg1fHGUwJoaPQI2DTBg49HqMyQ)
The client policy is still strictly checked against the configured proposal in the Proposals tab, as with clients connecting with SonicWall GVC. This option has no effect on GVC.
If the Accept Multiple Proposals for Clients option is selected, SonicOS will allow connections from other L2TP clients, such as Apple OS, Windows, or Android clients whose offered proposal is different from what is configured on the Proposals tab. The proposal is accepted if it meets the following conditions:
• If the offered algorithm matches one of the possible algorithms available in SonicOS.
• If the offered algorithm is stronger and more secure than the configured algorithm in the SonicOS proposal.
If this option is NOT selected, SonicOS will require the client to strictly match the configured policy.
This option allows SonicWall to support heterogeneous environments for Apple, Windows, and Android clients. Using this option, SonicOS can work with these clients if their proposal includes a combination of algorithms which are supported in SonicOS, but are not configured in the policy to prevent other clients like GVC from failing.
Resolution 2:
iPhone, iPod, iPad start transformation negotiation process starting from highest security for Phase 1 and Phase 2. Make sure that WAN Group VPN policy's Phase 1 and Phase 2 transformations match that of transformations that iPhone, iPod, iPad support.
When negotiations fail due to mismatch, Firewall Logs do indicate the reason for the negotiation failures (shown below)
Consider the following example:
L2TP client on IPAD running iOS Version 3.x is trying to connect SonicWall UTM device
Phase 1 Transformations set on Group VPN Policy on SonicWall: Pre-shared key/3DES/SHA1/Group2
Phase 2 Transformations set on Group VPN Policy on SonicWall: AES256/SHA1
![](upload/images/sonicwall/090170801641836.png)
When L2TP client (iPhone, iPod, iPad) running iOS 3.x tries to connect, Phase 1 succeeds because these transformations are supported by iOS 3.x. But phase 2 negotiation fails as iOS 3.x doesn't support AES256. (please refer the above mentioned supported transformations)
When L2TP client (iPhone, iPod, iPad) running iOS 4 tries to connect, both phase 1 and phase 2 connections succeed as these transformations are supported by iOS 4.x (please refer the above mentioned supported transformations)
How to Test:
Error Logs on SonicWall UTM device when negotiations fail due to transformations mismatch (Tests are done using IPAD running iOS 3.x)
a) Phase 1 DH Group Mismatch
![](upload/images/sonicwall/090170801164487.png)
b) Phase 1 Encryption Mismatch
![](upload/images/sonicwall/090170801272439.png)
c) Phase 2 Encryption Mismatch
![](upload/images/sonicwall/090170801999647.png)
d) Phase 1 and Phase 2 Successful
![](upload/images/sonicwall/090170801683900.png)
Related Articles
Categories