Vous êtes sur la page 1sur 21

TECHnotes

Guide to SonicWALL Advanced VPN Options

Prepared by SonicWALL, Inc Author: Paul Calvo Document Version 1.1 March 6, 2002

! Preface

! Using the ‘Apply NAT and Firewall Rules’ Feature

! Using the ‘Forward Packets To Remote VPN’s’ Feature

! Using the ‘Route All Internet Traffic Through This SA’ Feature

! Advanced VPN Client Configurations

! Extending SonicWALL functionality with 3 rd Party Products

! Glossary Of Security Association Parameters

! Glossary Of Advanced VPN Settings

! Overview of The IKE Protocol

Preface

The purpose of this document is to explain some of the advanced features and functionality available when using SonicWALL VPN to connect appliances and VPN software clients. In addition it is hoped that the various examples and different scenarios that will be illustrated will help to spark the readers creativity to experiment and find new ways to leverage and utilize SonicWALL’s VPN capabilities. The SonicWALL VPN implementation is very powerful and very flexible, and as such can be adapted to suit a variety of environments with diverse requirements. (Note: All of the examples in this document are based on firmware version 6.2.x.x)

Using the ‘Apply NAT and firewall Rules’ feature

First of all lets look at the normal behavior of a site-to-site tunnel. All VPN traffic terminates at the firewalls LAN interface. Figure 1 illustrates this.

Normal Site-to Site VPN (no advanced options in use) WAN IP 216.215.77.73/29 Headquarters SA Name=SiteA
Normal Site-to Site VPN
(no advanced options in use)
WAN IP 216.215.77.73/29
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Destination Network=192.168.2.0
SubnetMask=255.255.255.0
WAN IP 216.215.77.65/29
Advanced Option(s)=None
Site
A
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Destination Network=192.168.3.0
SubnetMask=255.255.255.0
Advanced Option(s)=None
Site A
SA Name=HQ
192.168.2.2
192.168.3.2
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
WAN IP 216.215.77.57/29
SubnetMask=255.255.255.0
Advanced Option(s)=None
Site B
HQ
LAN IP 192.168.1.1/24
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
SubnetMask=255.255.255.0
Advanced Option(s)=None
192.168.1.2
Figure 1.

In this example it’s easy to see why one of the requirements for connecting multiple sites via VPN tunnels is that all internal network-addressing schemes be unique. In the above scenario, if both remote sites shared the same internal network-addressing scheme (e.g. 192.168.2.0/24) then each of the SA’s defined at the firewall at HQ (SiteA and SiteB) would have to specify the same destination network, which would

result in an invalid configuration. Think about it, if more than one SA had the same destination network defined in it, when the firewall saw a packet destined for one of those destination networks how would it know which SA to use to encrypt and send the outbound traffic? Fortunately the SonicWALL’s management interface won’t allow you to create this kind of invalid configuration. If you inadvertently attempt to do so, it will return an error message informing you of a problem when you try to save.

In a situation where there are remote sites with overlapping network-addressing schemes and it is not practical for the administrator to redo the addressing schemes to make them all unique prior to implementing VPN connectivity, the ‘Apply NAT and Firewall Rules’ option provides a solution. This feature was developed for two main reasons:

1) To allow multiple remote sites that share the same internal network-addressing scheme to connect to a central site. 2) To provide a method for controlling what type of traffic is permitted and what is accessed through the VPN tunnel.

Because enabling this feature affects the fundamental architecture of how VPN tunnels are constructed, when implementing this feature there are several important design issues that need to be considered. The easiest way of understanding this feature, it’s capabilities and the related design requirements is to realize that the VPN tunnel is now essentially terminated on the WAN interface of the firewall vs. the LAN interface as in normal mode. Typically this feature is enabled on only one side of the tunnel essentially allowing one side unrestricted access to internal resources while restricting access from the other side. Terminating and decrypting the IPSEC packets at the WAN interface gives us some new flexibility controlling VPN traffic.

In order for a SonicWALL appliance to apply firewall rules to TCP/IP traffic, that traffic must flow unencrypted through both interfaces (WAN # LAN or LAN # WAN). This is by design. As was previously mentioned, in the normal implementation of a site-to-site tunnel, all VPN traffic terminates at the firewalls LAN interface. This means that while the traffic does flow through both interfaces it is encrypted while flowing through the WAN interface therefore preventing any rules from being applied to it. When terminating the VPN at the WAN interface, the IPSEC traffic from a remote site that flows through the firewall (from WAN # LAN) is now is unencrypted which gives us the ability apply access rules to it.

This is most useful in a scenario where the remote site is initiating all of the communication such as in a branch office/home office scenario. In a home office scenario it also has the added benefit of ensuring that users on the corporate network cannot access the home office users’ private network.

Applying Firewall Rules In our scenario if there were a requirement for a host or hosts on the corporate network to access resources on the branch office network, an access rule can be created to allow this. The syntax of this rule would specify either a specific address or range of addresses on the corporate network as the Source (on interface WAN) and the address of the resource at the branch site as the destination (on interface LAN). This may seem confusing at first because you are specifying private address as a source on the WAN interface but if you remember that when enabling the ‘Apply NAT and Firewall Rules’ option the VPN tunnel is terminated on the WAN interface it makes sense. The following is an example of such a rule:

 

Action

Service

Source

Destination

Time

Day

Enable

 

192.168.1.1 – 192.168.1.254 (WAN)

192.168.3.2

  192.168.1.1 – 192.168.1.254 (WAN) 192.168.3.2

1

Allow

Web (HTTP)

(LAN)

In this example, the preceding rule would allow hosts on the corporate network (192.168.1.0) to access a web server (192.168.3.2) running on the branch office network through the secure VPN tunnel. Important: This resource would be accessed via the WAN IP address branch office’s firewall.

Configuration Tips

Although it is possible to configure the VPN so that both firewalls participating in the site-to-site tunnel have this feature enabled, it is much simpler to configure if only one side does. In most all scenarios this should suffice. Page 2 of 21

The ‘Destination Network’ defined in the SA at HQ should be either the WAN IP address of the remote firewall with a mask of 255.255.255.255 or, if the remote site has been given multiple public addresses you may make this the actual IP network number and specify the corresponding subnet mask (network=216.215.77.64, mask=255.255.255.248, address range=216.215.77.65-

71).

The ‘Destination Network’ defined in the SA at the remote site(s) should be the IP network number of the LAN interface of the firewall at HQ. Figure 2 illustrates this.

VPN Using the NAT & Firewall Rules (Static WAN IP address at remote site) WAN
VPN Using the NAT & Firewall Rules
(Static WAN IP address at remote site)
WAN IP 216.215.77.73/29
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Destination Network=216.215.77.72
SubnetMask=255.255.255.248
WAN IP 216.215.77.65/29
Advanced Option(s)=None
Site
A
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Destination Network=216.215.77.64
SubnetMask=255.255.255.248
Advanced Option(s)=None
Site A
SA Name=HQ
192.168.2.2
IPSEC Gtwy=216.215.77.57
192.168.3.2
Destination Network=192.168.1.0
WAN IP 216.215.77.57/29
SubnetMask=255.255.255.0
Advanced Option(s)
$ Apply NAT and Firewall Rules
Site B
HQ
LAN IP 192.168.1.1/24
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
SubnetMask=255.255.255.0
Advanced Option(s)
$ Apply NAT and Firewall Rules
192.168.1.2
Figure 2.

If the remote sites have dynamically assigned WAN IP addresses this feature can still be implemented but there is an additional requirement and that is that the SA(s) must be manual key. Upon examination, the reason for this becomes clear. Since when this option is turned on at a remote site the central site must specify the remote sites’ WAN IP address as the destination network and since there is no way of knowing beforehand what that will be, the central site must specify the destination network as 0.0.0.0 in this scenario. Of course the IPSEC Gateway has to be set to 0.0.0.0 as well. The SonicWALL device only allows these two conditions to exist in a manual key VPN, henceforth the reason for this requirement. Figure 3 illustrates this.

VPN Using the NAT & Firewall Rules (Dynamic WAN IP address at remote site) WAN
VPN Using the NAT & Firewall Rules
(Dynamic WAN IP address at remote site)
WAN IP
Dynamic
WAN IP
Dynamic
Headquarters
SA Name=SiteA (Manual Key)
IPSEC Gtwy=0.0.0.0
Destination Network=0.0.0.0-0.0.0.0
Subnet Mask=255.255.255.255
Advanced Option(s)=None
Site
A
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
SA Name=SiteB
IPSEC Gtwy=0.0.0.0
Destination Network=0.0.0.0-0.0.0.0
Subnet Mask=255.255.255.255
Advanced Option(s)=None
Site A
SA Name=HQ
192.168.2.2
192.168.3.2
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
WAN IP 216.215.77.57/29
Advanced Option(s) Enabled
$ Apply NAT and Firewall Rules
HQ
LAN IP 192.168.1.1/24
Site B
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
Subnet Mask=255.255.255.0
Advanced Option(s)
$ Apply NAT and Firewall Rules
192.168.1.2

Figure 3.

How can I use this feature? I’m a Managed Service Provider and I want to have full access to my customers’ network but don’t want them accessing my internal network…. Enable the feature on your firewall and set your customers’ firewalls destination network to you firewalls’ WAN IP address.

I want to connect multiple remote sites with the same internal IP addressing scheme to a central site….

Set it up as in the prior discussion. Enable the feature on the remote firewalls and set your firewalls’ destination network to the remote firewalls WAN IP address.

I want to connect two sites with the same internal addressing scheme….

In this scenario, you can actually enable this feature on both firewalls. In this configuration rules will have to be specifically created to allow access to any internal resource on either side. If there is only one IP

address available on each side, all internal resources will have to be accessed via the WAN IP address of the far end. The limitation of this is that you can only access one instance of a given resource.

If you’re ISP has provided you with multiple IP addresses, you can optionally use these to access internal

resources and multiple instances of the same internal resource. This is done by mapping a public addresses to an internal resources private IP address via one-to-one NAT. In this scenario the destination network on the on each side would be the appropriate network number for the stub subnet (e.g. usable

address range: 216.215.77.57 – 62, network number: 216.215.77.56, subnet mask: 255.255.255.248)

Using the ‘Forward packets to Remote VPN’s’ feature

If you have multiple remote sites and wish to have full connectivity between all of them you can create

SA’s between all sites. This is referred to as a “Full Mesh” topology. The “Full Mesh” while providing excellent redundancy begins to get messy as the number of remote sites increases. SonicWALL provides

an alternative to this with the ‘Forward Packets to Remote VPN’s’ feature. This feature allows you to build

a “Hub and spoke” VPN network.

The “Hub and Spoke” works exactly as the name implies, all remote sites (spokes) have a single SA defined that connects them back to the central site (hub). When remote site send traffic destined to another remote site, the central site forwards the traffic to the appropriate SA. The “Hub and Spoke” achieves the same effect as the “Full Mesh” but is generally is easier to configure and maintain.

.

Configuration Tips

At the central site enable this feature for all SA’s you want to forward traffic to and from. At the

remote sites (spokes) define all of the destination networks for all the remote sites you need to communicate with, in the single SA that connects it back to the central site. Figure 4 illustrates this.

"Hub and Spoke" with Full Connectivity

Site A LAN IP 192.168.2.1/24 Site B LAN IP 192.168.3.1/24 192.168.2.2 192.168.3.2 HQ LAN IP
Site
A
LAN IP 192.168.2.1/24
Site
B
LAN IP 192.168.3.1/24
192.168.2.2
192.168.3.2
HQ
LAN IP 192.168.1.1/24
192.168.1.2
Headquarters SA Name=SiteA Destination Network=192.168.2.0 Advanced Option(s) Enabled $ Forward Packets To Remote
Headquarters
SA Name=SiteA
Destination Network=192.168.2.0
Advanced Option(s) Enabled
$ Forward Packets To Remote VPN's
SA Name=SiteB
Destination Network=192.168.2.0
Advanced Option(s) Enabled
$ Forward Packets To Remote VPN's
Site A
SA Name=HQ
Destination Network(s)
$ 192.168.1.0
$ 192.168.3.0
Site B
SA Name=HQ
Destination Network(s)
$ 192.168.1.0
$ 192.168.2.0

Figure 4.

Using the ‘Route All Internet Traffic Through This SA’ feature

Split tunneling" refers to having separate paths. For example if Site B is connected via a VPN tunnel to Site A and Site B sends traffic destined to Site A, that traffic is encrypted and sent through the tunnel however if Site B opens a web browser and goes to a public web site, that traffic flows directly to the Internet. Split tunneling is enabled in this case. If split tunnels are disabled, this same traffic would be forced to go across the VPN tunnel to Site A and then back out Site A’s firewall to its Internet destination.

For security reasons you may want to disable split tunneling at remote sites. If your remote users are allowed to access the Internet without restriction, more than likely they'll be downloading all kinds of high- risk material. Disabling split tunneling allows you to maintain more control over your remote users by centrally monitoring and controlling where they go on the public Internet. Preventing any direct communication with the Internet (other than through the VPN tunnel) goes a long way towards creating a secure environment. Disabling split tunneling provides some other advantages as well such as the ability to centrally deploy a content filtering or anti-virus solution.

The ‘Route All Internet Traffic Through This SA’ feature allows you to disable Split Tunneling at remote sites. What this means is that you can actually force all outgoing traffic whether it be destined for an internal host or the public Internet to go through a given SA, rather than directly accessing the Internet.

Configuration Tips

This feature is most commonly implemented when you have two SonicWALL devices, one acting as a VPN concentrator and the other as the Internet firewall.

This functionality uses two options that work together. They are ‘Route All Internet Traffic Through This SA’ (at the remote site) and ‘Default LAN Gateway’ (at the central site). Only one SA can have this feature enabled.

At the remote site(s) you wish to disable split tunneling, enable the ‘Route All Internet Traffic Through This SA’ feature. At the central site enter the IP address of the router that all traffic from the remote VPN should be routed through in the ‘Default LAN Gateway’ field (Note: The help file says, “At the central site enter the SonicWALL LAN IP address or the IP address of the router that all traffic from the remote VPN should be routed through”. This is incorrect. A limitation of this feature is that it only works when the firewall the VPN terminates at, is NOT the default LAN gateway. This means you must have another exit point that Internet traffic flows through). Figure 5 illustrates this.

Disabling Split Tunneling

WAN IP 216.215.77.73/29 WAN IP 216.215.77.65/29 Site A LAN IP 192.168.2.1/24 Site B LAN IP
WAN IP 216.215.77.73/29
WAN IP 216.215.77.65/29
Site
A
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
192.168.2.2
192.168.3.2
WAN IP 216.215.77.58/29
WAN IP 216.215.77.57/29
HQ-VPN Concentrator
LAN IP 192.168.1.2/24
HQ-Firewall
LAN IP 192.168.1.1/24
Switch
192.168.1.3
Headquarters-Firewall Static Routes Defined to all Remote Sites (e.g. Network 192.168.2.0 via 192.168.1.2, network
Headquarters-Firewall
Static Routes Defined to all Remote Sites
(e.g. Network 192.168.2.0 via 192.168.1.2,
network 192.168.3.0 via 192.168.1.2)
Headquarters-VPN Concentrator
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Destination Network=192.168.2.0
SubnetMask=255.255.255.0
Advanced Option(s)
$ Default LAN Gateway=192.168.1.1
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Destination Network=192.168.3.0
SubnetMask=255.255.255.0
Advanced Option(s)
$ Default LAN Gateway=192.168.1.1
Site A
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
SubnetMask=255.255.255.0
Advanced Option(s)
$ Route all Traffic Through This SA
Site B
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network=192.168.1.0
SubnetMask=255.255.255.0
Advanced Option(s)
$ Route all Traffic Through This SA

Figure 5.

Advanced VPN Client configurations

If you have multiple locations and need remote VPN client user to access them, you have several options. The simplest method is to enable the Group VPN on each remote location and create a new connection in the VPN client corresponding to each remote location where access is required. This has the disadvantage of requiring the administrator to enable and maintain the ‘GroupVPN’ SA at each location and also having to manually configure additional connections at the client. An alternative to this is to use the ‘Hub and Spoke’ functionality of the SonicWALL. Leveraging this feature allows you to configure VPN clients that access multiple locations through a single connection and single GroupVPN SA.

Before we take a look at some design options, it is important to know a few things about the SonicWALL VPN client. Its normal behavior when connecting to SonicWALL devices is to simply use whatever IP address the ISP has assigned it (as in the case of dialup or a non-NAT’ed broadband connection) or the IP address of an intermediary NAT device. What this means is that the SonicWALL “sees” the VPN connection coming from whatever that address may be. The client does however provide an advanced option to statically configure the IP address it will use to establish VPN tunnels. Selecting ‘Options -> Global Policy Settings -> Allow to specify internal Network Address’ allows you to configure this. If you specify this address, a requirement is that it must be on a different subnet than the LAN IP address of the SonicWALL the VPN clients will be connecting to. For purposes of this discussion, we’ll l refer to these addresses as ‘VPN Client Addresses’.

In the first example we are going to assume that the VPN clients have not been assigned a VPN Client Address. Since this is the case we must make sure that the SonicWALL devices at the Remote Site A and Remote Site B allow IPSEC traffic from a host without having to know what IP address that host will be using beforehand. This is accomplished by specifying an IPSEC gateway of 0.0.0.0 for the SA that connects it to HQ. So even though HQ may indeed have a static IP address this is a requirement. Otherwise the remote sites would reject the VPN client IPSEC traffic as illegal. The disadvantage of this is that as in any static/dynamic VPN tunnel pair, the dynamic side must initiate the tunnel. Of course once the tunnel was up enabling the ‘KeepAlive’ feature would help ensure it

Note: If you set the VPN clients up with VPN Client Address you bypass the requirement of configuring remote sites for dynamic SA’s. This however requires that you specify an IP address for each VPN client user. Selecting ‘Options -> Global Policy Settings -> Allow to specify internal Network Address’ allows you to configure this.

stayed up.

At the VPN client the configuration is easy. If all of the internal networks fall within the same address range (e.g. 192.168.1.0/24, 192.168.2.0/24, etc.), you can simply supernet the subnet specified under ‘Remote party Identity and Addressing’ (e.g. Subnet: 192.168.0.0. mask: 255.255.0.0) to encompass all of the destination networks. If the destination networks fall within different address ranges (e.g. 10.1.0.0, 172.16.1.0, 192.168.1.0, etc.) then you simply create a copy of the connection and change the subnet and mask under ‘Remote party Identity and Addressing’ accordingly. Figures 6, 7 & 8 illustrate this.

party Identity and Addressing’ accordingly. Figures 6, 7 & 8 illustrate this. Figure 6. Figure 7.

Figure 6.

party Identity and Addressing’ accordingly. Figures 6, 7 & 8 illustrate this. Figure 6. Figure 7.

Figure 7.

VPN client concentrator (no specified VPN client addresses required) Headquarters SA Name=SiteA IPSEC
VPN client concentrator
(no specified VPN client addresses required)
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Destination Network=192.168.2.0
Subnet Mask=255.255.255.0
Advanced Option(s)
$ Forward Packets to Remote VPN
WAN IP 216.215.77.73/30
WAN IP 216.215.77.65/30
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Destination Network=192.168.3.0
Subnet Mask=255.255.255.0
Site
A
Advanced Option(s) Enabled
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
$ Forward Packets to Remote VPN
SA Name=GroupVPN
Advanced Option(s) Enabled
$ Forward Packets to Remote VPN
192.168.2.2
Site A
192.168.3.2
WAN IP 216.215.77.57/29
SA Name=HQ
IPSEC Gtwy=0.0.0.0
Destination Network=10.1.1.0
Advanced Option(s)=None
HQ
LAN IP 10.1.1.1/24
Site B
SA Name=HQ
IPSEC Gtwy=0.0.0.0
Destination Network=10.1.1.0
Subnet Mask=255.255.255.0
Advanced Option(s)=None
10.1.1.2

Figure 8.

In the second example we are going to assign the VPN clients a VPN Access Address. Since now the clients address will be known beforehand there is no need to specify an IPSEC gateway of 0.0.0.0 at the Remote Sites. All that needs to be done at a remote site is to specify the VPN Access Address range (e.g. 192.168.255.0) reserved for VPN clients as one of the destination networks in the SA that connects it to HQ. Figures 9, 10 & 11 illustrate this.

networks in the SA that connects it to HQ. Figures 9, 10 & 11 illustrate this.

Figure 9.

networks in the SA that connects it to HQ. Figures 9, 10 & 11 illustrate this.

Figure 10.

VPN client concentrator

(Specified VPN client addresses required)

VPN client concentrator SA Name=SiteA IPSEC Gtwy=216.215.77.73 Destination Network=192.168.2.0 Subnet
VPN client concentrator
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Destination Network=192.168.2.0
Subnet Mask=255.255.255.0
Advanced Option(s)
$ Forward Packets to Remote VPN
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Destination Network=192.168.3.0
Subnet Mask=255.255.255.0
Advanced Option(s) Enabled
$ Forward Packets to Remote VPN
SA Name=GroupVPN
Advanced Option(s) Enabled
$ Forward Packets to Remote VPN
Site A
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network(s)
$ 10.1.1.0
$ 192.168.255.0 (VPN client network)
Advanced Option(s)=None
Site B
SA Name=HQ
IPSEC Gtwy=216.215.77.57
Destination Network(s)
$ 10.1.1.0
$ 192.168.255.0 (VPN client network)
Advanced Option(s)=None
WAN IP 216.215.77.73/30 WAN IP 216.215.77.65/30 Site A LAN IP 192.168.2.1/24 Site B LAN IP
WAN IP 216.215.77.73/30
WAN IP 216.215.77.65/30
Site
A
LAN IP 192.168.2.1/24
Site B
LAN IP 192.168.3.1/24
192.168.2.2
192.168.3.2
WAN IP 216.215.77.57/29
VPN client Concentrator
LAN IP 10.1.1.1/24
10.1.1.2

Figure 10.

In both of these examples the VPN client is able to access all resources at all sites via a connection (or multiple connections; defined at the client; required when there are different network ranges) to the single GroupVPN SA defined at the central site.

Disabling Split Tunneling at the VPN client As mentioned previously, there are some very good security-related reasons for disabling split tunneling and when dealing with software VPN clients connecting back to corporate, the reasons become even more compelling. As you know, even with a "personal firewall" the average user's laptop is far from secure. With a split tunnel, if an intruder can find just one vulnerability in a remote desktop, they can bypass your firewall and access your internal network with the same privileges that the real user has. This is even more critical when users access the tunnel from “always on” broadband connections such as DSL or cable modem (note: Using the VPN client to access corporate resources via an “always on” connection is NOT recommended. In these scenarios a home office firewall such as the TELE3 is the recommended solution).

As mentioned previously, by disabling split tunnels, you prevent any direct communication with the Internet (other than through the VPN tunnel), which goes a long way towards securing the environment. This can be accomplished by configuring the SonicWALL VPN client to ‘Secure All Connections’. Essentially in this configuration we are accomplishing the same thing as was discussed in the previous section explaining the usage of the ‘Route all Internet Traffic Through This SA’ feature using a VPN client–to- SonicWALL connection instead of a SonicWALL-to-SonicWALL connection.

Configuration Steps The first step is to configure two SonicWALL firewalls to eliminate Split Tunneling (see details in previous section entitled “Using the Route all Internet Traffic Through This SA feature”). Because of a bug in the built-in GroupVPN SA, you cannot use it to provide client access in this particular configuration; instead you must create an SA for VPN clients to establish connections on. To configure this SA follow the steps outlined below (note: for purposes of clarity, we will use specific addresses in the example. This will allow you to follow the steps below precisely and achieve a working configuration. In actual deployment you may substitute addresses as needed).

1. Create a new IKE SA at the firewall. Name this SA ‘VPNClients’. Set the IPSEC Gateway to 0.0.0.0. Create a destination network of 192.168.255.0 with a subnet mask of 255.255.255.0. Under the advanced setting check the ‘Use Aggressive mode’ option and set the default LAN gateway to either the SonicWALL functioning as the firewall/Internet Gateway (as detailed in the previous section entitled “Using the Route all Internet Traffic Through This SA feature”) or another router with access to the Internet.

2.

Open the Security Policy Editor. If you have already imported the GroupVPN client policy you should see something like this:

GroupVPN client policy you should see something like this: If not go to the built-in GroupVPN

If not go to the built-in GroupVPN SA at the firewall and export a policy file. Import this file to the VPN client; this will give you a baseline policy to work with.

3. Select ‘Options # Secure # All Connections. The connection name will change to “All Connections’. Check the box that says ‘Connect using Secure Gateway Tunnel’. Under ‘ID Type’ Select ‘Domain Name’ from the dropdown list and then specify the ‘Unique Firewall Identifier’ of the firewall you will establish a tunnel to. Under ‘IP address enter the firewalls WAN IP address. The screen should look something like this:

WAN IP address. The screen should look something like this: 4. Select ‘Options # Global Policy

4. Select ‘Options # Global Policy Setting # and check the box that says ‘Allow Clients to Specify Network Address’ and then click OK.

5. Click the + to open the “All Connections’. Click ‘Security Policy’ then select the ‘Aggressive Mode’ option under the ‘Select Phase 1 Negotiation Mode’ section. The screen should look like this:

6. Click ‘My Identity’ then enter 192.168.255.1 in the ‘Internal Network IP Address’ field. Under

6. Click ‘My Identity’ then enter 192.168.255.1 in the ‘Internal Network IP Address’ field. Under the ‘ID Type’ dropdown list select ‘Domain Name’. In the field that opens up below enter ‘VPNCLients’ (note: this name must match the name of the SA exactly). Click the ‘Pre-Shared Key’ button and enter in the pre-shared secret you specified in the SA. The screen should look like this:

you specified in the SA. The screen should look like this: 7. Click the + to

7. Click the + to open ‘Security Policy # Authentication (Phase 1) # Proposal 1’. Make sure all the parameters on this screen match the corresponding parameters in the VPNClients SA you created (note: in this example we are using all the default encryption parameters of SonicWALL SA’s). The screen should look like this:

8. Click + to open ‘Key Exchange # Proposal 1’. Make sure all the parameters

8. Click + to open ‘Key Exchange # Proposal 1’. Make sure all the parameters on this screen match the corresponding parameters in the ‘VPNClients’ SA as well. The screen should look like this:

SA as well. The screen should look like this: 9. Click ‘File # Save Changes’. Activate

9. Click ‘File # Save Changes’. Activate the client by right-clicking on the SN icon in the system tray and selecting ‘Activate Security Policy’ (if the option says deactivate security policy then the policy is already active). The client is now configured to route all traffic through the VPN tunnel. If you have configured the firewalls correctly (as detailed in the previous section “Using the Route all Internet Traffic Through This SA feature”), you will be able to access the Internet but all traffic will be traversing the VPN tunnel.

How can I use this feature? Increase security – When clients are accessing corporate resources you have control over where they go on the Internet. This provides you with an audit trail and can help protect classified documents from “escaping out the back door”.

Centralized Content Filtering – If you are using a high-end content filtering solution such as Websense, N2H2 or SurfControl you can maintain an audit trail and centrally control where users go on the Internet.

SonicWALL A/V Deployment – If you are using the A/V solution and have remote users that rarely come into the office, you can use this configuration to deploy the A/V client. When a user attempts to access the Internet the SonicWALL will detect that the A/V client needs to be installed and will redirect the user to the installation page just as if they were a local user behind the SonicWALL’s LAN interface.

Extending SonicWALL Functionality with 3 rd Party Products

Authenticating VPN client users with RADIUS

A consideration when multiple VPN client users establish VPN tunnels through the built-in GroupVPN SA is

that if it ever becomes necessary to deny access to a single user, the pre-shared secret must be changed at the SA. This would require that the pre-shared secret be updated on the entire deployed VPN client base as well. Obviously this doesn’t scale but fortunately a viable solution exists. Requiring VPN client users to authenticate first before allowing them to establish the tunnel solves this issue. More than likely you’ve already set up a database of user names and passwords on your network that handles network authentication. This same database can be used for VPN authentication as well. This database could be any of the following:

Windows NT Domains/Hosts

NetWare NDS/Bindery

Solaris NIS or etc/passwd

SQL databases from Informix, Sybase, Oracle, and Microsoft

Token systems such as Security Dynamics ACE/Server

If a single user must be denied access to VPN resources, that users privileges are simply revoked at the

centralized user database. In this example we will use Windows Domains.

Funk Software produces a RADIUS server that runs on Windows NT/2000, Solaris and Netware. For more information or to download a free 30-day evaluation, visit Funk Software’s website at www.funk.com. For this example we will use the Windows NT/2000 version. To configure Funk Software’s ‘Steel Belted RADIUS’ to authenticate SonicWALL VPN client users follow the steps outlined below.

1. If you have not done so already download and install an evaluation copy of Funk Software’s Steel Belted RADIUS Enterprise Edition. Log on to the domain controller as administrator Open the Windows MMC with the Active Directory User and Computer Snap-in. Create a group called ‘RADIUS Users’. Create a test user and them to this group. (Note: If you install Steel Belted RADIUS on a Windows 2000 domain controller you must be sure that the particular user or group that you will use to authenticate RADIUS users has ‘Logon Locally’ rights. By default only certain privileged groups have this right on a Windows 2000 domain controller, the Domain Users group is not included in these). If you installed Steel Belted RADIUS on a domain controller go to step 2, otherwise proceed to step 3.

2. Open the MMC with the Group Policy/Default Domain Controllers Policy Snap-in. Browse to Computer Configuration # User Rights Assignment # Log on Locally. Double-click the Log on Locally policy setting and add the newly created ‘RADIUS Users’ group to it. The screen should look like this.

policy setting and add the newly created ‘RADIUS Users’ group to it. The screen should look

3.

Open the Steel Belted Radius administrator program and click ‘Connect’. The screen should look like this.

and click ‘Connect’. The screen should look like this. 4. Select the ‘RAS Clients’ button and

4. Select the ‘RAS Clients’ button and then click ‘Add’ then the ‘Any RAS client’ checkbox then click OK. Click ‘Edit Authentication Shared Secret’ then enter 123456789 then click ‘Set’. Click the ‘Save’ button at the bottom right. The screen should look like this.

at the bottom right. The screen should look like this. 5. Next click the ‘Users’ button

5. Next click the ‘Users’ button on the left. Click ‘Add’ then select the ‘Domain’ tab on the dialog that pops up. Browse to the ‘RADIUS Users’ group in the domain select it then click ‘OK’. The screen should look like this.

the ‘RADIUS Users’ group in the domain select it then click ‘OK’. The screen should look

6.

Next open the management interface of the firewall and select ‘VPN’ then select the ‘RADIUS’ tab. Under the ‘Primary Server’ section enter the IP address of your RADIUS server (the Windows 2000 server Steel Belted RADIUS is installed on). Enter a port number of 1645. Enter a shared secret of 123456789. Scroll down to the ‘RADIUS Client Test’ section. Enter a user that belongs to the ‘RADIUS Users’ group you created. Enter that users password and click ‘Update’. If everything is working correctly the firewall will return a status message indicating the authentication succeeded. The screen should look like this.

authentication succeeded. The screen should look like this. 7. The next step is to enable the

7. The next step is to enable the GroupVPN SA to require RADIUS authentication. Select the GroupVPN SA and open the ‘Advanced Settings’ dialog. Check the ‘Require XAUTH/RADIUS’ option then click ‘OK’ and then ‘Update’ to save your settings.

8. The final step is to generate a GroupVPN configuration file for the clients. From the GroupVPN SA click the export button and save the file locally. Open this file with the SonicWALL VPN client ‘Security Policy Editor’. Browse to ‘My Identity’ and click the ‘Pre- Shared Secret’ button. Enter in the exact same pre-shared secret that is in the GroupVPN SA. Next click ‘Save’ then click ‘File # Export Security Policy’. The dialog will ask you if you would like to lock the policy, if you are distributing to end users this is generally a good idea.

Tip: When you save the file save it with a .reg extension. This makes for easy distribution and installation. Simply email the policy file to your end users and have them double- click it to enter the information into the registry. This will automatically configure their VPN client).

You can now test the installation by attempting to establish a connection to the firewall. Make sure the policy is active (right-click the S/N icon in the systems tray and there should be an option to ‘Deactivate security policy’. If there is an option to ‘Activate security policy’ your policy is not currently active. Choose this option to activate it). Ping the LAN IP address of the SonicWALL you are connecting to. A dialog box should pop up requesting your user name and password. Enter the username and password of one of the users you created that belongs to the ‘RADIUS Users’ group. The user should authenticate and the tunnel should come up. A Ping to the SonicWALL’s LAN IP address should return a successful reply. All that has to be done to grant or deny a user VPN access is to simply add or remove them from the ‘RADIUS Users’ group.

Centralized, Policy-based Internet Access & Content Filtering SonicWALL currently offers content filtering in the form of a subscription-based list. This list referred to as the CyberNOT list, is organized into 12 categories and consists of approximately 65,000 web sites. When the service is activated, the firewall downloads the list into its memory. Once the list is downloaded, the firewall can be configured to block all or any combination of these 12 categories. Subsequent attempts to access a restricted site are blocked and logged by the firewall. By default, the filtering applies to all users of the firewall however privileged users can be created that have rights to completely bypass the filtering.

While this functionality is more than adequate for many customers, in some organizations it may be desirable to implement a more granular level of content filtering. This type of functionality would enable policy-based content filtering based upon a users identity or group membership. One product that provides this functionality is called SuperScout. Superscout is produced by SurfControl; the same company who produces the CyberNOT list used by SonicWALL content filtering.

This product is a fairly high-end Content Filtering solution that integrates with Windows 2000 and features customizable filtering (i.e. per group, per user, etc.), extremely granular web content classification (40 categories and 130 subtopics), advanced reporting options (Internet usage summaries, trends, individual user online activity, etc.), Bandwidth control (allows you to control streaming audio, video, images by file extension), Real-Time Monitoring and Automated Scheduling (updates to the URL category list, distribution of reports, etc). For more information or to download a free 30-day evaluation, visit SurfControl’s website at www.surfcontrol.com.

When implemented in conjunction with a SonicWALL firewall/VPN solution, a company can architect a highly customizable, scalable security and access control solution for their entire user base. The following example shows a typical implementation of SuperScout in a central location for company-wide content filtering. Filtering can also be extended to remote VPN client users by configuring them to disable split tunneling thereby forcing all traffic through the VPN tunnel (refer to section ‘Disabling Split Tunneling at the VPN client). Figure 11 shows the typical placement of the SurfControl SuperScout agent.

Typical Placement of Superscout Server Router SonicWALL Hub Switch SuperScout Computer Computer
Typical Placement of Superscout Server
Router
SonicWALL
Hub
Switch
SuperScout
Computer
Computer

Glossary Of Security Association Parameters

IPSEC Keying Mode – Determines what method the SonicWALL will use to obtain the encryption and authentication keys used to encrypt data transmitted through the VPN tunnel. Three methods are available: Manual Keys, IKE using pre-shared secret and IKE using certificates. AS the name implies if Manual Keys are selected, the administrator defines the keys. If any of the IKE methods is selected, the Internet Key Exchange (IKE) protocol is used to dynamically agree upon a set of keys between the two SonicWALL devices that will be exchanging encrypted IPSEC traffic.

Name – Between 1 and 32 characters (alphanumeric). A unique value that identifies the Security Association (SA). 1 When one of the SonicWALL’s has a dynamically assigned WAN IP address, the name of the SA on the dynamic side must match the ‘Unique Firewall Identifier’ of the Static side and visa versa (IKE only).

IPSEC Gateway – The WAN IP Address of the remote SonicWALL or other IPSEC VPN gateway. If the remote SonicWALL has a dynamic WAN IP address, the IPSEC gateway address should be set to 0.0.0.0 on the side with the static IP address. In this scenario, the dynamic side must always initiate the tunnel.

Security Parameters Index (Manual Key Only) – Between 3 to 8 characters (HEX). The Security Parameters Index (SPI) allows the firewall to uniquely identify all SA’s. When incoming IPSEC packets are seen the firewall looks at the SPI field in the IPSEC packet to determine which SA it should use to decrypt the incoming traffic. When setting up a manual key VPN tunnel between two firewalls, the outgoing SPI must match the incoming SPI and the incoming SPI must match the outgoing SPI of the other firewall. For obvious reasons all Incoming SPI’s must be unique on a firewall.

Think of the outgoing SPI as a way for the firewall to identify itself. Therefore a good rule of thumb is to develop your own internal identification scheme. Give each firewall a unique identifier (it could be something based on location, department, etc, etc…) and then use that for all the outbound SPI’s. Then when that firewall establishes a VPN tunnel to a remote firewall, at the remote firewall you will be able to identify which firewall it was by simply looking at the log. An entry will be created indicating that a VPN tunnel was established and what the incoming SPI was.

Phase 1 DH Group (IKE Only) - Diffie-Hellman (DH) Key Exchange (a key agreement protocol) is used during phase 1 of the authentication process to establish shared keys. There are three choices: Group 1, 2 and 5. These Groups use Modular-Exponentiation with different prime lengths. Group 1 uses 768-bits, Group 2 uses 1024-bits and Group 5 uses 1536-bits therefore Group 5 provides the highest level of security and Group 1 provides the highest throughput. The default for this setting is Group 1.

SA Life time (IKE Only) – The SA lifetime specifies the number of seconds that a VPN tunnel will stay active before new encryption and authentication keys will be exchanged. The SA Life Time may range from 120 to 2,500,000 seconds. (Note: A short SA Life Time increases security by forcing the two VPN gateways to update the encryption and authentication keys. However, every time the VPN tunnel

1 During an IKE negotiation the side that initiates the communication is known as the Initiator. The other side is known as the Responder. One of the first steps that occur during an IKE negotiation is authentication of the Initiator in order to ensure its identity. When the WAN IP address of both sides is known beforehand (static) the IKE negotiation occurs in what is referred to as Main Mode. In Main Mode the Initiator sends his WAN IP address to identify itself to the responder. Since this information is static the Responder knows beforehand what it should be and can verify that the Initiator is indeed who it should be. When the initiator has a dynamically assigned WAN IP address, the IKE negotiation occurs in what is referred to as Aggressive Mode (Note: Specifying either NAT w/ DHCP client or NAT w/ PPPoE client as the SonicWALL’s Network Addressing Mode causes the firewall to automatically switch to Aggressive Mode IKE negotiations). Since in this scenario the Responder has know way of knowing beforehand what the WAN address of the Initiator will be, the Initiator must use another method to properly identify itself to the Responder. SonicWALL uses both the Security Association (SA) name and the Unique Firewall Identifier to accomplish this. Page 17 of 21

renegotiates, all users accessing remote resources are temporarily disconnected. Therefore, the default SA Life Time of 28,800 seconds is recommended).

Phase 1 Encryption/Authentication (IKE Only)- This field defines the type of encryption and

authentication methods used to secure Phase 1 exchange using Internet Key Exchange (IKE). There are four methods that can be selected from the menu (listed in order from least secure to most secure):

DES & MD5

DES & SHA1

3DES & MD5

3DES & SHA1

Data Encryption Standard (DES) is a U.S. government standard for encrypting information. It is a symmetric encryption scheme that requires the sender and the receiver to know the secret key in order to communicate securely. DES is based on a 56-bit key that allows for 7.2 x 10 16 possible keys. This makes DES fairly secure, but when it was cracked in 1997, a more secure variant was developed called 3DES. Triple DES encrypts each message using three different 56-bit keys in succession. MD5 (Message Digest) is derived from a group of hashing algorithms used in cryptography. Message Digest refers to a hash value of fixed length that is computed from a longer variable message that is hashed by the algorithm. MD5 produces a 128-bit hash value. MD’s are commonly used to generate a digital signature from a message. MD5 uses four rounds of hashing and is fairly difficult to crack. SHA1 (Secure Hashing Algorithm) is a hashing algorithm developed by National Institute of Standards and Technology (NIST). If network speed is preferred, select DES & MD5. If network security is preferred, then select 3DES & SHA1.

Encryption Method (Named Phase 2 Encryption/Authentication when using IKE) – The parameters that the SonicWALL will use to encrypt data that will be transmitted through the VPN tunnel. For example one of the choices is: Strong Encrypt and Authenticate (ESP 3DES HMAC MD5). This choice causes the firewall to use 168 bit 3DES as the encryption method and HMAC MD5 Authentication method.

Pre-shared secret (IKE Only) - Between 4 to 128 characters (alphanumeric). The pre-shared shared secret is a predefined value that the two endpoints of a VPN tunnel use to set up the Phase 1 portion of an IKE negotiation.

Encryption Key (Manual Key Only) – A hexadecimal value used to encrypt the data being transmitted through the VPN tunnel. When using either DES or ARCFour as the encryption method, the Encryption Key must be exactly 16 characters long. When using Triple DES, the encryption key must be exactly 48 characters long.

Authentication Key (Manual Key Only) – A hexadecimal value used when the encryption method selected includes authentication. If MD5 is used the Authentication key must be exactly 32 characters long. If SHA1 is used the Authentication Key must be exactly 40 characters long.

Destination Networks – The destination network is a part of the SA that is defined on a firewall. The destination network tells the firewall when to encrypt packets and send them through the VPN tunnel. When the firewall “sees” packets that match a destination network defined in any of it’s SA’s, it encrypts these packets according to the rules of the SA and sends them to the IPSEC gateway specified in the SA.

In a manual key VPN you specify the actual range of addresses (e.g. 192.168.1.1 to 192.168.1.254) when you define the destination network. In an IKE w/ pres-shared secret VPN you specify a network (e.g. 192.168.1.0) and control how many hosts by manipulating the subnet mask. You cannot specify the same destination network more than once on a firewall.

Unique Firewall Identifier - Between 4 and 32 characters (alphanumeric). The Unique Firewall Identifier field is used to identify SonicWALL when its IP address is dynamically assigned. When one of the SonicWALL’s has a dynamically assigned WAN IP address, the name of the SA on the dynamic side must match the ‘Unique Firewall Identifier’ of the Static side and visa versa (IKE only).

Glossary of Advanced VPN Settings

Use Aggressive Mode - Selecting the Use Aggressive Mode check box forces the SonicWALL appliance to use Aggressive Mode to establish the VPN tunnel even if the SonicWALL has a static IP address. Aggressive Mode requires half of the main mode messages to be exchanged in Phase One of the SA exchange. Use Aggressive Mode is useful when the SonicWALL is located behind another NAT device. The check box is only available if IKE using Pre-shared Secret or IKE using certificates (SonicWALL to SonicWALL) is selected as the IPSec Keying Mode.

Enable Keep Alive - Selecting the Enable Keep Alive checkbox allows the VPN tunnel to remain active or maintain its current connection by listening for traffic on the network segment between the two connections. Interruption of the signal forces the tunnel to renegotiate the connection.

Require XAUTH/RADIUS (only allows VPN Clients) - An IKE Security Association may be configured to require RADIUS authentication before allowing VPN clients to access LAN resources. XAUTH/RADIUS authentication provides an additional layer of VPN security while simplifying and centralizing management. RADIUS authentication allows many VPN clients to share the same VPN configuration, but requires each client to authenticate with a unique user name and password. And because a RADIUS server controls network access, all employee privileges may be created and modified from one location.

Enable Windows Networking (NetBIOS) broadcast - Computers running Microsoft Windows communicate with one another through NetBIOS broadcast packets. Select the Enable Windows Networking (NetBIOS) broadcast checkbox to access remote network resources by browsing the Windows Network Neighborhood.

Apply NAT and firewall rules - This feature allows the remote site’s LAN subnet to be hidden from the corporate site, and is most useful when a remote office’ s network traffic is initiated to the corporate office. The IPSec tunnel is located between the SonicWALL WAN interface and the LAN segment of the corporation. To protect the traffic, NAT (Network Address Translation) is performed on the outbound packet before it is sent through the tunnel, and in turn, NAT is performed on inbound packets when they are received. By using NAT for a VPN connection, computers on the remote LAN are viewed as one address (the SonicWALL public address) from the corporate LAN. If the SonicWALL uses the Standard network configuration, using this checkbox applies the firewall access rules and checks for attacks. It does not apply NAT, as the SonicWALL is not configured for it. If the SonicWALL uses NAT network configuration, then using this checkbox performs normal firewall checks, access rules, and applies NAT (Note: You cannot use this feature if you have Route all internet traffic through this SA enabled).

Forward Packets to Remote VPNs - Checking the Forward Packets to Remote VPNs checkbox for a Security Association allows the remote VPN tunnel to participate in the SonicWALL routing table. Inbound traffic is decrypted and can now be forwarded to a remote site via another VPN tunnel. Normally, inbound traffic is decrypted and only forwarded to the SonicWALL local LAN or a specific route on the LAN specified on the Routes tab located under the Advanced section. Enabling this feature allows a network administrator to create a “hub and spoke” network configuration by forwarding inbound traffic to a remote site via a VPN security association. To create a “hub and spoke” network, enable the Forward Packets to Remote VPNs checkbox for each Security Association in your SonicWALL. Traffic is now able to go from branch office to branch office via the corporate office.

Route all internet traffic through this SA - Checking this box allows a network administrator to force all network traffic to the WAN to go through a VPN tunnel to a central site. Outgoing packets are checked against the remote network definitions for all Security Associations (SA). If a match is detected, the packet is then routed to the appropriate destination. If no match is detected, the SonicWALL checks for the presence of a SA using this checkbox. If an SA is detected, the packet is sent using that SA. If there is no SA with this option enabled, and if the destination does not match any other SA, the packet goes unencrypted to the WAN. Note: Only one SA may have this checkbox enabled.

Enable Perfect Forward Secrecy - The Enable Perfect Forward Secrecy checkbox increases the renegotiation time of the VPN tunnel. By enabling Perfect Forward Secrecy, a hacker using brute force to break encryption keys is not able to obtain other or future IPSec keys. During the phase 2 renegotiation

between two SonicWALL appliances or a Group VPN SA, an additional Diffie-Hellman key exchange is performed. Enable Perfect Forward Secrecy adds incremental security between gateways.

Phase 2 DH Group - Diffie-Hellmen (DH) Key Exchange (a key agreement protocol) is used during phase 2 of the authentication process if Enable Perfect Forward Secrecy is selected. You can now select from three well-known DH groups:

Group 1 (768-bit) - least secure

Group 2 (1024-bit) - more secure

Group 5 (1536-bit) - most secure

Default LAN Gateway - A Default LAN Gateway is used at a central site in conjunction with a remote site using the Route all Internet traffic through this SA checkbox. The Default LAN Gateway field allows the network administrator to specify the IP address of the default LAN route for incoming IPSec packets for this SA. Incoming packets are decoded by the SonicWALL and compared to static routes configured in the SonicWALL. Since packets may have any IP address destination, it is impossible to configure enough static routes to handle the traffic. For packets received via an IPSec tunnel, the SonicWALL looks up a route for the LAN. If no route is found, the SonicWALL checks for a Default LAN Gateway. If a Default LAN Gateway is detected, the packet is routed through the gateway. Otherwise, the packet is dropped.

Overview of the IKE Protocol

The IKE protocol can be thought of as a combination of two protocols, the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley. ISAKMP provides a framework for establishing security associations and cryptographic keys, but does not prescribe any particular authentication mechanism. ISAKMP was designed to integrate with a number of security protocols. Oakley is a suite of key agreement protocols in which two parties generate a key jointly.

The IKE RFC describes how Oakley can be used to provide an instantiation of ISAKMP. A typical key establishment protocol proceeds in one phase, in which two parties use master keys to establish shared keying material. IKE, however, proceeds in two such phases. In the 1st phase, two entities use master keys to agree, not only on keying material, but also on the various mechanisms (e.g. cryptographic algorithms, hash functions, etc.), that they will use in the second phase. The keying material and set of mechanisms thus agreed upon is called a Security Association (SA). In the second phase, the keys and mechanisms produced in the 1st phase are used to agree upon new keys and mechanisms (that is, new Security Associations) that will be used to protect and authenticate further communications.

The security association established in Phase 1 is bi-directional, so the initiator in the 1st phase can be either initiator or responder in the second phase. Oakley may be used in one of four different modes:

‘Main’, ‘Aggressive’, ‘Quick’ and ‘New Group’. These offer different types of services. Both ‘Main’ and ‘Aggressive’ mode can be used in Phase 1. In ‘Main’ mode, certain types of identifying information will not be exchanged until some initial authentication has occurred. In ‘Aggressive’ mode, this level of protection is not provided, but the exchange is accomplished in fewer messages.

‘Main’ and ‘Aggressive’ mode can be implemented in four different ways: using shared keys, signatures, or public keys in two different ways for authentication. In all of these, the Diffie-Hellman protocol is used to generate the keying material. ‘Quick’ mode is used as part of the Phase 2 negotiation process. In ‘Quick’ mode, the key material generated in Phase 1 is used to encrypt and authenticate messages used to generate the key material produced for Phase 2. ‘Quick’ mode offers Diffie-Hellman key exchange as an option that can be used to provide perfect forward secrecy; the other option is to use more conventional shared key generation mechanisms, which, while they are faster, do not provide the same degree of security.

In IKE, identity information is only required in ‘Quick’ mode messages when ISAKMP is acting as a client negotiator on behalf of another party (for example, hosts negotiating security associations for applications or users); otherwise identities may be assumed to be the IP addresses of the ISAKMP peers. Finally, ‘New Group’ mode is used to agree on a new Diffie-Hellman group.

As we can see, IKE is really a combination of a number of different sub-protocols. Phase 1 offers a choice of eight different sub-protocols, with two choices for mode, and four choices for authentication mechanism. Phase 2 offers a choice of four different sub-protocols, depending upon whether perfect forward secrecy is or is not provided, and depending upon whether or not explicit identity information is included. Thus, all in all, when the ‘New Group’ protocol is included, thirteen different sub-protocols are offered.