Advanced VPN

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 3rd 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)
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
WAN IP 216.215.77.73/29 Destination Network=192.168.2.0
WAN IP 216.215.77.65/29 SubnetMask=255.255.255.0
Advanced Option(s)=None
SA Name=SiteB
Site A IPSEC Gtwy=216.215.77.65
Site B Destination Network=192.168.3.0
LAN IP 192.168.2.1/24
LAN IP 192.168.3.1/24 SubnetMask=255.255.255.0
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
Site B
HQ SA Name=HQ
IPSEC Gtwy=216.215.77.57
LAN IP 192.168.1.1/24 Destination Network=192.168.1.0
SubnetMask=255.255.255.0
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
Page 1 of 21
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 192.168.3.2

1 Allow Web (HTTP)
(WAN) (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)
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
WAN IP 216.215.77.73/29 Destination Network=216.215.77.72
SA Name=SiteB
Site A IPSEC Gtwy=216.215.77.65
Site B Destination Network=216.215.77.64
LAN IP 192.168.2.1/24
LAN IP 192.168.3.1/24 SubnetMask=255.255.255.248
Site A
SA Name=HQ
192.168.2.2 IPSEC Gtwy=216.215.77.57
192.168.3.2
Advanced Option(s)
$ Apply NAT and Firewall Rules
HQ Site B
SA Name=HQ
LAN IP 192.168.1.1/24 IPSEC Gtwy=216.215.77.57
Advanced Option(s)
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)
Headquarters
SA Name=SiteA (Manual Key)
IPSEC Gtwy=0.0.0.0
WAN IP Dynamic Destination Network=0.0.0.0-0.0.0.0
WAN IP Dynamic Subnet Mask=255.255.255.255
SA Name=SiteB
Site A
Site B IPSEC Gtwy=0.0.0.0
LAN IP 192.168.2.1/24 Destination Network=0.0.0.0-0.0.0.0
LAN IP 192.168.3.1/24
Subnet Mask=255.255.255.255
Site A
192.168.2.2 SA Name=HQ
192.168.3.2 IPSEC Gtwy=216.215.77.57
WAN IP 216.215.77.57/29 Advanced Option(s) Enabled
Site B
HQ SA Name=HQ
LAN IP 192.168.1.1/24 IPSEC Gtwy=216.215.77.57
Subnet Mask=255.255.255.0
Advanced Option(s)
192.168.1.2
Page 3 of 21
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.
Page 4 of 21
"Hub and Spoke" with Full Connectivity
Headquarters
SA Name=SiteA
Site A Advanced Option(s) Enabled
LAN IP 192.168.2.1/24 $ Forward Packets To Remote VPN's
Site B
LAN IP 192.168.3.1/24 SA Name=SiteB
Advanced Option(s) Enabled
192.168.2.2 $ Forward Packets To Remote VPN's
192.168.3.2 Site A
SA Name=HQ
Destination Network(s)
$ 192.168.1.0
$ 192.168.3.0
Site B
HQ SA Name=HQ
LAN IP 192.168.1.1/24 Destination Network(s)
$ 192.168.1.0
$ 192.168.2.0
192.168.1.2
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.
Page 5 of 21
Disabling Split Tunneling
Headquarters-Firewall
Static Routes Defined to all Remote Sites
(e.g. Network 192.168.2.0 via 192.168.1.2,
WAN IP 216.215.77.73/29 network 192.168.3.0 via 192.168.1.2)
WAN IP 216.215.77.65/29
Headquarters-VPN Concentrator
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Site A Destination Network=192.168.2.0
Site B SubnetMask=255.255.255.0
LAN IP 192.168.2.1/24
LAN IP 192.168.3.1/24 Advanced Option(s)
$ Default LAN Gateway=192.168.1.1
SA Name=SiteB
IPSEC Gtwy=216.215.77.65
192.168.2.2 Destination Network=192.168.3.0
192.168.3.2
Advanced Option(s)
$ Default LAN Gateway=192.168.1.1
WAN IP 216.215.77.58/29
Site A
SA Name=HQ
IPSEC Gtwy=216.215.77.57
WAN IP 216.215.77.57/29
Advanced Option(s)
$ Route all Traffic Through This SA
HQ-VPN Concentrator HQ-Firewall
Site B
LAN IP 192.168.1.2/24 LAN IP 192.168.1.1/24 SA Name=HQ
IPSEC Gtwy=216.215.77.57
Switch Advanced Option(s)
$ Route all Traffic Through This SA
192.168.1.3
Figure 5.
Page 6 of 21
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 stayed up.
up with VPN Client Address you
bypass the requirement of At the VPN client the configuration is easy. If all of the internal networks
configuring remote sites for
dynamic SA’s. This however fall within the same address range (e.g. 192.168.1.0/24, 192.168.2.0/24,
requires that you specify an IP etc.), you can simply supernet the subnet specified under ‘Remote party
address for each VPN client user. Identity and Addressing’ (e.g. Subnet: 192.168.0.0. mask: 255.255.0.0)
Selecting ‘Options -> Global to encompass all of the destination networks. If the destination networks
Policy Settings -> Allow to
specify internal Network Address’ fall within different address ranges (e.g. 10.1.0.0, 172.16.1.0,
allows you to configure this. 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.
Figure 6. Figure 7.
Page 7 of 21
VPN client concentrator
(no specified VPN client addresses required)
Headquarters
SA Name=SiteA
IPSEC Gtwy=216.215.77.73
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
Site B $ Forward Packets to Remote VPN
LAN IP 192.168.2.1/24
LAN IP 192.168.3.1/24
SA Name=GroupVPN
192.168.2.2 Site A
192.168.3.2
SA Name=HQ
WAN IP 216.215.77.57/29 IPSEC Gtwy=0.0.0.0
Site B
HQ
SA Name=HQ
LAN IP 10.1.1.1/24 IPSEC Gtwy=0.0.0.0
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.
Figure 9. Figure 10.
Page 8 of 21
(Specified VPN client addresses required)

SA Name=SiteA
IPSEC Gtwy=216.215.77.73
Advanced Option(s)
WAN IP 216.215.77.73/30
WAN IP 216.215.77.65/30 SA Name=SiteB
IPSEC Gtwy=216.215.77.65
Site B $ Forward Packets to Remote VPN
LAN IP 192.168.2.1/24
LAN IP 192.168.3.1/24
SA Name=GroupVPN
192.168.2.2 Site A
192.168.3.2
SA Name=HQ
WAN IP 216.215.77.57/29 IPSEC Gtwy=216.215.77.57
$ 10.1.1.0
$ 192.168.255.0 (VPN client network)
VPN client Concentrator
LAN IP 10.1.1.1/24 Site B
SA Name=HQ
IPSEC Gtwy=216.215.77.57
$ 10.1.1.0
10.1.1.2 $ 192.168.255.0 (VPN client network)
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.
Page 9 of 21
2. Open the Security Policy Editor. If you have already imported the GroupVPN client policy you
should see something like this:
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:
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:
Page 10 of 21
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:
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:
Page 11 of 21
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:
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.
Page 12 of 21
Extending SonicWALL Functionality with 3rd 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.
Page 13 of 21
3. Open the Steel Belted Radius administrator program and click ‘Connect’. The screen should look
like this.
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.
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.
Page 14 of 21
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.
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

Tip: When you save the file save it
clients. From the GroupVPN SA click the export button and save with a .reg extension. This makes for
the file locally. Open this file with the SonicWALL VPN client easy distribution and installation.
‘Security Policy Editor’. Browse to ‘My Identity’ and click the ‘Pre- Simply email the policy file to your
Shared Secret’ button. Enter in the exact same pre-shared secret end users and have them double-
click it to enter the information into
that is in the GroupVPN SA. Next click ‘Save’ then click ‘File #
the registry. This will automatically
Export Security Policy’. The dialog will ask you if you would like configure their VPN client).
to lock the policy, if you are distributing to end users this is
generally a good idea.
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.
Page 15 of 21
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
Page 16 of 21
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). 1When 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).
Page 18 of 21
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
Page 19 of 21
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.
Page 20 of 21
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.
Page 21 of 21

Advanced VPN

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Advanced VPN

Încărcat de

Drepturi de autor:

Formate disponibile

TECHnotes

Guide to SonicWALL Advanced VPN Options

Normal Site-to Site VPN

Applying Firewall Rules

Action Service Source Destination Time Day Enable

192.168.1.1 – 192.168.1.254 192.168.3.2

VPN Using the NAT & Firewall Rules

VPN Using the NAT & Firewall Rules

How can I use this feature?

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

Figure 9. Figure 10.

VPN client concentrator

Disabling Split Tunneling at the VPN client

How can I use this feature?

8. The final step is to generate a GroupVPN configuration file for the

Typical Placement of Superscout Server

Security Parameters Index (Manual Key Only) – Between 3 to 8 characters (HEX).

Encryption Method (Named Phase 2 Encryption/Authentication when using IKE) – The

Enable Windows Networking (NetBIOS) broadcast - Computers running Microsoft Windows

S-ar putea să vă placă și