IMPLEMENTATION                                          SonicWALL IKE / IPSec VPN Implementation FAQ



Introduction
This ...
Q: Which VPN-related RFC’s and drafts are supported in SonicWALL firmware?
A: In the older SonicWALL firmware 6.x (GEN2/GE...
Q: What VPN settings have been automated or simplified?
     A single field defines the policy lifetime for Phase 1 and Ph...
Q: How does the SonicWALL handle IKE Identities?
A: Note the following:

    Firmware 6.6.x using PSK
        In Aggressiv...
Q: How many VPN tunnels can a SonicWALL security appliance really handle?
A: First off, it’s important to understand that ...
Q: How many IP subnets can you define for a VPN policy?
A: On Standard, Phase 1 and Phase 2 SAs are not explicitly counted...
Q: What is ARCFour?
A: ARCFour is an older encryption mechanism based on RC4. If you are setting up SonicWALL-to-
SonicWAL...
Q: Where can I find technotes on how to set up VPN tunnels to third-party VPN
security appliances?
A: All VPN interoperabi...
Q: What does the ‘Enable Fragmented Packet Handling’ checkbox do?
A: For various reasons, IPsec traffic can become fragmen...
Q: What’s the difference between ‘Dead Peer Detection’ and ‘Keepalive’?
A: Note the following:

        Dead Peer Detectio...
Q: What does the ‘NAT Traversal’ checkbox do?
A: NAT Traversal, if enabled, automatically detects if network address trans...
Q: What exactly does the built-in ‘GroupVPN’ policy do?
A: The 'GroupVPN' is hard-coded to accept incoming connections fro...
Q: What is ‘VPN single-armed’ mode?
A: This feature allows a SonicWALL security appliance running firmware 6.2.x or SonicO...
Q: What do the ‘VPN Terminated at’ radio buttons do in firmware 6.6 and SonicOS
Standard?
A: In these two firmware OS’s, i...
Q: What are the constraints on the Shared Secret field?
A: The Shared secret must be a minimum of four characters and a ma...
Upcoming SlideShare
Loading in...5
×

SonicWALL IKE / IPSec Implementation FAQ

3,252

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,252
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
38
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "SonicWALL IKE / IPSec Implementation FAQ"

  1. 1. IMPLEMENTATION SonicWALL IKE / IPSec VPN Implementation FAQ Introduction This technote provides answers to the following Frequently Asked Questions: Introduction........................................................................................................................................................................... 1 Q: Which VPN-related RFC’s and drafts are supported in SonicWALL firmware? ............................................................... 2 Q: What VPN features are NOT in the older 6.x firmware, but are in SonicOS Standard/Enhanced?.................................. 2 Q: What VPN settings have been automated or simplified? ................................................................................................. 3 Q: How does the SonicWALL handle IKE Identities?............................................................................................................ 4 Q: How many VPN tunnels can a SonicWALL security appliance really handle? ................................................................. 5 Q: How many IP subnets can you define for a VPN policy? ................................................................................................. 6 Q: Can I set up VPN tunnels using third-party certificates? .................................................................................................. 6 Q: Can I use the built-in Windows XP IKE/IPsec client to make a VPN connection to a SonicWALL security appliance? ... 6 Q: Should I always use 3DES? What about DES? Or AES? ................................................................................................ 6 Q: What is ARCFour? ........................................................................................................................................................... 7 Q: Do all SonicWALLs support AES for IPsec VPNs? .......................................................................................................... 7 Q: Should I always use SHA-1? What about MD5?.............................................................................................................. 7 Q: My SonicWALL security appliance doesn’t have SHA-1 or PFS. Why?........................................................................... 7 Q: Who has SonicWALL demonstrated IKE IPsec compatibility with?.................................................................................. 7 Q: Where can I find technotes on how to set up VPN tunnels to third-party VPN security appliances? ............................... 8 Q: Are there any known issues with VPN third-party interoperability? .................................................................................. 8 Q: What is the VPN throughput of a SonicWALL? ................................................................................................................ 8 Q: What good does “enabling NetBIOS broadcasts” do? ..................................................................................................... 8 Q: What does the ‘Enable Fragmented Packet Handling’ checkbox do?.............................................................................. 9 Q: What does the ‘Ignore DF (Don’t Fragment) Bit’ checkbox do? ....................................................................................... 9 Q: How important is the ‘Deed Peer Detection’ (DPD) feature? ........................................................................................... 9 Q: What version of DPD (Dead Peer Detection) is SonicWALL using? ................................................................................ 9 Q: What’s the difference between ‘Dead Peer Detection’ and ‘Keepalive’?........................................................................ 10 Q: What does the ‘NAT Traversal’ checkbox do? ............................................................................................................... 11 Q: What version of NAT Traversal is SonicWALL using? ................................................................................................... 11 Q: What exactly does the built-in ‘GroupVPN’ policy do? ................................................................................................... 12 Q: Can I create multiple VPN policies to the same remote peer? ....................................................................................... 12 Q: What VPN clients can I use? ......................................................................................................................................... 12 Q: What is the Unique Firewall Identifier (UFI)? ................................................................................................................. 12 Q: What is ‘VPN single-armed’ mode? ............................................................................................................................... 13 Q: What is ‘DHCP over VPN’ and how does it work? ......................................................................................................... 13 Q: Do SonicWALL security appliances support ‘Mode Config’? ......................................................................................... 13 Q: Can SonicWALL security appliances accept L2TP connections? .................................................................................. 13 Q: Can I terminate VPN tunnels on any interface? ............................................................................................................. 13 Q: What does the ‘Forward Packets to Remote VPNs’ feature do?.................................................................................... 13 Q: What do the ‘VPN Terminated at’ radio buttons do in firmware 6.6 and SonicOS Standard? ........................................ 14 Q: Does the SonicWALL support XAUTH?......................................................................................................................... 14 Q: Can I force users to authenticate before accessing a site-to-site VPN tunnel?.............................................................. 14 Q: Can I set up a secondary VPN gateway for redundancy purposes? .............................................................................. 14 Q: What are the constraints on the Shared Secret field?.................................................................................................... 15 Q: What does the ‘Preserve IKE Port for Pass Through Connections’ checkbox do? ........................................................ 15 Q: What does the ‘Clean up active tunnels when Peer Gateway DNS name resolves to a different IP Address’ checkbox do?...................................................................................................................................................................................... 15 Q: What does the ‘Enable OCSP Checking’ checkbox do? ................................................................................................ 15 Q: Can multicast traffic run across VPN tunnels? ............................................................................................................... 15 Q: Do SonicWALL security appliances support IKEv2?...................................................................................................... 15 Q: Do SonicWALL security appliances support GRE?........................................................................................................ 15 Q: Can I set up manual key tunnels with SonicWALL security appliances? ....................................................................... 15
  2. 2. Q: Which VPN-related RFC’s and drafts are supported in SonicWALL firmware? A: In the older SonicWALL firmware 6.x (GEN2/GEN3), SonicOS 2.x/3.x Standard, and SonicOS 2.x/3.x Enhanced, the following are supported: RFC Title RFC 1825 Security Architecture for the Internet Protocol (obsoleted by RFC 2401) RFC 1826 IP Authentication Header (obsoleted by RFC 2402) RFC 1827 IP Encapsulating Security Payload (ESP) (obsoleted by RFC 2406) RFC 1828 IP Authentication using Keyed MD5 RFC 1829 The ESP DES-CBC Transform RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention RFC 2104 HMAC: Keyed-Hashing for Message Authentication RFC 2401 Security Architecture for the Internet Protocol RFC 2402 IP Authentication Header RFC 2403 The Use of HMAC-MD5-96 within ESP and AH RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV RFC 2406 IP Encapsulating Security Payload (ESP) RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC 2409 The Internet Key Exchange (IKE) RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec RFC 2411 IP Security Document Roadmap RFC 2451 The ESP CBC-Mode Cipher Algorithms RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) RFC 3602 The AES-CBC Cipher Algorithm and Its Use with IPsec RFC 3706 A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (Enhanced only) RFC 3947 Negotiation of NAT-Traversal in the IKE (Enhanced only) RFC 4306 Internet Key Exchange (IKEv2) Protocol (Enhanced only) Internet Drafts ‘Negotiation of Nat-Traversal in the IKE’, drafts 00 (Standard only) Q: What VPN features are NOT in the older 6.x firmware, but are in SonicOS Standard/Enhanced? A: Note the following: Ability to set individual Phase 2 lifetime Ability to set IKE Identity type and value (Enhanced only) Ability to configure per host and host ranges, as well as entire subnets for destination networks Ability to select user groups as well as users for inbound and outbound authentication on the VPN Tunnel (Enhanced only) Ability to apply NAT policies to enable you to select local and remote-translated networks (Enhanced only) Ability to enable or disable management and user login on a per-policy basis (Enhanced only) Ability to bind policy to a specific Zone or interface (Enhanced only) VPN bandwidth management in access rules and on a per-policy basis (Enhanced only) Fragmented packet handling on a per-policy basis (Enhanced only) Ability to restrict traffic on a policy-to-policy basis. Enables restrictions based on services, schedule, specific users and user groups (Enhanced only) 2
  3. 3. Q: What VPN settings have been automated or simplified? A single field defines the policy lifetime for Phase 1 and Phase 2 in 6.6.x and older firmware; the maximum policy lifetime for a SonicWALL is 9,999,999 seconds, and the minimum policy lifetime is 120 seconds. Older manuals and docs regarding SA lifetime may be incorrect (they state 2,500,000 as the max). SonicWALL uses time-based policy lifetimes. Other Firewall/VPN vendors implement data-based SA lifetimes as well as time-based policy lifetimes. The lifetime negotiation may differ depending on the value the remote peer gateway proposes. If the lifetime proposed by the remote peer gateway is lower than what the SonicWALL policy is set to, the SonicWALL will negotiate the VPN tunnel with the lower of the two values. IKE Identity is automatically set depending upon the mode in 6.6.x and SonicOS Standard. Sonic OS Enhanced firmware gives the user the option of setting the IKE Identity. Please refer to the next page for a full explanation of this topic. SonicWALL Firmware 6.6.x and SonicOS Standard do not have a configuration option for setting the Phase 2 ID type – it’s automatically set to ‘subnet’. For interoperability, the peer VPN gateway must also be configured to use subnet ID as the Phase 2 ID type. Using "Apply NAT & Firewall rules" will cause SonicWALL security appliances running firmware 6.x to send the SonicWALL’s WAN IP address with a 32-bit subnet mask as Phase 2 ID for the SonicWALL security appliance. As IKE Responder, SonicWALL can accept Diffie-Hellman 1, 2, or 5 (DH1, DH2, and DH5) - this is critical to remember when setting up a tunnel with a third-party security appliance. SonicWALLs support only ‘tunnel' mode and not ‘transport’ mode for site-to-site VPN connections - ‘tunnel’ mode is used for both ESP and for AH – although ‘transport’ mode is used for L2TP client connections. Replay Detection is automatically on for all IPsec traffic that uses IKE. Each IPsec packet has a Sequence Number that increases monotonically. The SonicWALL keeps a counter for IPsec packets on each VPN tunnel, and if it detects a packet that it has seen before, it is discarded. When a replayed packet is detected, the following message will appear in the log: "IPSEC Replay Detected". If attacks are checked under the ‘Alerts’ section in the log settings page, the SonicWALL will not do anything besides discarding the packet and incrementing an error counter that is usable for debugging. In firmware 6.2.0.0 and older, the mode (Aggressive or Main) is automatically negotiated by the SonicWALL security appliance during a VPN tunnel negotiation, depending on whether the peer gateway is explicitly specified or is absent (will negotiate in Aggressive if absent). In firmware 6.3.0.0 and newer, and in all versions of SonicOS Standard and SonicOS Enhanced, the administrator can explicitly set the mode (Aggressive or Main) for each policy. 3
  4. 4. Q: How does the SonicWALL handle IKE Identities? A: Note the following: Firmware 6.6.x using PSK In Aggressive Mode the security appliance sends ID_USER_FQDN as its Phase 1 ID, and accepts ID_USER_FQDN or ID_FQDN from the remote peer gateway. In Main Mode the security appliance sends ID_IPv4_ADDR as its Phase 1 ID, and accepts ID_IPv4_ADDR from the remote peer gateway. SonicOS 2.x/3.x Standard using PSK In Aggressive Mode the security appliance sends ID_USER_FQDN as its Phase 1 ID, and accepts ID_USER_FQDN or ID_FQDN from the remote peer gateway. In Main Mode the security appliance sends ID_IPv4_ADDR as its Phase 1 ID, and accepts ID_IPv4_ADDR from the remote peer gateway. SonicOS 2.x/3.x Enhanced using PSK In Aggressive Mode with a site-to-site tunnel to another SonicWALL security appliance not running Enhanced firmware, The Local IKE ID must be set to type SonicWALL Identifier (which is ID_USER_FQDN) and its value must be same as the policy “Name” field on the SonicWALL security appliance not running enhanced firmware. The Remote IKE ID must be set to type SonicWALL Identifier and its value needs to be the same as the “Unique Firewall Identifier” of the SonicWALL security appliance not running Enhanced. In Aggressive Mode with a site-to-site tunnel to another SonicWALL security appliance running Enhanced firmware, the user must configure the Local IKE ID and the Remote IKE ID. The user can pick from the following: Domain Name, Email Address, and SonicWALL Identifier. Please note that while there is an existing bug in all versions of SonicOS Enhanced 3.5.0.2 and older that will let you select IP Address as the IKE ID type, it will not work (IKE negotiations will fail). The Local IKE ID on system one must be the same type and have the same value as the Remote IKE ID on system two and vice-versa. In Main Mode, if the user has not set Local IKE ID or Remote IKE ID, which should be the case unless this is a site-to-site setup with another security appliance running Enhanced firmware, the security appliance sends ID_IPv4_ADDR as its Phase 1 ID, and expects ID_IPv4_ADDR from the remote peer gateway. Using Certificates The IKE ID is chosen from the Certificate contents as follows: If there is a subjectAltName of type ID_FQDN or ID_USER_FQDN, that type is selected and the value of the subjectAltName is sent (as a string, non-NULL terminated). If multiple subjectAltName's are present, the first ID_FQDN or ID_USER_FQDN is sent. If no subjectAltName is present, the subjectName is sent as a binary DER encoding of the ASN.1 X.500 Distinguished Name with type ID_DER_ASN1_DN. 4
  5. 5. Q: How many VPN tunnels can a SonicWALL security appliance really handle? A: First off, it’s important to understand that there are differences between the definitions of what a VPN tunnel is, what a Security Association (SA) is, and what a VPN policy is. SonicWALLs are licensed for VPN policies – which is a connection to a unique remote peer gateway. For example, the TZ170-U security appliance is licensed for ten VPN policies, which means that it is capable of setting up VPN connections with up to ten unique remote peer gateways. In some of our older documentation, SonicWALL used the generic term “VPN Tunnel”, or referred to them as “profiles”, which can be somewhat misleading. While “profiles” and “VPN policies” refer to the same thing, it’s extremely important to note that a “VPN tunnel” or “SA” should not be considered the same. Remember that with IKE IPsec, at least three SA’s are negotiated for each VPN tunnel – one Phase 1 IKE SA, and two unidirectional Phase 2 IPsec SA’s for each remote subnet. So on a TZ170-U, if you were to set up VPN tunnels to five unique remote peer gateways, and each had one remote subnet defined, you’re actually talking about 15 SA’s – and it would work fine. The following illustration helps you visualize the relationship between a VPN tunnel and a VPN policy: Phase 1 SA Phase 2 SA Phase 2 SA Phase 2 SA Phase 2 SA Phase 2 SA Phase 2 SA VPN Tunnel VPN Policy For SonicWALLs running older 6.x firmware, it gets a little more complex when you start adding lots of remote subnets to each VPN policy, as the SonicWALL has a shared memory pool, and other functions on the SonicWALL may utilize this pool. This means that if the SonicWALL has other functions active (for example: AV, CFS, extensive firewall policy entries, IPS, GAV, AntiSpyware), it may adversely affect your ability to set up new VPN policies or add additional subnets to existing VPN policies -- even if the security appliance is licensed for a specified number of policies. When our older documentation discusses how many “VPN Tunnels” or “profiles” each model can support, the number is really a best-case scenario, i.e. each VPN policy only has one remote subnet defined, the security appliance does not have that many rules, AV and CFS/CFL are not enabled, etc. NOTE: SonicWALLs running SonicOS Standard or SonicOS Enhanced do not have this limitation and can be configured for the advertised number of VPN Policies. 5
  6. 6. Q: How many IP subnets can you define for a VPN policy? A: On Standard, Phase 1 and Phase 2 SAs are not explicitly counted or limited. For Enhanced, please refer to the chart below. Platform *Max Default *Max Policies *Max Phase1 *Max Phase2 Policies’ Possible (after SAs SAs upgrade) TZ170 Family Enhanced 5 User 2 10 100 500 TZ170 Family Enhanced 10 User 2 10 100 500 TZ170 Family Enhanced 25 User 10 10 100 500 TZ170 Family Enhanced Unlimited 10 10 100 500 User PRO 1260 Enhanced 25 25 100 500 PRO 2040 Enhanced 50 50 200 1,000 PRO 3060 Enhanced 1,000 1,000 2,000 5,000 PRO 4060 Enhanced 3,000 3,000 6,000 12,000 PRO 4100 Enhanced 3,500 3,500 8,000 16,000 PRO 5060 Enhanced 4,000 4,000 10,000 20,000 Q: Can I set up VPN tunnels using third-party certificates? A: Yes. We support Verisign, RapidSSL, Thawte, Baltimore, RSA Keon, Entrust, OpenCA/OpenSSL, and Microsoft CA certificates for VPN tunnels from SonicWALL-to-SonicWALL. They are not supported for VPN tunnels between a SonicWALL security appliance and any third-party VPN security appliance (Check Point, Juniper, Cisco, etc). You can use certs to set up a tunnel between SonicWALL’s Global VPN Client (GVC) version 2.x and newer, and with SafeNet 9.x and newer if the SonicWALL is running SonicOS Enhanced 3.x and newer. Q: Can I use the built-in Windows XP IKE/IPsec client to make a VPN connection to a SonicWALL security appliance? A: Yes, but the setup & configuration on the Windows XPSP1/SP2 system is fairly complex and is not a trivial task. SonicWALL does not provide any technotes on its setup; users wishing to use the built-in IKE/IPsec client in Windows XP will need to contact Microsoft. SonicWALL strongly recommends using the SonicWALL Global VPN Client (GVC) instead, since it’s designed to work seamlessly with SonicWALL Firewall/VPN security appliances, and is incredibly easy to install, configure, and use. Q: Should I always use 3DES? What about DES? Or AES? A: That depends – if it is crucial that the data never be compromised, and both sides can support it, then 3DES, or even AES-256, is the way to go. Please note that older SonicWALL security appliances may not support AES, or will suffer performance impacts if using 3DES or AES. Security administrators by nature are paranoid (which you can argue is what they’re paid to be) and generally will want to use the most secure mechanisms possible for a VPN setup. As for DES, most security administrators no longer consider it secure, as it has been publicly demonstrated that it is susceptible to brute-force attacks given enough computing horsepower. For this reason, the FreeS/WAN project refused to even implement DES. 6
  7. 7. Q: What is ARCFour? A: ARCFour is an older encryption mechanism based on RC4. If you are setting up SonicWALL-to- SonicWALL VPN tunnels using GEN2 or earlier security appliances (TELE2, SOHO2, PRO/PRO-VX), you may wish to consider using ARCFour, since it is an extremely fast method of encryption and is not susceptible to any known attack. The drawback to ARCFour is that no other known vendor supports it as an encryption method for IPsec VPNs, and that it is not supported in any version of SonicOS. Q: Do all SonicWALLs support AES for IPsec VPNs? A: No. AES is supported in all versions of SonicOS Enhanced and all versions of SonicOS Standard. AES is supported on the following platforms for Firmware 6.6: PRO100, PRO200, PRO230, PRO300, PRO330, GX2500, GX6500, all SOHO3-based, all TELE3-based, and the SOHO TZW. Q: Should I always use SHA-1? What about MD5? A: There was a demonstrated attack against an older implementation of MD5, but the version of MD5 that SonicWALL implemented in its IKE/IPsec code is considered secure. MD5 is a 128-bit hash, while SHA-1 is a 160-bit hash. Using SHA-1 may result in a noticeable reduction in throughput with some older SonicWALL security appliances. Use SHA-1 if the security policy dictates that the maximum level of protection be used whenever possible. If not, use MD5. Q: My SonicWALL security appliance doesn’t have SHA-1 or PFS. Why? A: SHA-1 and PFS were not implemented until firmware 6.0.0.0. If you require either of those features, you will need to upgrade your SonicWALL’s firmware to a version newer than 6.0.0.0. If you have an older SonicWALL (like an original TELE or SOHO security appliance), using SHA-1 or PFS will not be possible, as they only support up to firmware 5.1.7. Q: Who has SonicWALL demonstrated IKE IPsec compatibility with? A: SonicWALL has verified compatibility with these vendors’ products: Cisco IOS IPsec Feature Set version 12.1.5T and newer Cisco PIX and ASA version 5.3.1 and newer Cisco 3000 VPN Concentrator version 3.0 and newer Juniper NS-Series 5/10/100/500/1000 version 2.0.1 and newer Nortel Contivity version 04_06_120 Checkpoint Firewall-1 version 4.0 and newer Checkpoint NG and newer Checkpoint NG on Nokia IPSO Watchguard SOHO 2.3 and newer Watchguard Firebox 6.x and newer Alcatel PermitGate 2500/4500 version 2.1 and newer Symantec Raptor version 6.5 and newer Symantec Firewall/VPN Gateway version 1.5 and newer NAI Gauntlet version 5.5 and newer PLEASE NOTE: Untested peers should interoperate as long as they abide by RFC’s 2407, 2408, and 2409. SonicWALL devices are ICSA 1.0d certified, so any other peer that is also ICSA 1.0d certified should also interoperate. 7
  8. 8. Q: Where can I find technotes on how to set up VPN tunnels to third-party VPN security appliances? A: All VPN interoperability technotes with third-party VPN security appliances can be found here: http://www.sonicwall.com/us/support/323.html#heading_3806. Interop docs are written and maintained by members of SonicWALL’s Architecture & Publications Group and are added/revised on a periodic basis. Q: Are there any known issues with VPN third-party interoperability? A: SonicWALL-to-Check Point seems to be more troublesome than most, but that’s mostly due to issues with Check Point’s IPsec implementation. Check Point also tends to make changes to their IPsec implementation every time they release a service pack -- you can almost count on SonicWALL-to-Check Point tunnels not working after you apply one. SonicWALL-to-Cisco 3000 VPN Concentrator (a.k.a. the Altiga) has been one of the more troublesome pairings, but the problem can be addressed by upgrading the firmware to 3.5 or newer on the Cisco security appliance, and Firmware 6.6.x, SonicOS 3.x Standard, or SonicOS 3.x Enhanced on the SonicWALL security appliance. Q: What is the VPN throughput of a SonicWALL? A: This number varies significantly from model to model and from SonicOS Standard to SonicOS Enhanced. The throughput numbers below were obtained using Spirent SmartBits models 200 & 600 RFC2544 testing against SonicWALLs running 3.1.x firmware. Testing criteria was UDP traffic, unidirectional mode, 1280 byte frame, NAT/Firewall Mode active, using 3DES cipher and SHA-1 hash. TZ 150 SonicOS Standard: 9.29 Mbps TZ 170 SonicOS Standard: 40.14 Mbps TZ 170 SonicOS Enhanced: 23.53 Mbps PRO 1260 SonicOS Standard: 28.37 Mbps PRO 1260 SonicOS Enhanced: 21.98 Mbps PRO 2040 SonicOS Standard: 34.74 Mbps PRO 2040 SonicOS Enhanced: 41.22 Mbps PRO 3060 SonicOS Standard: 74.84 Mbps PRO 3060 SonicOS Enhanced: 45.01 Mbps PRO 4060 SonicOS Enhanced: 100 Mbps PRO 5060 SonicOS Enhanced: 346.1 Mbps Q: What good does “enabling NetBIOS broadcasts” do? A: If both sides of the VPN tunnel are SonicWALL security appliances, it can greatly reduce the number of problems associated with Microsoft workgroup/domain networks, as the SonicWALL security appliances will forward all NetBIOS-Over-IP packets sent to the local LAN subnet’s broadcast address across the VPN tunnel(s). Microsoft networking, unless explicitly configured otherwise, is heavily dependent upon local LAN broadcast messages; normally, edge security appliances such as routers, firewalls, or VPN security appliances discard these broadcast messages. Please note that this is a SonicWALL-only feature – do not activate it if the remote peer gateway for a VPN tunnel is not a SonicWALL security appliance. It is not supported for client VPN connections to any version of SonicWALL’s Global VPN Client or Global Security Client. 8
  9. 9. Q: What does the ‘Enable Fragmented Packet Handling’ checkbox do? A: For various reasons, IPsec traffic can become fragmented in transit. If this checkbox is not enabled, then fragmented IPsec traffic will get dropped. If you are experiencing problems with traffic not successfully passing across VPN tunnels, please enable this feature. In SonicOS Enhanced 3.1.0.7 and newer, and SonicOS Standard 3.1.0.7 and newer, this checkbox is enabled by default. Q: What does the ‘Ignore DF (Don’t Fragment) Bit’ checkbox do? A: Some applications can explicitly set the ‘Don’t Fragment’ option in a packet, which tells all security appliances in between to not fragment the packet. This option, when enabled, causes the SonicWALL to ignore the option and fragment it anyways. This option is a sub-option of the ‘Enable Fragmented Packet Handling’ option and can only be enabled if it is too. Q: How important is the ‘Deed Peer Detection’ (DPD) feature? A: When IPsec was defined as a standard, they neglected to make recommendations for a common method to determine if a policy was still valid or not. When two sides negotiate IKE, they negotiate a Phase 1 SA, and then negotiate two or more Phase 2 SA’s for the traffic; all of these SA’s (and the keys associated) have a pre-set lifetime. If DPD is disabled, during the lifetime, both sides generally assume the SA’s and keys are valid, and generally not do any sort of validity checking. If either side crashes or reboots, the other side has no way to determine that the IPsec SA is no good anymore, and will continue to keep sending traffic using that IPsec SA across it until the lifetime expires. Since the other side no longer has that SA -- remember, it either crashed or rebooted, so it’s been flushed -- it will reject the traffic. The other side would have to also be rebooted to get it working, or you will need to initiate traffic from the side that crashed/rebooted, since that will cause a totally new IPsec SA to be built. The solution to the problem described above is to enable DPD on both sides of the VPN tunnel. This will cause the SonicWALL security appliance to perform periodic checks on the remote side, and clean up (delete) any negotiated IKE/IPsec SA to that peer that is no longer valid. Q: What version of DPD (Dead Peer Detection) is SonicWALL using? A: The DPD mechanism used in firmware 6.x, all versions of SonicOS Standard, and versions of SonicOS Enhanced prior to 2.5 is proprietary and will not interoperate with third-party VPN security appliances. The DPD mechanism used in SonicOS Enhanced 2.5 and newer is based upon RFC 3706 and can interoperate with any third-party VPN security appliance also adhering to this RFC. Please note that the proprietary DPD mechanisms in firmware 6.x and SonicOS Standard also interoperate with all versions of SonicOS Enhanced. 9
  10. 10. Q: What’s the difference between ‘Dead Peer Detection’ and ‘Keepalive’? A: Note the following: Dead Peer Detection (DPD) This feature, if enabled, is used to detect if the remote peer still has a valid IKE SA. If the SonicWALL has a tunnel established with a peer and the peer shuts down/reboots without notifying the SonicWALL, it will still try to use the older SA. To avoid this problem a proprietary dead-peer- detection mechanism was added for all firmware versions (6.1.x and newer, SonicOS Standard, SonicOS Enhanced), and RFC3706-compliant DPD was added to SonicOS Enhanced 2.5 and newer. If configured, the SonicWALL sends an ‘IKE NOTIFY:KEEP-ALIVE-REQUEST’ packet to the peer. If the peer also supports this mechanism, it will reply with an ‘IKE NOTIFY:KEEP-ALIVE-RESPONSE’ packet. These packets are encrypted & protected with Phase 1 SA (similar to quick mode messages). The peer can decrypt it correctly only if it still has the matching keys negotiated during Phase 1. This feature will work only with SonicWALL security appliances, and in the case of SonicWALL security appliances running SonicOS Enhanced 2.5 or newer, any remote peer that is also RFC3706- compliant. This mechanism is a simple detection scheme for peer liveliness. Essentially, the SonicWALL is periodically "pinging" the other end to see if it is alive. Please note that this feature will force an ISDN or modem dial-on-demand line to dial out if VPN policies are active. Remember that the SonicWALL is sending these ‘IKE NOTIFY:KEEP-ALIVE-REQUEST’ messages, as configured. These packets (UDP port 500) will cause the line to activate. KeepAlive This feature, if enabled, is used to keep a VPN tunnel constantly negotiated and up with the peer VPN gateway. If this feature is enabled, the SonicWALL periodically checks to see if a tunnel exists (Phase 2 SA exists) with the other end. If a tunnel is not found a new negotiation is started (will start an outbound IKE negotiation - UDP 500 packet). This means that the tunnel will be established even when there is no network traffic to the other end. The SonicWALL checks on a configurable timer to see if it has an IPsec SA (Phase 2 SA) with the other end. This feature in itself does not send any extra packets. This feature can operate without DPD but will operate best in conjunction with DPD active. Please note that this feature will also force an ISDN line to dial out, as noted above. There have been a few changes with the introduction of SonicOS Enhanced firmware – it no longer periodically checks for valid Phase 2 SA’s. Instead, it traps all tunnel teardown & failure conditions and initiates a new negotiation if “Keep Alive” is turned on. 10
  11. 11. Q: What does the ‘NAT Traversal’ checkbox do? A: NAT Traversal, if enabled, automatically detects if network address translation (NAT) is being performed between the two VPN tunnel endpoints, since this “in-between” NAT can interfere with IPsec/ESP traffic – also, some routers that may exist between the VPN peers might be programmed to block IPsec pass-through, or have been programmed to block IP 50 (ESP). If NAT is indeed being performed somewhere between those two endpoints, and both endpoints are capable of doing NAT Traversal, the IPsec traffic will be encapsulated within UDP packets. Encapsulating the IPsec traffic in UDP packets allows the IPsec traffic to be NAT’ed in between the endpoints. This feature is also supported in all versions of SonicWALL’s Global VPN Client and Global Security Client. SonicWALL’s implementation of NAT Traversal is based upon RFC 3947, in SonicOS Enhanced 3.2.x and newer. How it works: NAT Traversal is achieved by sending the NAT Traversal Vendor ID field in the first two messages in Main Mode and Aggressive Mode. A MD5 Hash (draft-ietf-IPsec-nat-t-ike-00) is sent as Vendor ID hash. Upon the receipt of this Vendor ID, both sides can decide whether the other end supports NAT Traversal or not. A new payload called “NAT-Discovery” payload is sent in the message 2 and 3 in Main Mode, and message 2 and message 3 in the Aggressive Mode. The HASH function negotiated in the IKE is used in the HASH calculation. It can be MD5 or SHA. After receiving the NATD payload the IPsec Tunnel endpoints can determine whether a NAT security appliance is in between by computing the HASH values locally and comparing with the HASH values received. If a NAT security appliance is detected in between the endpoints, in the phase 2 Quick mode instead of ESP Attribute, UDP_TUNNEL_ESP ->61443 or UDP_TRANSPORT_ESP ->61444 is sent depending on Tunnel/Transport mode. If a NAT security appliance is not detected then there is no change in the Quick Mode. Once the IPSEC SA is negotiated in the Quick Mode, the ESP packets should be encapsulated in the UDP header. The UDP encapsulation should use the same source and destination port as used in the IKE negotiations – however, in draft 3, the UDP port is floated to 4500. The UDP encapsulation should be done only when a NAT security appliance is present in between the endpoints. The Phase 1 initiator will send the keepalives. The keepalive is just to keep up the NAPT mapping with the NAT security appliance in between. Q: What version of NAT Traversal is SonicWALL using? A: SonicWALL implemented the NAT_Tv00 draft in these firmware versions: 6.6.x, SonicOS 2.0.0.9 Standard, SonicOS 2.0.1.5 Enhanced, and all subsequent versions. Additionally, the NAT_Tv03 draft is implemented in SonicOS Standard/Enhanced 2.5 and newer. RFC 3947 is supported in SonicOS Enhanced 3.2.x and newer. 11
  12. 12. Q: What exactly does the built-in ‘GroupVPN’ policy do? A: The 'GroupVPN' is hard-coded to accept incoming connections from any peer gateway (in this case, the peer gateways are VPN Clients). The 'GroupVPN' doesn't have an 'add network' capability - instead it accepts the IP subnets that are directly attached to the interface the GroupVPN terminates on and/or any static routes on the LAN and/or additional LAN subnets defined. These subnets are used as the phase 2 networks to negotiate. The 'GroupVPN' is also hard coded to Aggressive Mode, and cannot be changed. And, the 'GroupVPN' has the 'Export Settings' button that takes all the settings and crunches them into a SPD and/or RCF file, compatible with the SafeNet IRE 5.x/8.x/9.x/10.x client. The ‘GroupVPN’ SA cannot be deleted – only disabled (by default, it is disabled). The ‘GroupVPN’ policy accepts ID_USER_FQDN, ID_FQDN or ID_IPV4_ADDR as the remote gateway (client) IKE Identity, but it doesn’t actually validate the value – it just accepts it. SonicOS Enhanced adds more flexibility to the GroupVPN policy: Ability to specify destination networks on a per user and/or User Group basis (please note that by default, no destination networks are included and must be configured before use). Apply firewall rules for VPN traffic on a per user and/or User Group basis. Added the ability to use this gateway itself to route all Internet traffic from VPN Clients instead of a separate gateway on the LAN. If VPN access network is a range, it is parsed and automatically consolidated, then downloaded to the VPN client. When XAUTH is not enabled, extended functionality to allow unauthenticated users access to specific destination networks. Q: Can I create multiple VPN policies to the same remote peer? A: Yes, but this feature is only supported in SonicOS Enhanced 3.x and newer. Please note that if two policies are created to the same peer, then their Phase 1 protocols, Phase 1 ID, and secondary gateway information must match for both policies. If it doesn’t, the SonicWALL will overwrite the previous policy with the new information. Q: What VPN clients can I use? A: In firmware 6.4.x, SonicOS Standard, and SonicOS Enhanced, you can use SonicWALL Global VPN Client 1.x/2.x/3.x, SonicWALL Global Security Client 1.x, SonicWALL, Pocket GVC, IRE SafeNet Client 8.x/9.x/10.x, the built-in IKE/IPsec connector in Windows XPSP1/SP2, and Equinux’s ‘VPN Tracker’ for Apple Macintosh systems (setup papers can be found here: http://www.equinux.com/us/products/vpntracker/interoperability.html). Q: What is the Unique Firewall Identifier (UFI)? A: SonicWALL security appliances use the UFI as the default IKE Identity when negotiating Aggressive Mode VPN tunnels. The entry, which can be found on the main VPN GUI page of all SonicWALL security appliances, defaults to the SonicWALL’s MAC address, but can be customized to any value. The IKE Identity type for this field is ID_USER_FQDN. 12
  13. 13. Q: What is ‘VPN single-armed’ mode? A: This feature allows a SonicWALL security appliance running firmware 6.2.x or SonicOS Standard (and newer) to act as a stand-alone VPN gateway, with the WAN port utilized as a VPN tunnel termination point. Clear text traffic is statically routed to the WAN interface via internal routing process, and the data is encapsulated to the appropriate remote peer gateway. If ‘VPN Single-Armed Mode (stand-alone VPN gateway)’ is enabled, a dialog box appears with the following message: Selecting "VPN Single Armed mode" will make this security appliance accessible only from the WAN interface. This option will modify the intranet mode and will automatically add a HTTPS WAN management rule. Please note that this feature only works if the SonicWALL is in transparent mode. Q: What is ‘DHCP over VPN’ and how does it work? A: This feature is supported in Firmware 6.4 and above, and in all versions of SonicOS. It allows remote SonicWALL security appliances to forward all LAN-side or DMZ/OPT-side DHCP requests off to a remote DHCP server located on the other side of a VPN tunnel, instead of using the SonicWALL’s internal DHCP server. The feature is popular in hub-and-spoke environments where administrators want to issue all DHCP leases from a centralized source, regardless of whether the requesting clients are local or remote users. By using this feature, all scopes can be created, controlled, and monitored from a central location, instead of having to set up unique scope info on each remote SonicWALL security appliance. Q: Do SonicWALL security appliances support ‘Mode Config’? A: No. SonicWALL is currently working on this for a future version of SonicOS, with no ETA for delivery at present. In IKEv1, Mode Config is not a standard. There are expired Internet Drafts specifying Mode Config and several vendor-specific implementations exist. In IKEv2, Config payloads are standardized and replace the proprietary IKEv1 mechanism. Q: Can SonicWALL security appliances accept L2TP connections? A: Yes – all versions of SonicOS Standard and SonicOS Enhanced have a built-in L2TP-over-IPsec server that can terminate incoming L2TP connections. This feature is not supported in any 6.x firmware release, or any of the older firmware releases. Q: Can I terminate VPN tunnels on any interface? A: Yes, but the SonicWALL must run SonicOS 2.5 Enhanced or newer. If it is, it’s possible to terminate VPN tunnels on any interface for incoming Global VPN Client connections as well as site-to-site VPN tunnels. This feature is not supported in any version of firmware 6.x or SonicOS Standard. Q: What does the ‘Forward Packets to Remote VPNs’ feature do? A: This feature can be used to set up “hub-and-spoke” VPN networks in SonicOS Standard and firmware 6.6.x, where the administrator wishes to allow the remote sites to access each other via the central site. This feature eliminates the need to set up a full-mesh VPN environment. This feature is enabled on all SA’s on the central site that need to communicate with each other; on each remote site, it will be necessary to list all the central and remote peer destination networks in the VPN policy leading to the central site in order for each remote site to connect to the other remote sites. 13
  14. 14. Q: What do the ‘VPN Terminated at’ radio buttons do in firmware 6.6 and SonicOS Standard? A: In these two firmware OS’s, it’s not possible to manually specify the local networks (initiator Phase 2 Proxy ID) the SonicWALL security appliance will propose during Phase 2 IPsec negotiations. Instead the local networks are implicitly selected based upon the value for the ‘VPN Terminated at’ option. When Keepalives are enabled: If the value is ‘LAN’ the SonicWALL will propose all LAN subnets – this includes any secondary networks bound to the LAN interface as well as any static IP routes set on the LAN interface. If the value is ‘OPT’ (or WLAN, in the case of the SOHO TZW, TZ 170W, and TZ 150W) then It will propose all networks bound to the OPT interface. If set to ‘LAN/OPT’, it will send all of the above. This will work only if the ‘Enable Keep Alive’ and ‘Try to bring up all possible Tunnels’ options are checked on the VPN policy’s ‘Advanced’ tab. When Keepalives are NOT enabled: The SonicWALL will do a route lookup on the traffic attempting to access a remote network defined in a VPN policy and will only propose the local network matching that traffic. It will not automatically propose the LAN subnet(s), or a static route, or the OPT subnet. If a SonicWALL running 6.x firmware or SonicOS Standard is the responder, and receives a Phase 2 Proxy ID that does not belong to the ‘VPN Terminated’ selection then that Phase 2 negotiation fails. Q: Does the SonicWALL support XAUTH? A: Yes, and incoming users can be authenticated against the internal user database of the SonicWALL or against an external RADIUS, LDAP, or Microsoft Active Directory server. Please note that Microsoft Windows 2000 Server and Microsoft Windows 2003 Server come with a free RADIUS snap-in that allows external security appliances (such as a SonicWALL) to query Active Directory for usernames/passwords using RADIUS. Q: Can I force users to authenticate before accessing a site-to-site VPN tunnel? A: Yes, this is possible if the SonicWALL is running firmware 6.4 or above, or any version of SonicOS. Authentication can be enforced in either direction of the tunnel, and the usernames/passwords can be polled either from the internal database on the SonicWALL security appliance, or passed onto external RADIUS/LDAP/Microsoft Active Directory servers. If this feature is activated, the user must first navigate to the SonicWALL’s LAN IP address using a web browser and successfully authenticate, before their traffic is allowed across the tunnel. This feature is particularly useful in home-office environments where the primary user requires access across a VPN tunnel to his or her corporate office, but there are other people also utilizing the home-office connection for public Internet connectivity that should not be allowed access to corporate resources across the tunnel. Using authentication on VPN tunnels solves this problem. Q: Can I set up a secondary VPN gateway for redundancy purposes? A: Yes, this feature, if configured, is available in firmware 6.6 and above, and SonicOS 2.0 Standard/Enhanced and above. The feature allows a remote “spoke” security appliance, such as a SonicWALL TZ 170, to utilize a primary remote peer as its main VPN gateway. The remote SonicWALL security appliance uses Dead Peer Detection to check the status of the primary remote peer; if the primary remote peer stops responding, the remote SonicWALL security appliance will renegotiate the VPN tunnel with the secondary remote peer – this may be another SonicWALL security appliance entirely, or it may even be the secondary WAN port of the primary remote peer. 14
  15. 15. Q: What are the constraints on the Shared Secret field? A: The Shared secret must be a minimum of four characters and a maximum of 128 characters. Q: What does the ‘Preserve IKE Port for Pass Through Connections’ checkbox do? A: This option, when enabled, allows internal Check Point Securemote/Secureclient VPN connections to pass through the SonicWALL. By default this checkbox is not enabled and should be left that way unless there are Check Point VPN client connections on the internal network(s). NOTE: If this option is enabled it will cause connectivity issues with other third-party VPN clients, as well as SonicWALL’s GVC/GSC. Do not enable this feature unless running Securemote/Secureclient through the SonicWALLs is an absolute requirement. Q: What does the ‘Clean up active tunnels when Peer Gateway DNS name resolves to a different IP Address’ checkbox do? A: This option, when enabled, will force the SonicWALL to monitor the ‘IPsec Primary Gateway Name’ field in all active VPN policies; if the name resolves to a different IP address (say, in the case of a peer WAN IP that is dynamically obtained), the policy’s tunnel will be brought down. Q: What does the ‘Enable OCSP Checking’ checkbox do? A: OCSP, short for Online Certificate Status Protocol, is a real-time method of checking the validity of a digital certificate during VPN negotiation. This option is used when certificates have been used as the authentication mechanism for a VPN Policy; if enabled, the SonicWALL will contact a remote validating entity (configured in the ‘OCSP Responder URL’ sub-option) to see if the certificate sent by the remote peer is valid. Q: Can multicast traffic run across VPN tunnels? A: Yes, but only if the SonicWALL is running SonicOS Enhanced 3.x or later. Q: Do SonicWALL security appliances support IKEv2? A: Yes, this is supported in SonicOS Enhanced 3.2.x and newer, using preshared keys only. It is not supported in any version of SonicOS Standard and never will be. Q: Do SonicWALL security appliances support GRE? A: All versions of SonicOS Enhanced can pass GRE across its interfaces (if configured in the firewall rules to do so), but cannot initiate or terminate GRE tunnels. SonicOS Standard and firmware 6.x cannot pass GRE and cannot initiate or terminate GRE tunnels. There are no plans for any version of SonicWALL OS to initiate or terminate GRE tunnels. Q: Can I set up manual key tunnels with SonicWALL security appliances? A: Yes, this is supported in all SonicWALL OS releases, regardless of version. Document created: 6/5/2002 Last updated: 6/22/2007 Version 2.0 Maintainer: Dave Parry 15

×