Feature/Application:

This article will detail all the steps necessary to create a working IKE IPSec VPN tunnel between a SonicWALL security appliance running SonicOS Standard and a SonicWALL security appliance running SonicOS Enhanced.

Scenario

Please note that all settings and screenshots contained within this article are taken from a SonicWALL TZ 170 running SonicOS Standard 3.1.6.3-4s acting as the remote site, and a SonicWALL NSA 240 running SonicOS Enhanced 5.6 acting as the central site.

Caveats:

• Please take special care to correctly set the VPN proposal settings on the SonicWALL security appliances. If the settings do not match on the SonicWALLs, the security appliances will not be able to negotiate a tunnel from either side. For instance, when creating the address object for the destination network in SonicOS Enhanced, the Zone must be VPN.

• Some Microsoft networking environments rely heavily on broadcasts to advertise and locate network resources (servers, print devices, etc). By default, SonicWALL devices are configured to not pass these Microsoft NetBIOS broadcasts across VPN tunnels. In this technote, we will detail how to configure SonicOS to pass these broadcasts across the VPN tunnel bidirectionally in the ‘Optional Steps’ section of this technote. Please note this may increase traffic in some environments.

Configure SonicOS Standard VPN settings (remote site):

• Log into the SonicWALL Management interface of the remote site Sonicwall.
• Navigate to the VPN > Settings page.
• Click on the Add button under the VPN Policies section.
• Create a VPN policy with details as per the following screenshots.
• When done click on the OK button to save the settings.

Configure SonicOS Enhanced VPN settings (central site)

• Log into the SonicWALL Management interface of the central site Sonicwall.
• Navigate to the Network > Address Objects page.
• Create a new Address Object named “Remote Site LAN” with details as per the screenshot:

• Navigate to the VPN > Settings page.
• Create a VPN policy with details as per the following screenshots.
• Click OK to save.

From a system behind the remote site SonicWALL, attempt to connect to a network resource behind the central site, or ping the central site SonicWALL’s LAN interface IP address.

Once you’ve done this, log into the remote site SonicWALL’s management GUI and check the ‘VPN > Settings’ page. You should see the active VPN tunnel listed (see screenshots below). On the remote site, you should see that the tunnel has negotiated with the Primary IPSec gateway.

Tunnel up at the Enhanced (central) Site:

Tunnel up at the Standard (remote) Site:

If the tunnel does not negotiate successfully, check the SonicWALL’s log on the ‘Log > View’ page to see if there are any error messages for VPN negotiation. If the tunnel is not negotiating and there are error messages displayed, go over the settings on both side to make sure that they match and attempt to bring the tunnel up again.

You should see the active VPN tunnel listed (see screenshots above). On the remote site, you should see that the tunnel has negotiated with the Primary IPSec gateway. If the tunnel does not negotiate successfully, check the SonicWALL’s log on the ‘Log > View’ page to see if there are any error messages for VPN negotiation.

If the tunnel is not negotiating and there are error messages displayed, go over the settings on both side to make sure that they match and attempt to bring the tunnel up again.

The Global VPN Settings section of the VPN > Settings page displays the Unique Firewall Identifier – the default value is the serial number of the SonicWALL and used for configuring Aggressive Mode VPN tunnels. You can replace this with your choice of name, “chicago / new york” for example.
Procedure: 

Network Setup:

Configuring a Site to Site VPN on the Central Location (Static WAN IP address)

Device used on Central Site: SonicWALL PRO 4060 appliance with SonicOS Enhanced 4.0.0.2e firmware.

Central Location Network Configuration:

1.       LAN Subnet: 192.168.168.0

2.       Subnet Mask: 255.255.255.0

3.       WAN IP: 66.249.72.115

4.       Unique Firewall Identifier: chicago

Step 1: Creating Address Object for Remote Site:

 - Login to the Central Location SonicWALL appliance
 - Navigate to Network > Address Objects page.
 - Scroll down to the bottom of the page and click on Add button, enter the following settings.

Name – newyork vpn,

Zone – VPN,

Type – Network,

Network – 10.10.10.0,

Netmask – 255.255.255.0
 -  Click OK when finished.

Step 2: Configurating a VPN Policy:

a.       Click on VPN > Settings

b.       Check the box “Enable VPN” under Global VPN Settings, ensure that the correct Firewall Identifier has been specified

c.       Click on the “Add” button under VPN Policies section. The VPN Policy window pops up.

Click the General tab

a.       Select the Authentication method as “IKE Using Preshared Secret”

b.       Name: New York Aggressive Mode VPN

c.       IPsec Primary Gateway Name or Address: 0.0.0.0

Note:  Since the WAN IP address changes frequently, it is recommended to use the 0.0.0.0 IP address as the Primary Gateway.

d.       IPsec Secondary Gateway Name or Address: 0.0.0.0

e.       Shared Secret: sonicwall (The Shared Secret would be the same at both SonicWALL’s)

f.         Local IKE ID: SonicWALL Identifier – chicago

g.       Peer IKE ID: SonicWALL Identifier – newyork

 Click the Network tab

Ø       Local Networks

Select Choose local network from list, and select the Address Object – X0 Subnet (Lan subnet)

Ø       Destination Networks

Select Choose destination network from list, and select the Address Object – newyork vpn

Click the Proposals tab

IKE (Phase 1) Proposal

Exchange:  Aggressive Mode

DH Group:  Group 2

Encryption: 3DES  

Authentication: SHA1

Life Time (seconds): 28800  

Ipsec (Phase 2) Proposal

Protocol:  ESP

Encryption: 3DES 

Authentication: SHA1

Enable Perfect Forward Secrecy(not checked)

DH Group:  Group 2

Life Time (seconds): 28800

Click the Advanced tab

Ensure that the VPN Policy bound to: Zone WAN

  - Click OK when finished

Configuring a Site to Site VPN on the Remote Location (Dynamic WAN IP address)

Device used on Remote location: SonicWALL TZ 170 appliance with SonicOS Enhanced 3.2.3.0 firmware

Network Configuration:

1.       LAN Subnet: 10.10.10.0

2.       Subnet Mask: 255.255.255.0

3.       WAN IP: DHCP (As this is a Dynamic IP Address)

4.       Unique Firewall Identifier: newyork

�
Step 1: Creating Address Object for Remote Site:

 - Login to the Central Location SonicWALL appliance
 - Navigate to Network > Address Objects page.
 - Scroll down to the bottom of the page and click on Add button, enter the following settings.

Name – chicago vpn

Zone – VPN

Type – Network

Network – 192.168.168.0

Netmask – 255.255.255.0

 - Click OK when finished

Configuring a Site to Site VPN on the Remote Location (Dynamic WAN IP address)

Device used on Remote location: SonicWALL TZ 170 appliance with SonicOS Enhanced 3.2.3.0 firmware

Network Configuration:

1.       LAN Subnet: 10.10.10.0

2.       Subnet Mask: 255.255.255.0

3.       WAN IP: DHCP (As this is a Dynamic IP Address)

4.       Unique Firewall Identifier: newyork

�
Step 1: Creating Address Object for Remote Site:

 - Login to the Central Location SonicWALL appliance
 - Navigate to Network > Address Objects page.
 - Scroll down to the bottom of the page and click on Add button, enter the following settings.

Name – chicago vpn

Zone – VPN

Type – Network

Network – 192.168.168.0

Netmask – 255.255.255.0

 - Click OK when finished

Step 2: Configuration VPN Policy:

a.       Click on VPN > Settings

b.       Check the box “Enable VPN” under Global VPN Settings, ensure that the correct Firewall Identifier has been specified

c.         Click on the “Add” button under the VPN Policies section. The VPN Policy window pops up.

Click the General tab

a.      Select the Authentication method as “IKE Using Preshared Secret”

b.      Name: Chicago Aggressive Mode VPN

c.      IPsec Primary Gateway Name or Address: 66.249.72.115

d.      IPsec Secondary Gateway Name or Address: 0.0.0.0

e.      Shared Secret: sonicwall

f.         Local IKE ID: SonicWALL Identifier – newyork

g.       Peer IKE ID: SonicWALL Identifier – chicago

Click the Network tab

Ø       Local Networks

Select Choose local network from list, and select the Address Object – LAN Primary Subnet

Ø       Destination Networks

Select Choose destination network from list, and select the Address Object – chicago vpn

Click the Proposals tab

IKE (Phase 1) Proposal

Exchange:  Aggressive Mode

DH Group:  Group 2

Encryption: 3DES 

Authentication: SHA1

Life Time (seconds): 28800  

Ipsec (Phase 2) Proposal

Protocol:  ESP

Encryption: 3DES 

Authentication: SHA1

Enable Perfect Forward Secrecy (not checked)

DH Group:  Group 2

Life Time (seconds): 28800

Click the Advanced tab

Enable Keep Alive box should be checked

VPN Policy bound to: Zone WAN

                  – Click OK when finished

How to Test:

From the Remote Location try to ping an IP address on the Central Location. 

Note: Before receiving successful replies, you might see couple of “Request Timed Out“ messages while the VPN tunnel is still establishing.

Manually opening Ports to allow Email traffic (SMTP, IMAP or POP3) from Internet to a server behind the SonicWALL in SonicOS Enhanced involves the following steps:

Step 1: Creating the necessary Address Objects
Step 2: Create a Service Group
Step 2: Defining the appropriate NAT Policies (Inbound, Outbound and Loopback)
Step 3: Creating the necessary WAN > Zone Access Rules for public access

Recommendation: The Public Server Wizard quickly configure your SonicWALL to provide public access to an internal server. The Public Server Wizard is the most ambitious and functional wizard developed to date. It simplifies the complex process of creating a publicly and internally accessible server resource by automating above mentioned steps. Please refer KBID 7027 and KBID 4178 for complete instructions.

Scenario:

The following example covers allowing Email traffic (SMTP, IMAP or POP3) service from the Internet to a server on the LAN with private IP address as 192.168.1.100.  Once the configuration is complete, Internet users can Send emails to the Email Server behind the SonicWALL UTM appliance through the WAN (Public) IP address 1.1.1.1.  

Please Note: If you want to Open ports for OWA (Outlook Web Access), which is accessible on HTTP or HTTPS port then refer KBID 7484.

Procedure:  

In this example we have chosen to demonstrate using SMTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Step 1: Creating the necessary Address Objects 

TIP: For complete information on creating Address Objects refer: KBID 7486

1. Select Network > Address Objects.
2. Click the Add a new address object button and create two address objects one for Server IP on LAN and another for Public IP of the server:  

Address Object for Server on LAN Name: MailServer Private� Zone Assignment: LAN � Type: Host  � IP Address: 192.168.1.100

Address Object for Server’s Public IP Name: MailServer Public Zone Assignment: WAN � Type: Host  � IP Address: 1.1.1.1

3. Click the OK button to complete creation of the new address objects.

Step 2: Create a Service Group

1. The Services page can be accessed either from Firewall > Services or Network > Services.�
2. Click Add Group.
3. Select individual services from the list in the left column. Click - > to add the services to the group.
4. To remove services from the group, select individual services from the list in right column. Click < – to remove the services.

5. When you are finished, click OK to add the group to Custom Services Groups.

Step 3: Defining the appropriate NAT Policies

1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and chose the following settings from the drop-down menu:

Understanding how to use NAT policies starts with the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requestor, and the destination’s IP address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.

Note: To Add custom port in SonicOS Enhanced refer KBID 7133

Adding appropriate NAT Policies Original Source: Any Translated Source: Original Original Destination: MailServer Public Translated Destination: MailServer Private Original Service: MailServer Services Translated Service: Original Inbound Interface: Any Outbound Interface: Any Comment: Webserver behind SonicWALL. Enable NAT Policy: Checked Create a reflexive policy: Checked

Note: Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.

3. Click the Add button.

Loopback Policy:

If you wish to access this server from other internal zones using the Public IP address 1.1.1.1 consider creating a Loopback NAT Policy else go to next step:

• Original Source: Firewalled Subnets 
• Translated Source: MailServer Public
• Original Destination: MailServer Public
• Translated Destination: MailServer Private
• Original Service: MailServer Services
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Comment: Loopback policy
• Enable NAT Policy: Checked
• Create a reflexive policy: unchecked

4.  Upon completion under Network > Nat Policies tab the above Inbound and Outbond NAT policies will be created. 

Step 3: Creating Firewall Access Rules

1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3. Click Add a new entry and create the rule by entering the following into the fields:

Caution: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.

Action: Allow  From Zone: WAN To Zone: LAN Service: MailServer Services� Source: Any� Destination: MailServer Public  Users Allowed: All Schedule: Always on Enable Logging: checked Allow Fragmented Packets: checked

5: Click OK.

How to Test:

• Testing from within the private network: Ensure that the Email Server is working from within the private network itself.

• Testing from the Internet: Go to www.mxtoolbox.com and enter your Email Server’s Public IP address in the Domain Name field i.e 1.1.1.1 

Troubleshooting:

• Ensure that the EmailServer’s Default Gateway IP address is SonicWALL’s LAN IP address.

• Ensure that the Email Server is able to access the Internet.

• Try to reduce the MTU value on your SonicWALL appliance. Refer KBID 3557: UTM: How to change the MTU size on the SonicWALL UTM appliance?

• Displaying Access Rule Traffic Statistics:

1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3. Move your mouse pointer over the Graph icon to display the following access rule receive (Rx) and transmit (Tx) traffic statistics: 

• Rx Bytes�
• Rx Packets�
• Tx Bytes�
• Tx Packets 

• Ensure you do not have duplicate NAT Policies and Firewall Access Rules for your Email Server.
• For further troubleshooting go to SonicWALL Logs under Log > View page and check for Alerts, Denied IP’s, Dropped messages, etc. 

Manually opening non-standard (custom) Ports from Internet to a server behind the SonicWALL in SonicOS Enhanced involves the following steps:

Step 1: Creating the necessary Address Objects
Step 2: Creating a Custom Service for non-standard port (custom port number)
Step 3: Defining the appropriate NAT Policies (Inbound, Outbound and Loopback)
Step 4: Creating the necessary WAN > Zone Access Rules for public access

Recommendation: The Public Server Wizard quickly configure your SonicWALL to provide public access to an internal server. The Public Server Wizard is the most ambitious and functional wizard developed to date. It simplifies the complex process of creating a publicly and internally accessible server resource by automating above mentioned steps. Please refer KBID 7027 and KBID 4178 for complete instructions.

Scenario:

The following example covers allowing non-standard port from the Internet to a server on the LAN with private IP address as 192.168.1.100.  Once the configuration is complete, Internet users can access the server behind the SonicWALL UTM appliance through the WAN (Public) IP address 1.1.1.1. 

Procedure:  

In this example we have chosen to demonstrate using CustomPort 4443, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Step 1: Creating the necessary Address Objects 

TIP: For complete information on creating Address Objects refer: KBID 7486

1. Select Network > Address Objects.
2. Click the Add a new address object button and create two address objects one for Server IP on LAN and another for Public IP of the server:  

Address Object for Server on LAN Name: MyServer Private� Zone Assignment: LAN � Type: Host  � IP Address: 192.168.1.100

Address Object for Server’s Public IP Name: MyServer Public Zone Assignment: WAN � Type: Host  � IP Address: 1.1.1.1

3. Click the OK button to complete creation of the new address objects.

Step 2: Creating a Custom Service for non-standard port (custom port number)

Please Note: For increased convenience and accessibility, the Services page can be accessed either from Firewall > Services or Network > Services. The page is identical regardless of which tab it is accessed through.

All custom services you create are listed in the Custom Services table. You can group custom services by creating a Custom Services Group for easy policy enforcement. If a protocol is not listed in the Default Services table, you can add it to the Custom Services table by clicking Add. 

1. Enter the name of the service in the Name field.
2. Select the type of IP protocol from the Protocol pull-down menu.

3. Enter the Port Range or IP protocol Sub Type depending on your IP protocol selection:

– For TCP and UDP protocols, specify the Port Range. You will not need to specify a Sub Type.�
– On SonicWALL NSA series appliances, for ICMP, IGMP, OSPF and PIMSM protocols, select from the Sub Type pull-down menu for sub types.�
– For the remaining protocols, you will not need to specify a Port Range or Sub Type.

4. Click OK. The service appears in the Custom Services table.

Step 3: Defining the appropriate NAT Policies

1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and chose the following settings from the drop-down menu:

Understanding how to use NAT policies starts with the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requestor, and the destination’s IP address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.

Adding appropriate NAT Policies Original Source: Any Translated Source: Original Original Destination: MyServer Public Translated Destination: MyServer Private Original Service: CustomPort 4443 Translated Service: Original Inbound Interface: Any Outbound Interface: Any Comment:� Enable NAT Policy: Checked Create a reflexive policy: Checked

Note: Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.

3. Click the Add button.

Loopback Policy:

If you wish to access this server from other internal zones using the Public IP address Http://1.1.1.1 consider creating a Loopback NAT Policy else go to next step:

• Original Source: Firewalled Subnets 
• Translated Source: MyServer Public
• Original Destination: MyServer Public
• Translated Destination: MyServer Private
• Original Service: CustomPort 4443
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Comment: Loopback policy
• Enable NAT Policy: Checked
• Create a reflexive policy: unchecked

4.  Upon completion under Network > Nat Policies tab the above Inbound and Outbond NAT policies will be created. 

Step 3: Creating Firewall Access Rules

1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3. Click Add a new entry and create the rule by entering the following into the fields:

Caution: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.

Action: Allow  From Zone: WAN To Zone: LAN Service: CustomPort 4443� Source: Any� Destination: MyServer Public  Users Allowed: All Schedule: Always on Enable Logging: checked Allow Fragmented Packets: checked

4. Under the Advanced tab, you can leave the “Inactivity Timeout in Minutes” at 15 minutes. Some protocols, such as Telnet, FTP, SSH, VNC and RDP can take advantage of longer timeouts where increased values like 30 or 60 minutes can be tried with caution in those cases. Longer timeout values will not help at all for HTTP or HTTPS.

5: Click OK.

How to Test:

• Testing from within the private network: Try to access the server through its private IP address (Http://192.168.1.100) to ensure it is working from within the private network itself.

• Testing from the Internet: Login to a remote computer on the Internet and try to access the server by entering the public IP (Http://1.1.1.1 with appropriate port number (e.g Port 4443).

In order to allow Internet users to access your Small Business Server located behind the SonicWALL, it will be necessary to create the required firewall access rules and if you are using SonicOS Enhanced firmware then NAT policies also has to be created to permit and translate the traffic.

What services and ports should I allow on the firewall?

Microsoft Small Business Server 2003 includes many services, for example:

- MS Exchange, inbound email requires inbound SMTP traffic on TCP port 25 and Outlook Web Access requires inbound HTTPS traffic on TCP port 443;
- MS SQL, inbound SQL access requires inbound SQL traffic on TCP port 1433.

if you are not sure of the services and port numbers, the following weblinks should be helpful:

• List of components that are included in Windows Small Business Server 2003 for information on the protocols and port numbers used by SBS and
• Microsoft Windows Small Business Server 2003 with Service Pack 1 Getting Started guide – APPENDIX C Network Configuration Settings for additional considerations when using SBS behind a firewall.

After verifying the particular services and port numbers in SBS. The SonicWALL should be configured to allow remote access to these services from the outside, appropriate NAT and Firewall Access Rules must be setup.

Procedure:

Configuring the SonicWALL appliance
SonicOS Standard:

If you want to allow access using the SonicWALL’s WAN IP address an Access Rule must be created or if you are using a separate Public IP address then you need to configure One-to-One NAT setup first, refer KBID 4464.

Creating an Allow access rule:

1. Login to the SonicWALL Management Interface
2.Click Firewall –> Access Rules. Click Add. Create the rule by entering the following into the fields: 

- Action: Allow
- Service: (SBS server Services that you want to share, for example SMTP.)
- Source Ethernet: * (Asterisks * represent all IP addresses on that interface. This example allows the traffic from any address, which is appropriate for servers you want visible from the Internet and the LAN.)
- Source Address Range Begin: *
- Source Address Range End: *
- Destination Ethernet: LAN or DMZ (Select appropriate Interface where the server resides)
- Destination Address Range Begin: For inbound rules, such as the one in this example, you will almost always need to specify a single LAN or DMZ IP address representing the server.
- Destination Address Range End: Leave this field blank. 

3. Enable the “Allow Fragmented Packets” box. 

4. Under the Advanced tab, you can leave the “Inactivity Timeout in Minutes” at 30 minutes. Some protocols, such as Telnet, FTP, SSH, VNC and RDP can take advantage of longer timeouts where increased values like 45 or 60 minutes can be tried with caution in those cases. Longer timeout values will not help at all for HTTP or HTTPS.

5. Click OK.

SonicOS Enhanced:

The following example is for allowing SMTP, POP3 and IMAP service for the 192.168.1.100 IP address on LAN. You would follow the same steps for other services (like HTTP, HTTPS, FTP, Terminal, SSH, etc.). 

Step 1: Creating Address Objects

1. Select Network > Address Objects.
2. Click the Add a new address object button and enter the following into the fields:

• Name: MailServer Private 
• Zone Assignment: LAN
• Type: Host
• IP Address: 192.168.1.5

3. Click the OK button to complete creation of the new address object.

4. Click the Add a new address object button again and create another address object for Public IP of the server: 

Step 2: Create a Service Group

1. The Services page can be accessed either from Firewall > Services or Network > Services.�
2. Click Add Group.
3. Select individual services from the list in the left column. Click - > to add the services to the group.
4. To remove services from the group, select individual services from the list in right column. Click < – to remove the services.

5. When you are finished, click OK to add the group to Custom Services Groups.

Step 3: Creating NAT Policies

1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and enter the following into the fields:

• Original Source: Any
• Translated Source: Original
• Original Destination: MailServer Public
• Translated Destination: MailServer Private
• Original Service: MailServer Services
• Translated Service: Original
• Inbound Interface: WAN
• Outbound Interface: Any
• Enable NAT Policy: Checked
• Create a reflexive policy: Checked 

3. Click the OK button to complete creation of the NAT policy.

Step 4: Creating Firewall Access Rules

1. Click Firewall –> Access Rules.
2. Select from WAN to LAN in the matrix.
3. Click Add a new entry and create the rule by entering the following into the fields:

• Action: Allow
• Service: MailServer Services
• Source: Any
• Destination: Mail server Public
• Allow Fragmented Packets: checked 

4. Under the Advanced tab, you can leave the “Inactivity Timeout in Minutes” at 30 minutes. Some protocols, such as Telnet, FTP, SSH, VNC and RDP can take advantage of longer timeouts where increased values like 45 or 60 minutes can be tried with caution in those cases. Longer timeout values will not help at all for HTTP or HTTPS.

5: Click OK.

Feature/Application:

Manually opening Ports to allow (Webserver, FTP, Email, Terminal Service, etc.) from Internet to a server behind the SonicWALL in SonicOS Enhanced involves the following steps:

Step 1: Creating the necessary Address Objects
Step 2: Defining the appropriate NAT Policies (Inbound, Outbound and Loopback)
Step 3: Creating the necessary WAN > Zone Access Rules for public access

Recommendation: The Public Server Wizard quickly configure your SonicWALL to provide public access to an internal server. The Public Server Wizard is the most ambitious and functional wizard developed to date. It simplifies the complex process of creating a publicly and internally accessible server resource by automating above mentioned steps. Please refer KBID 7027 and KBID 4178 for complete instructions.

Alert: The SonicWALL security appliance can be managed using HTTP (Port 80) or HTTPS (443) and a Web browser. Both HTTP and HTTPS are enabled by default. If you are using the SonicWALL WAN IP address for HTTP or HTTPS port forwarding to a server, then the default Management port must be changed to another unused port number (e.g. 8080, 444, 4443, etc.). You can change this under the System > Administration page.

Scenario:

The following example covers allowing HTTP (webserver) service from the Internet to a server on the LAN with private IP address as 192.168.1.100.  Once the configuration is complete, Internet users can access the HTTP (webserver) service behind the SonicWALL UTM appliance through the WAN (Public) IP address 1.1.1.1. 

Procedure:  

 In this example we have chosen to demonstrate using HTTP service, however the following steps apply to any service you wish to use (like HTTPS, SMTP, FTP, Terminal Services, SSH, etc).

Step 1: Creating the necessary Address Objects

TIP: For complete information on creating Address Objects refer: KBID 7486

1. Select Network > Address Objects.
2. Click the Add a new address object button and create two address objects one for Server IP on LAN and another for Public IP of the server:  

Address Object for Server on LAN Name: Mywebserver Private� Zone Assignment: LAN � Type: Host  � IP Address: 192.168.1.100

Address Object for Server’s Public IP Name: Mywebserver Public Zone Assignment: WAN � Type: Host  � IP Address: 1.1.1.1

3. Click the OK button to complete creation of the new address objects.

Step 2: Defining the appropriate NAT Policies

1. Select Network > NAT Policies.
2. Click the Add a new NAT Policy button and chose the following settings from the drop-down menu:

Understanding how to use NAT policies starts with the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester’s IP address, the protocol information of the requestor, and the destination’s IP address. The NAT Policies engine in SonicOS Enhanced can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.

Note: To Add custom port in SonicOS Enhanced refer KBID 7133

Adding appropriate NAT Policies Original Source: Any Translated Source: Original Original Destination: Mywebserver Public Translated Destination: Mywebserver Private Original Service: HTTP Translated Service: Original Inbound Interface: Any Outbound Interface: Any Comment: Webserver behind SonicWALL. Enable NAT Policy: Checked Create a reflexive policy: Checked

Note: Create a reflective policy: When you check this box, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy window is automatically created.

3. Click the Add button.

Loopback Policy:

If you wish to access this server from other internal zones using the Public IP address 1.1.1.1 consider creating a Loopback NAT Policy else go to next step:

• Original Source: Firewalled Subnets 
• Translated Source: Mywebserver Public
• Original Destination: Mywebserver Public
• Translated Destination: Mywebserver Private
• Original Service: HTTP
• Translated Service: Original
• Inbound Interface: Any
• Outbound Interface: Any
• Comment: Loopback policy
• Enable NAT Policy: Checked
• Create a reflexive policy: unchecked

4.  Upon completion under Network > Nat Policies tab the above Inbound and Outbond NAT policies will be created. 

Step 3: Creating Firewall Access Rules

1. Click Firewall > Access Rules tab.
2. Select the type of view in the View Style section and go to WAN to LAN access rules.
3. Click Add a new entry and create the rule by entering the following into the fields:

Caution: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.

Action: Allow  From Zone: WAN To Zone: LAN Service: HTTP� Source: Any� Destination: My webserver Public  Users Allowed: All Schedule: Always on Enable Logging: checked Allow Fragmented Packets: checked

4. Under the Advanced tab, you can leave the “Inactivity Timeout in Minutes” at 15 minutes. Some protocols, such as Telnet, FTP, SSH, VNC and RDP can take advantage of longer timeouts where increased values like 30 or 60 minutes can be tried with caution in those cases. Longer timeout values will not help at all for HTTP or HTTPS.

5: Click OK.

The maximum transmission unit, here on referred to as MTU, is the maximum amount of bytes that can be encapsulated in an IP packet. The MTU size includes the data payload, any transport headers (such as TCP, UDP, GRE, RTP, or ICMP), and the IP header.

It is generally recommended that the MTU for a WAN interface connected to a PPPoE DSL network be 1492. In fact, with auto MTU discovery, 1492 is discovered to be the maximum allowed MTU. However, having an MTU of 1452 is most optimal.

To change the MTU size on the SonicWALL UTM appliance? refer KBID 3557

The maximum MTU for Ethernet connections on SonicWALL devices is 1500 bytes (Ethernet maximum MTU size).  Having an MTU of 1500 allows for 1460 bytes of data payload, 20 bytes of TCP header, and 20 bytes of IP header. With PPPoE connections, the PPP and PPPoE header increases the frame size by 8 bytes, so we must lower the MTU to 1492. With the Ethernet header added to this, we get a frame size of 1518 bytes.

1492 + 8 + 18 = 1518 bytes

The network between the DSL multiplexer and the ISP aggregation router is ATM. ATM uses 48 byte fixed length cells.

1518 ÷ 48 = 31 cells + 30 bytes, or 32 cells.

ATM adds an 8 byte trailer to the entire 1518 byte frame, and adds a 5 byte header per 48 byte cell.

32 cells * 5 byte header = 160 bytes

The 32^nd cell is only 30 bytes long, and ATM mandates a fixed 48 byte cell. With the 8 byte ATM frame trailer appended to the original 30 byte cell, we get 40 bytes. The ATM network must add an additional 8 bytes of padding to fill the fixed 48 byte cell.

1518 + 8 + 160 + 10 = 1696 bytes

1696 bytes are transmitted for 1452 bytes of actual payload. (1492 bytes minus TCP and IP headers)

1696 ÷ 1452 = 1.168 – 1 * 100% = 16.80% overhead

Lowering the MTU to 1452 removes the necessity for adding 10 bytes of padding.

1452 + 8 + 18 = 1478 bytes

1478 ÷ 48 = 30 cells + 38 bytes, or 31 cells

The 8 byte ATM frame trailer is added to the 31^st cell to make 46 bytes, requiring only 2 bytes of additional padding to meet the total 48 bytes required per cell. Finally, the 5 byte cell headers are added to the 31 cells.

31 cells * 5 byte headers = 155 bytes

Add up the entire payload and overhead:

1478 + 8 + 155 + 2 = 1643 bytes

1643 bytes are transmitted for 1412 bytes of actual payload. (1452 bytes minus TCP and IP headers)

1643 ÷ 1412 = 1.163 -1 * 100% = 16.36% overhead

With the MTU on PPPoE connections set to 1452 the overhead per frame is reduced by 0.44%. This translates into a faster internet connection. On a standard T1 at 1.544 Mbps, this means an increase of about 10 kbps.

Note: maximum MTU may differ per provider.

Occurs when the IPsec driver failed to install during the GVC install on Vista even though no error was displayed during the installation.

This issue has been fixed in the SonicWALL GVC 4.0.0 release.

If the issue persists after the upgrade, follow these steps:

1. Uninstall Global VPN Client using Add/Remove Programs in the Control Panel.
2. Reboot.
3. Run the GVC cleaner tool to remove the Deterministic Networks (DNE) driver. A link to download this tool is available as a related item link.
4. Reboot.
5. Reinstall GVC.

If you are using Windows 7 then follow these steps:

1. Install SonicWall VPN client
2. Reboot
3. Open device manager
4. Click “View“, then “Show Hidden Devices”.
5. Expand “Non Plug n Play Drivers”
6. Open the SonicWall IPSec device and set startup type to Automatic
7. Click Start to get the driver up again.
8. Reboot again to check if your new settings worked.

Inactivity Timeout will drop the connections of applications that remain idle or inactive. The default inactivity timeout setting on rules is 15 minutes for TCP and 30 seconds for UDP. SonicWALL will close a connection when the inactivity timer expires. SonicOS Standard and Firmware 6.X do not apply rules on VPN traffic by default, but SonicOS Enhanced does. 

SonicOS Enhanced applies rules to all VPN traffic and there is a default rule for this traffic. Citrix, MS Terminal Services, PCAnywhere, Telnet, and other remote access applications are particularly susceptible to this. Microsoft Outlook/Exchange performance can also be affected. These applications often have long periods of inactivity. This will cause an interuption which will appear to be a dropped session.  

Resolution/Workaround:

It is recommended that you create specific rules from the LAN zone to the VPN zone and from VPN to LAN for these applications to extend the timeout period, which will minimize the number of open connections in the connection cache for other applications. Using MS Terminal Services as the example, follow these steps to create the necessary firewall access rules:

1. Select Firewall > Access Rules.
2. Select the Matrix view and choose the LAN > VPN intersection.
3. Click Add a new entry and enter the following rule:
   • Action: Allow
   • Service: Terminal Services
   • Source: Any
   • Destination: Any
   • Users Allowed: All
   • Schedule: Always on
   • Allow Fragmented Packets: Checked 
4. Click the Advanced tab.
5. Enter a value in the TCP Connection Inactivity Timeout (minutes): field that is larger than the default. It may be necessary to experiment with this value, deriving a number high enough to solve the timeout issue while avoiding leaving idle connections open unnecessarily.
6. If necessary for your application, enter a value in the UDP Connection Inactivity Timeout (seconds):
7. Click OK.
8. Choose the VPN > LAN intersection in the rules matrix and repeat this procedure starting with step 3.

This article provides information on how to configure the SSL VPN features on the SonicWALL security appliance. SonicWALL’s SSL VPN features provide secure remote access to the network using the NetExtender client.

NetExtender is an SSL VPN client for Windows, Mac, or Linux users that is downloaded transparently and that allows you to run any application securely on the company’s network. It
uses Point-to-Point Protocol (PPP). NetExtender allows remote clients seamless access to resources on your local network. Users can access NetExtender two ways:

• Logging in to the Virtual Office web portal provided by the SonicWALL security appliance and clicking on the NetExtender button.
• Launching the standalone NetExtender client.

The NetExtender standalone client is installed the first time you launch NetExtender. Thereafter, it can be accessed directly from the Start menu on Windows systems, from the
Application folder or dock on MacOS systems, or by the path name or from the shortcut bar on Linux systems.

For more information refer: UTM – FAQ: What are the basics of SSLVPN setup on Gen5 UTM appliances running SonicOS Enhanced 5.2? 

Procedure:

Step 1. Login to the SonicWALL UTM appliance, go to SSL-VPN > Server Settings page allows the administrator to enable SSL VPN access on zones, from SonicOS Enhanced 5.6.x.x onwards the SSL-VPN feature on UTM devices uses port 4433.

Please Note: In previous firmware versions the SSL-VPN Zones settings are available under SSL-VPN > Client Settings page.

Step 2. Configure the SSL VPN > Client Settings.

The SSL VPN > Client Settings page allows the administrator to configure the client address range information and NetExtender client settings.

The most important being where the SSL-VPN will terminate (eg on the LAN in this case) and which IPs will be given to connecting clients. Finally, select from where users should be able to login (probably, this will be the WAN, so just click on the WAN entry):

Note (New for SonicOS Enhanced 5.5 and above): NetExtender cannot be terminated on an interface that is paired to another interface using L2 Bridge Mode. This includes interfaces bridged with a WLAN interface. Interfaces that are configured with L2 Bridge Mode are not listed in the “SSLVPN Client Address Range” Interface drop-down menu. For NetExtender termination, an interface should be configured with as a LAN, DMZ, WLAN, or a custom Trusted, Public, or Wireless zone, and also configured with the IP Assignment of “Static”. 

Configuring NetExtender Client Settings:

Enable the option Create Client Connection Profile - The NetExtender client will create a connection profile recording the SSL VPN Server name, the Domain name and optionally the username and password.

Step 3. The SSL VPN > Client Routes page allows the administrator to control the network access allowed for SSL VPN users. The NetExtender client routes are passed to all NetExtender clients and are used to govern which private networks and resources remote user can access via the SSL VPN connection.

Note: All clients can see these routes. Also, here you may enable/disable “Tunnel All Mode” (this is the equivalent of “This gateway only” option while configuring GroupVPN).

Step 4. Under Users > Local users, ensure that the relevant user is part of the “SSLVPN Services” group:

Groups Tab:

On the VPN Access Tab allows users to access networks using a VPN tunnel, select one or more networks from the Networks list and click the arrow button -> to move them to the Access List. To remove the user’s access to a network, select the network from the Access List, and click the left arrow button <-.

Step 5. Under Firewall > Access Rules, note the new SSLVPN zone:

Step 6. Modify the SSLVPN to LAN rules to allow access only to those users that are configured (recommended to use single rule with groups rather than multiple rules with individual users). Ignore any warning that login needs to be enabled from SSLVPN zone.

Please note: Prior to SonicOS Enhanced 5.6, the “VPN access list” that we normally use for GVC VPNs has no effect. You can control access using the firewall rules:

Step 7: Goto WAN interface and ensure HTTPS user login is enabled:

How to Test this Scenario:

1. Users can now go to the public IP of the sonicwall. Notice the new “click here for SSL login” hyper link:

2. Users can then login and start netextender:

NetExtender provides remote users with full access to your protected internal network. The experience is virtually identical to that of using a traditional IPSec VPN client, but NetExtender does not require any manual client installation. Instead, the NetExtender Windows client is automatically installed on a remote user’s PC by an ActiveX control when using the Internet Explorer browser, or with the XPCOM plugin when using Firefox.

On MacOS systems, supported browsers use Java controls to automatically install NetExtender from the Virtual Office portal. Linux systems can also install and use the NetExtender client.

After installation, NetExtender automatically launches and connects a virtual adapter for secure
SSL-VPN point-to-point access to permitted hosts and subnets on the internal network.