Article Applies To:
SonicWALL Security Appliance Platforms:
Gen5: NSA E8500, NSA E7500, NSA E6500, NSA E5500, NSA 5000, NSA 4500, NSA 3500, NSA 2400, NSA 2400MX, NSA 240
Gen5 TZ Series: TZ 100, TZ 100 Wireless, TZ 200, TZ 200 W, TZ 210, TZ 210 Wireless,
Firmware/Software Version: SonicOS 220.127.116.11 and higher
Gen4: PRO series: PRO 5060, PRO 4100, PRO 4060,PRO 3060, PRO 2040
Gen4: TZ series: TZ 190, TZ 190 W, TZ 180, TZ 180 W
Firmware/Software Version: SonicOS 18.104.22.168 and higher
Services: L2TP connectivity using iPhone, iPod, iPad
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
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:
Phase 1- IKE Transformations :
· Pre-shared key/3DES/SHA1/Group2
Phase 2 - IPSec Transformations :
· AES 128/MD5
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 :
SonicWALL Default Phase 2 Transformations: 3DES/SHA1/Group 2
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 22.214.171.124 and above. The option is on the Advanced tab when configuring a GroupVPN policy from the VPN > Settings page in SonicOS.
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.
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
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
b) Phase 1 Encryption Mismatch
c) Phase 2 Encryption Mismatch
d) Phase 1 and Phase 2 Successful