Beruflich Dokumente
Kultur Dokumente
2003 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Will there be a preferences converter tool for older SonicWALL firmware (6.4, 6.5) to SonicOS 2.0s
and 2.0e?
No, there will be no external preferences converter tool. However, it is possible to import a prefs file from
6.4 or 6.5 into a device running SonicOS 2.0s. Importing a prefs file from 6.4 or 6.5 into a device running
SonicOS 2.0e is not supported.
Can I install SonicOS 2.0s or SonicOS 2.0e on older SonicWALL models?
SonicWALL is currently investigating porting SonicOS 2.0s to select older models, but has not made any
concrete plans to do so at this time. SonicOS 2.0e will not be provided on older models.
Is SonicOS 2.0e harder to use?
There are new features that allow SonicOS 2.0e to meet the needs of more complex networks, but the
interface is intuitive for network professional. SonicWALL has attempted to provide configuration controls
that are as easy to use as possible, but some of the Enhanced firmware functions such as NAT Policy,
WAN/WAN Active Load Balancing, and NAT/VPN rules on VPN tunnels require careful programming in
order to perform as desired. Because SonicOS 2.0e is targeted at more complex and, consequently,
more widely varied environments, fewer wizards will be provided allowing for more flexibility and
configurability.
Can I operate my PRO 3060 or PRO 4060 with the cover removed?
NO! The cooling systems in the PRO 3060 & 4060 rely on the cover being installed and in place in order
to provide proper ventilation for the processors onboard. Operating either model with the cover removed
can cause permanent damage to the processors and motherboard, and void the warranty. Do not power
up your PRO 3060 or PRO 4060 with the cover removed.
What kinds of processors are in the PRO 3060 & PRO 4060?
Both models have a 2GHz Intel as their main processor, which handles all I/O, firewall, and packet
processing functions. All cryptographic and hashing mechanisms are offloaded to a Cavium Nitrox coprocessor. The Nitrox co-processor is capable of processing AES, 3DES/DES, MD5/SHA-1, and ESP all
in hardware, dramatically increasing the encryption speeds of the PRO 3060 & 4060.
How much memory is in the PRO 3060 & PRO 4060?
Both models contain 256 MB RAM and 64 MB secure compact flash. While both memory modules are
removable, SonicWALL does not allow the memory modules to be replaced or upgraded in the field.
Removing or otherwise altering the memory in the PRO 3060/4060 will void the warranty. Adding
additional memory into either device is not currently supported.
What is secure compact flash?
The secure compact flash encrypts and protects the SonicOS firmware. The compact flash (CF) used in
the PRO 3060 and 4060 provides the fastest data transfers rates currently available with the CF format,
with sustained read rates of 6MBps and burst rates of up to 16.6MBps. Since the contents of the flash are
encrypted, it is not possible to read the contents of the flash with a CF reader, nor is it possible to take the
flash from one SonicWALL device and install it in another SonicWALL device.
How many interfaces are in PRO 3060 & PRO 4060?
Both models have six 10/100 auto-sensing Ethernet ports located on the front of the device, labeled X0
to X5. The LAN port and zone are permanently attached to the X0 port, and the primary WAN port and
zone are permanently attached to the x1 port. The ports labeled X2, X3, X4 can be assigned for any
purpose they can be added as extra ports to the LAN zone, assigned as the secondary WAN port, or
added to their own security zones. The X5 port can also be assigned to any of these functions, but is
also the only port capable of acting as the hardware failover link to a backup 3060/4060 device. However,
for PRO 3060 units running SonicOS 2.0s, interfaces X3-X5 are software disabled and cannot be used
until the unit has SonicOS 2.0e installed.
Page 2 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Are all the Ethernet interfaces on PRO 3060 & PRO 4060 AutoMDIX-capable?
No, they are not.
Can the Ethernet interfaces be assigned to the same IP subnet?
No. Each interface must be assigned to a different IP subnet, and cannot be used as switch ports. As
noted, though, interfaces can be assigned to the same security zone.
Can I change the default IP address of the LAN interface (X0)?
Yes. The devices ship with 192.168.168.168/24 as the default IP address, but can be changed to any
value. Please note that the new value will take effect as soon as the OK button is clicked, so you will
need to change the IP address of your management station to match the new IP subnet of the LAN
interface, and then log back into the device to continue device setup.
Do the PRO 3060 & PRO 4060 have a console port?
Yes, each model has a single DB-9 console port, and a DB9 male-to-female null modem cable is included
with each device. The settings for the console port are 115200 bits per second, 8 data bits, No parity,
1stop bit, and no flow control. These settings cannot be modified at present. With SonicOS 2.0, the CLI
attached to the console port is much more functional than in previous versions of firmware, but still has
limited functionality. The CLIs capability will be greatly expanded over the next six months; the goal is to
eventually offer all GUI-based configuration options via the CLI.
What are the physical specs for the PRO 3060 & PRO 4060?
Dimensions: 1U rack-mountable, 1.75 high, 17 wide, 13 deep
Weight: 13 lbs (17.5 lbs with accessory kit manuals, power cords, mount brackets, etc)
Power: 100V-240V AC, 250w.
Environment: Temperature 40-105 F, 5-40 C, Humidity 10-90% non-condensing
Regulatory Compliance: EMC: FCC Class A, ICES Class A, CE, C-Tick, VCCI, BSMI, MIC, NOM,
Safety: UL, cUL, TUV/GS
MTBF: 35,000 hours
Why are there so many fans in the PRO 3060 & PRO 4060?
Both models require a significant amount of cooling due to the high-speed processors on the
motherboard. There are six fans in each device - four in the main chamber of the chassis and two in the
power supply. Both devices can lose one chassis fan and one power supply fan and continue to operate.
If an onboard fan fails, the Alarm light on the front of the device will flash on and off, the device will beep,
and a warning message will be logged. Fans cannot be replaced in the field, and the device will need to
be RMAd. To maintain proper airflow and cooling, the top of the chassis must be kept securely on the
PRO3060 & PRO 4060 during operation. Operating with the chassis open voids the warranty.
How long does it take for the PRO 3060 & PRO 4060 to start up?
The average startup time from power-on to operation is approximately one minute. The device performs a
number of hardware and software diagnostic check routines upon warm and cold boots to ensure the
device and firmware are operational.
What exactly is a zone?
A zone is simply a logical grouping of one or more interfaces or subinterfaces, and is intended to make
creating security policy a much simpler task. With SonicOS 2.0e, interfaces do not have the same
importance in terms of how the security policy functions as they did in previous versions of firmware.
Please refer to the doc Security Zones in SonicOS 2.0 Enhanced for a full discussion on this topic.
I created some zones, but they do not show up in the rules matrix why?
Zones will not display in the access rules matrix unless an interface has been explicitly bound to the zone.
Once an interface has been added to a zone, it will then show up in the matrix, and you can then write
rules to/from this zone.
Page 3 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Can I run the PRO 3060 & PRO 4060 in transparent mode?
If the PRO 3060 or PRO 4060 is running SonicOS 2.0e, then it is not possible to run in transparent mode
(aka standard mode). A PRO 3060 running SonicOS 2.0s is capable of running in transparent mode, so
if the feature is required, this model and firmware are recommended.
How many permanent user accounts can I create?
Up to 500 unique user accounts can be created on the PRO 3060, and up to 1,000 unique user accounts
can be created on the PRO 4060. If customers need additional accounts for either device, it is advised
that they forward all user/password functions to a secured RADIUS server located on the internal
network.
How many groups can I create?
With SonicOS 2.0e, up to 64 unique user groups can be created on the PRO 3060, and up to 128 unique
user groups can be created on the PRO 4060. SonicOS 2.0s does not support user groups. This may
expanded in future versions of firmware.
How many users can I put in a group?
Although there is no limit on the number of users we can add to any one group, there is actually a limit of
4,000 on the total number of group memberships that can be set.
How many destination network objects can I assign to a group or user?
There are no restrictions to the amount of network objects you can assign to a group or user, but please
keep in mind that pushing an extremely high number of destination network objects to a Global VPN
Client may cause problems with the underlying OS of the computer the Client is running on.
How many DHCP scopes can I create in SonicOS 2.0s and SonicOS 2.0e?
With SonicOS 2.0s, you can create a range for the LAN and DMZ interfaces, and those ranges can each
have 254 addresses maximum. With SonicOS 2.0e, its a little different you can create up to 64 ranges,
but there is a global limit of 4,096 assignable addresses, so you will need to take care not to exhaust the
global limit with multiple defined ranges. 2.0e also allows the admin to create DHCP scopes larger than a
single class C, up to the size of the global limit.
What is the difference between signed and non-signed firmware?
The PRO 3060 and PRO 4060 require signed firmware images, unlike other SonicWALL Firewall/VPN
devices. This is a new security mechanism added to the firmware to prevent tampering, and ensures that
the image is both valid and originates from SonicWALL. Because of this, the PRO 3060 & 4060 will not
accept non-signed firmware images. All signed images end with a .sig extension.
Are the PRO 3060 & PRO 4060 ICSA-Certified?
SonicWALL has submitted the PRO 3060 & 4060 for ICSA 1.1 IPSec and ICSA 4.0 Firewall certification
and is currently awaiting approval (ETA Fall 2003).
Do the PRO 3060 & PRO 4060 support protocols other than IP?
No. The PRO 3060 & 4060 can only process IP traffic and cannot process IPX/SPX, NetBEUI, AppleTalk,
DECNet, LAT, or SNA traffic natively. In addition, neither model is currently capable of natively processing
GRE or Multicast packets. In order for the PRO 3060 & 4060 to process such traffic it must first be
encapsulated into IP packets by another device before it reaches the PRO 3060 & 4060s interfaces.
PPTP is supported as a pass-through protocol if a specific rule is written for it.
Page 4 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Which routing protocols does the PRO 3060 & PRO 4060 support?
Support for routing protocols is limited in SonicOS 2.0e at present the device is only capable of using
RIPv1 and RIPv2 to advertise networks (it cant listen to RIP broadcasts and include them in its routing
table). RIP advertisements may be enabled and configured on any interface (previously it could only be
enabled on the LAN and DMZ). Support for default route advertisement has been added. For each
interface, the user may configure RIP to:
always advertise the default route
never advertise the default route
conditionally advertise the default route depending on the viability of the WAN connection (nonWAN interfaces only). This taps into the wan-failover logic to determine the viability of our WAN
connection(s).
The user now has the choice of enabling or disabling advertisement of remote VPN networks that are
accessible via the interface for which RIP is being configured. Remote VPN networks will only be
advertised when the remote address object is of the type "Network". "Range" and "Host" networks cannot
be advertised. When advertisement of static routes is enabled, RIP will advertise all accessible routes,
regardless of the route's egress interface. Previously, only routes that egressed out of the WAN interface
were advertised. Intra-zone route advertisement will be consistent with the configuration of intra-zone
communication on the Network >Zones page. Dynamic routing support will be expanded in SonicOS
2.5e.
Can I set up VPN tunnels to older SonicWALL devices?
Yes. Please refer to the SonicWALL technote IKE VPN Tunnel between SonicWALL 6.5 and SonicOS2.0
Enhanced.
Can I set up site-to-site VPN tunnels from the PRO 3060 & PRO 4060 to other devices?
Yes, as long as the other device supports manual IPSec or IKE IPSec. This would include all other IPSeccapable SonicWALL models, and devices from other manufacturers.
How many firewall policies can I create in the PRO 3060 & PRO 4060?
The PRO 3060 supports up to 5,000 firewall policies (running SonicOS 2.0s or SonicOS 2.0e), and the
PRO 4060 supports up to 10,000 firewall policies.
How many concurrent firewall sessions supported by PRO 3060 & PRO 4060?
PRO 3060 supports up to 128,000 concurrent sessions (running SonicOS 2.0s or SonicOS 2.0e), and
PRO 4060 supports up to 500,000 concurrent sessions. This number should not be interpreted as the
number of simultaneous users the device can support, as many applications are capable of opening
multiple concurrent connections, and because many users typically operate with multiple programs open
and active. A good rule of thumb is to assume that any user, at any given time, has over 20 sessions
open to various locations inside and outside the network.
How many Global VPN Client VPN sessions does PRO 3060 & PRO 4060 support?
PRO 3060 running SonicOS 2.0s: Up to 500 simultaneous GlobalVPN client sessions
PRO 3060 running SonicOS 2.0e: Up to 500 simultaneous GlobalVPN client sessions
PRO 4060 running SonicOS 2.0e: Up to 3,000 simultaneous GlobalVPN client sessions
How many site-to-site VPN sessions does PRO 3060 & PRO 4060 support?
PRO 3060 running SonicOS 2.0s: Up to 500 simultaneous site-to-site VPN sessions
PRO 3060 running SonicOS 2.0e: Up to 1,000 simultaneous site-to-site VPN sessions
PRO 4060 running SonicOS 2.0e: Up to 3,000 simultaneous site-to-site VPN sessions
Page 5 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
How many simultaneous L2TP sessions can the PRO 3060 & PRO 4060 support?
A SonicWALL running SonicOS 2.0 Enhanced should be able to terminate about 2,000 L2TP sessions,
but please note that this may be limited by available RAM (since RAM is shared by other processes, most
notably the firewall connection table, and the IPSec VPN connections).
Given that the PRO 3060 can support up to 75 Mbps 3DES/AES performance, what are the
compelling reasons to purchase PRO 4060 instead?
With the rise of broadband access, WLAN and Internet becoming 24 x 7 tool for business continuity, it is
more important than ever that customers start deploying additional broadband and encryption capacity
from the day one versus requiring to do field upgrade shortly after the initial deployment. Also, the overall
cost of field-replacing a 3060 with a 4060 will be significantly higher than the cost delta between PRO
4060 vs. 3060 during initial purchase. Further, the VPN performance of the PRO 3060 cannot be
upgraded to the PRO 4060 performance levels.
What are the primary differences between SonicOS 2.0 Standard and SonicOS 2.0 Enhanced?
SonicOS 2.0e supports business continuity features and additional VPN functionality features to provide
finer control over management of the business traffic. Please refer to the SonicWALL document SonicOS
2.0 Family Features for a comprehensive, detailed breakdown of the differences between the firmware
versions.
What VPN enhancements are in SonicOS 2.0e?
Definable IKE Identities Its now possible to specify the firewalls IKE identity and the expected
remote peer IKE identity. This feature was once hidden from the users control, and changed
depending upon how the WAN interface was addressed. This method made interoperating with
certain manufacturers rather difficult, so it is now possible to control what is sent and what is
expected. Users can now specify that the IKE Identities be an IP Address, or an Email Address,
or a Domain Name (FQDN).
Definable source & destination networks Its now possible to define network address objects,
group those objects together, and then assign those objects as the source and destination
networks to exchange when a VPN tunnel is established. In previous versions of firmware, the
firewall did not allow the user to specify which source destination networks were exchanged
during a VPN tunnel negotiation. This feature allows the user to control exactly which subnets are
exchanged with remote peers.
Multiple interface binding Its now possible for both WAN interfaces to initiate and respond to
VPN tunnel requests. In previous versions of firmware, the VPN tunnels appeared to terminate on
the WAN or WLAN ports, but in reality they were bound to the LAN port.
NAT & Firewall rules for VPN traffic Its now possible to drive all incoming and outgoing VPN
traffic through the zone security policy and the NAT policy. This allows users to restrict traffic to
and from VPN tunnels, and to perform NAT on traffic before it goes into a VPN tunnel, or after it
leaves a VPN tunnel on the way to a zone.
GroupVPN allowed networks policy Its now possible to control which destination networks are
exchanged with SonicWALLs Global VPN Client 2.0. When creating users and groups, the user
can define which network objects are bound to a specific group or user. When a GlobalVPN
Client attempts to make a connection to the SonicWALL, the firewall examines the user name
that is passed to it during XAUTH authentication. It first checks the users group, then checks the
user account to see if there are additional networks allowed. Please note that the allowed
destination networks feature is an additive system and not a restrictive system. This means that
whatever group or user destination networks policy has the most networks will be passed to the
client.
Page 6 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Some Unmapped: used when Original Source is NOT Any, and Translated Source is =Orig. This
is usually to override a less specific policys remapping for a certain address range, or the
Original Source is being used as a selector for a dest remapping.
All Unmapped: used when Original Source is Any and Translated Source is =Orig. No source
addresses are remapped.
Destination Remappings:
One/Few To Many: used when Original Dest contains fewer addresses than Translated Dest.
This is for load balancing for public servers. This is not yet implemented.
One To One: used when Original Dest and Translated Dest have the same number of addresses.
This is also available in the previous products. Each dest address will have a corresponding
remap address, and source port remapping is unnecessary.
Some Unmapped: used when Original Dest is NOT Any, and Translated Dest is =Orig. This is
usually to override a less specific policys remapping for a certain address range, or the Original
Dest is being used as a selector for a source remapping.
All Unmapped: used when Original Dest is Any and Translated Dest is =Orig. No dest addresses
are remapped.
Service Remappings:
One To One: used when Original Service and Translated Service have the same number of
services. Each source service will have a corresponding remap service.
Some unmapped: used when Original Service is NOT Any, and Translated Service is =Orig. This
is generally for public server rules, where the Original Service is being used as a selector for a
Source or Dest remapping.
All unmapped: used when Original Source is Any and Translated Source is =Orig. No source
addresses are remapped.
How many NAT policies can I create?
A device running SonicOS 2.0.0.2s can store up to 256 unique NAT policies. A device running SonicOS
2.0.0.2e can store up to 512 unique NAT policies.
What is the firewall throughput of the PRO 3060 & PRO 4060?
Cleartext throughput is 300 Mbps for both models, regardless of firmware version.
What is the 3DES/SHA-1 throughput of the PRO 3060 & PRO 4060?
PRO 3060 running SonicOS 2.0s: 75Mbps (UDP bi-directional, 1280 byte packets)
PRO 3060 running SonicOS 2.0e: 75Mbps (UDP bi-directional, 1280 byte packets)
PRO 4060 running SonicOS 2.0e: 190Mbps (UDP bi-directional, 1280 byte packets)
What is the AES-256/SHA-1 throughput of the PRO 3060 & PRO 4060?
PRO 3060 running SonicOS 2.0s: 75Mbps (UDP bi-directional, 1280 byte packets)
PRO 3060 running SonicOS 2.0e: 75Mbps (UDP bi-directional, 1280 byte packets)
PRO 4060 running SonicOS 2.0e: 190Mbps (UDP bi-directional, 1280 byte packets)
How many WAN sessions can PRO 3060 & PRO 4060 support?
When running SonicOS 2.0e, the PRO 3060 and 4060 can support up to two concurrent WAN sessions.
As the products support six interfaces, if the customer decides to use only a single WAN session, then
the rest of the interfaces can be assigned to other security zones.
Is there an easy way to erase the config file on the PRO 3060 & PRO 4060?
This is done from the System > Settings menu by booting the box with the Current Firmware with
Factory Default settings button. All stored settings (including username, password, and LAN IP address)
will be discarded and the device will reboot with factory settings (username: admin, password: password,
LAN IP Address: 192.168.168.168).
Page 8 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Is there an easy way to erase the firmware on the PRO 3060 & PRO 4060?
In previous versions of SonicWALL firmware, the device could only hold one version of firmware. With
SonicOS 2.0e, its now possible to store multiple versions of firmware, eliminating the need to erase the
firmware. Simply load a new version and boot that one instead the previous one will be stored as a
backup, in case the new firmware fails to operate as intended.
What is SafeMode?
SafeMode is a feature of the SonicOS 2.0e firmware that allows the firewall to store multiple versions of
firmware, including a rescue image that can be used to boot the firewall with all previous settings in case
of emergency. SafeMode allows firewall administrators to switch between firmware builds and revert to
known-good versions in case a new firmware image turns out to cause issues. In cases of firmware
corruption, the device can be told to boot with a specific IP address, and will boot into a special GUI mode
that allows the administrator to choose which version to boot, and also allows the administrator to run
hardware diagnostics, view the bootlog, or export the bootlog to a file.
How do I access the SafeMode menu?
When the device is running, you can access the SafeMode menu from the System > Settings menu (it
will be under the Firmware Management section). In emergency situations, you can also access the
SafeMode menu by holding in the Reset button on the front panel of the 3060/4060 (its the small pinhole
button between the Console port and the LAN interface) for 12-14 seconds until the Test light begins
flashing red. If you have a Console session open, you will see the following dialog:
SonicROM Booting.............................
Initializing Firmware loader
SafeMode Switch Pressed
Initializing SafeMode
Starting SafeMode WebServer on 192.168.168.168
Also Starting SafeMode WebServer on (your LAN IP here)
Your SonicWALL is now running in SafeMode.
Connect to the SafeMode WebServer on 192.168.168.168
-Upload and download firmware images and system settings.
-Boot to your choice of firmware and settings.
-Manage system backups.
-Easily return your SonicWALL to a previous system state.
When the SonicWALL is booted into the SafeMode menu, connect a workstation to the LAN interface of
the 3060/4060 and access the special SafeMode GUI using the default IP address of 192.168.168.168, or
the devices previously saved LAN interface IP address. You will be able to boot the device using a
previously saved image, boot the device from a known-good Factory Default Image, or you can upload a
new version of firmware with the Upload New Firmware button.
What is FIPS Mode?
Enabling the FIPS mode checkbox in the management GUI automatically sets all necessary internal
settings for a PRO 4060 running SonicOS 2.0e to be FIPS 140-2 compliant. Enabling FIPS mode will not
change any functionality of the device, nor will it change the way the management GUI operates, but
please note that since FIPS mode forces the device to use a stronger PRNG algorithm for key generation,
VPN performance may be marginally affected. FIPS Mode is not supported in SonicOS 2.0s, or any
earlier version of SonicWALL firmware.
Page 9 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Page 10 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
What do all the lights mean on the front of the PRO 3060 & PRO 4060?
The PRO 3060 and PRO 4060 have 3 LEDs: Power, Test, and Alert, as well as a system buzzer. The
Power LED is controlled directly by Vcc (+5.0 Volt DC power) and is affected only by power-on/power-off.
The Test and Alert LEDs provide off, standard (yellow) and alternate (red) states that are fully
controllable. The following graphic describes the states and events:
= Power
= Standard
= Alternate
Event
Power on
BIOS
ROM
Reset Switch Sensed
SafeMode (entered)
Firmware (loading)
System up/normal
Minor Alarm
Major Alarm
Voltage askew
Fan Failure
Thermal Yellow
Thermal Red
Thermal Shutdown
= Blink Standard
Power
Test
= Blink Alternate
Alarm
Page 11 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Page 12 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Why are there 3 different mechanisms for setting user group memberships for RADIUS users?
The RADIUS specification does not clearly define a mechanism for defining user group memberships;
and RADIUS servers vary in how well and how easily they allow the various alternatives to be configured.
Therefore SonicWALL has implemented three different options for this, and you can choose the one best
suited to your organization.
Use SonicWALL vendor-specific attribute on RADIUS server A SonicWALL vendor-specific
RADIUS attribute has been defined for setting user group memberships on the RADIUS server.
One or more of these can be set for a user, each giving the name of one user group to which that
user has membership. A RADIUS dictionary defining this attribute is available from SonicWALL.
This method is probably a good one to choose if your RADIUS server allows easy configuration of
vendor-specific attributes. It is especially good with Funk Softwares Steelbelted RADIUS server
since that can import the SonicWALL dictionary directly.
Use RADIUS Filter-ID attribute on RADIUS server Filter-ID is a standard RADIUS attribute that
can be used for any form of filtering, in this case filtering users into user groups. Its is used on the
RADIUS server in exactly the same way as the SonicWALL vendor-specific attribute - one or more
can be set for a user, each giving the name of one user group to which that user has membership.
This method should work with any RADIUS server that properly implements the RADIUS
specification, and is probably a good one to choose if your corporate RADIUS server is not already
using the Filter-ID attribute for some other purpose.
Enter duplicate RADIUS user names locally on the SonicWALL In this case every RADIUS user
who is to be given group memberships or settings additional to the set defaults needs to have an
entry created in the Local Users list on the SonicWALL. That local user entry can then be added to
user groups just like any other user in the Local Users list (but note that the password and other
settings in it are ignored).
This method is an alternative for use with RADIUS servers that do not allow either of the above two
mechanisms, or for corporations who do not want to configure additional settings on their RADIUS
server.
Note that the need to set user group memberships for each individual RADIUS user can be minimized by
use of the All RADIUS Users virtual user or the Everyone user group. For example, if certain resources
are to be made available to everyone, but other resources are to available only to selected users, then
access to the open resources can be set for All RADIUS Users or Everyone, and access to the
restricted resources set for different user groups. It is then only necessary to configure individual group
memberships for those RADIUS users who need to access the restricted resources.
Note also that with the first two mechanisms, all user groups selected on the RADIUS server must exist in
the Local Groups list on the SonicWALL.
Page 13 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Why can user privileges be set on the RADIUS server but not VPN client access networks or CFS
policies?
Now that the SonicWall supports user groups, these settings are more easily configured by defining
groups of users with the same settings and configuring the settings in the user groups, and hence no
RADIUS attributes have been defined for these new features. The setting of user privileges on the
RADIUS server, however, is retained for backward compatibility.
How does the RADIUS configuration setting Allow only users listed locally differ from the
authentication method Use RADIUS but also allow locally configured users?
The former limits the RADIUS users that are allowed to log in to the SonicWALL; and the latter allows for
login of locally configured non-RADIUS users in addition to RADIUS users.
The Allow only users listed locally setting is used to select a sub-set of users on the RADIUS server that
are allowed to log in to the SonicWALL, which is achieved entering their names in the Local Users list on
the SonicWALL. It would be used where a corporate RADIUS server is used to control access to other
resources as well as the SonicWALL, and not all users in it are to be allowed access to the SonicWALL.
The Use RADIUS but also allow locally configured users authentication method basically combines
RADIUS and local user authentication, allowing both to be used simultaneously.
If I select Allow only users listed locally with RADIUS, can I configure any settings for the
RADIUS user in the local user entry on the SonicWALL?
No. In this case the password and any other settings in the local user entry are ignored, although it can
be used to define user group memberships for the RADIUS user if Enter duplicate RADIUS user names
locally on the SonicWALL has been selected for that purpose.
Can I set otherwise identical policy rules for different users?
No, but there is no need to do that. If you want to create the same policy rule for multiple users then
create a user group, give those users membership to it, and then create a single policy rule specifying
that user group as the users allowed.
Can I include the administrator in policy rules?
No, but there is no need. Anyone logged in as administrator gets implicit access through any policy rule
requiring authentication.
What is the difference between All and Everyone in a policy rule?
Selecting All for the users allowed means that the policy rule will allow all matching traffic, whether from
an authenticated user or not. Selecting the Everyone user group will allow traffic from any logged in
user, but not from a user who has not logged in.
What happens if a user or user group specified in a policy rule is deleted?
If that happens the policy rule is not deleted, but it is disabled and the users allowed is changed to
admin. The rule can then be deleted manually if so desired.
A policy rule requires authentication to access the Internet, but browsers are not getting
redirected to login to the SonicWALL when users try to do that. What is the problem?
There are a number of reasons that this can happen:
1. User login must be enabled on the interface or VPN policy that users are accessing it from.
2. If the DNS server is on the WAN side of the SonicWALL then an additional policy rule will be
needed to allow DNS traffic thorough without requiring authentication.
3. If users are accessing sites using HTTPS or non-standard HTTP ports then the SonicWALL
cannot redirect them. They must point their browsers at the SonicWALL to login first.
Page 14 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.
Why does a VPN policy that uses XAUTH require a user group for XAUTH users to be set, and how
does this relate to the VPN client access networks specified for the users?
The user group for XAUTH users selects a user group specifying those users who are allowed to connect
via this VPN policy when XAUTH is used, and hence such a VPN policy can be made available to a
subset of all users, or to all users by specifying the Everyone user group. Note that this only applies with
the SonicWALL VPN client or connections from 3rd party clients or other equipment that support XAUTH.
The VPN client access networks apply only with VPN client on GroupVPN, and specify the networks that
the user will get access to when he connects to the SonicWALL in this way. However, if XAUTH is
enabled on GroupVPN then even if a user has VPN client access networks defined he will still only be
allowed to connect by VPN client if he is a member of the user group for XAUTH users, should that be set
to something other than Everyone.
Can access be limited to a subset of users for VPN policies that do not use XAUTH?
Yes. That is achieved by setting the users allowed in policy rules in the VPN to LAN or VPN to DMZ
zones accordingly. By default a rule is created for each VPN policy to allow all traffic from its remote
networks with no user authentication needed, but that rule can then be edited to allow only authenticated
users as required.
Can the networks accessible to individual remote VPN users be set for cases other than the
SonicWALL VPN client, where the users VPN client access networks do not apply?
Yes. Again this can be controlled by policy rules in the VPN to LAN or VPN to DMZ zones. Create rules
allowing access to the various networks, and select the users allowed in those rules.
So how does setting the VPN client access networks for a user differ from setting policy rules to
give the user access to those same networks?
Setting VPN client access networks can be seen as more secure since the networks are negotiated with
the client during the set up of the VPN tunnel, and hence any attempt to access other networks behind
the SonicWALL will not get past the client. However, for the same reason it is only applicable to a singleuser connection, and so is not appropriate in the case of a VPN tunnel between two SonicWALLs. In that
case user authentication in the policy rules must be used.
How do I set the local networks for VPN client when XAUTH is not used and hence the VPN client
access networks are not available?
In that case the SonicWall does not know the user name of the connecting user and hence cannot
provide different network access to different users. Instead the local networks to be available to all VPN
client users are selected in the GroupVPN advanced settings.
Page 15 of 15
2001 SonicWALL, Inc. SonicWALL is a registered trademark of SonicWALL, Inc. Other product and company names mentioned herein may be trademarks and/or registered
trademarks of their respective companies.