You are on page 1of 15

SonicWALL PRO 3060 & PRO 4060 FAQ

Prepared by SonicWALL, Inc.


Version 1.6
11/24/2003
How are the PRO 3060 & PRO 4060 different from previous PRO models?
The 3060 and 4060 do not utilize any hardware or software components from the older PRO models.
The new 3060 & 4060 models are many times faster and more capable than the PRO 230 & 330 models,
mostly due to dramatic improvements in CPU, crypto chip, system bus, and memory. The new 3060 and
4060 models run SonicWALLs newest generation firmware, SonicOS 2.0, which is designed for
corporate customers with more complex network architectures that require a higher level of internal
security and flexibility.
How is the PRO 3060 different from the PRO 4060?
The PRO 3060 contains similar hardware as the PRO4060, but the 4060 utilizes a faster crypto engine
(multiple cores). The products have different speed, performance, and feature specifications; other
differences will be covered in this FAQ.
What is the minimum version of firmware the PRO 3060 & PRO 4060 will run?
The PRO 3060 ships with SonicOS 2.0 Standard, and can be upgraded via license to SonicOS 2.0
Enhanced (hereafter referred in this document as SonicOS 2.0s and SonicOS 2.0e, respectively).
However, the VPN performance of the PRO 3060 cannot be upgraded to the PRO 4060. The PRO 4060
cannot run SonicOS 2.0s, and requires SonicOS 2.0e firmware. Neither device can run the older 6.x
firmware releases, nor can they run the older SonicOS 1.x firmware. Updated versions of the SonicOS
2.0s and SonicOS 2.0e firmware are available to customers who have registered the device for the first
90 days. After 90 days, a software support contract may be purchased in order to receive SonicOS 2.0
updates.
Is SonicOS 2.0s management interface different from the 6.x firmware releases?
Yes, it has a new look and feel, is better organized, and is more intuitive. Users of SonicWALLs 6.x
firmware will find it easy to understand, and will be completely comfortable with using SonicOS 2.0,
whether its the Standard edition, or even the Enhanced edition. The management GUI for SonicOS 2.0
uses the same button-and-tab menu system that SonicWALL has used for years, and is accessible from
any modern web browser (IE 6.x, Mozilla 1.x, Opera 7.x, Netscape 6.2).
If a PRO 3060 running SonicOS 2.0s is upgraded to SonicOS 2.0e, does it then have the same
capabilities as a PRO 4060?
No. Upgrading from SonicOS 2.0s to SonicOS 2.0e will allow users to utilize the added capabilities of the
Enhanced firmware, but will not cause the 3060 to support the same number of site-to-site VPN
connections, sustained connections, Global VPN Client connections, firewall rules, and
encryption/cleartext throughput the 4060 supports. In addition, the VPN performance of the PRO 3060
cannot be upgraded to the PRO 4060 performance levels.
How do I upgrade a PRO 3060 running SonicOS 2.0s to SonicOS 2.0e?
You will need to export the existing preferences file off the PRO 3060 and convert it to a new preferences
file with an external utility, which SonicWALL will provide in the near future. Once this has been done, you
can upload the SonicOS 2.0e firmware onto the 3060, reboot, and then upload the converted preferences
file.
Can I downgrade a PRO 3060 running SonicOS 2.0e to SonicOS 2.0s?
Yes, but your SonicOS 2.0e preferences are not convertible to SonicOS 2.0s (the advanced objects in
SonicOS 2.0e cannot be mapped onto the SonicOS 2.0s preference structure).
Page 1 of 15

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

How does Hardware Failover work in SonicOS 2.0e?


Hardware Failover (previously called High Availability) now uses a dedicated interface to transmit sync
and heartbeat traffic between the primary and backup SonicWALL devices. The X5 interface must be
dedicated to this purpose, and when it is being used as the Hardware Failover (HF) link, it must be bound
to a special zone and cannot be used for any other purpose. Please note that no network resources
(users, servers, etc) can exist on this link it must be a dedicated link between the two devices. This
change was introduced because there will be forthcoming enhancements to Hardware Failover
functionality that will require a dedicated 100Mbps link between the primary and backup devices.
Can I use the X5 interface for other purposes if Im not using Hardware Failover?
Yes if Hardware Failover is not used, then the X5 port can be used as an additional interface and can
be added to any security zone defined on the device (assuming the device is running 2.0e, since the X5
interface is disabled in 2.0s).
How does Dual WAN/ISP Failover work?
SonicOS 2.0e can support two separate WAN connections, and has the ability to utilize these WAN
connections in two different methods. The first is a simple active/passive scenario where the secondary
WAN is only utilized if the primary WAN has failed, and can be set to revert to using the primary WAN
when connectivity is restored. The second method is a simple per-destination load balancing that utilizes
both connections, and balances the traffic flow between both WAN connections. However, this method
works best if both WAN connections are of equal value (i.e. they have similar inbound and outbound
speeds). With either method, the WAN connections can be monitored for physical and logical link
connection state to ensure that the links are up and pass traffic.
What can I do with the CLI in SonicOS 2.0e and SonicOS 2.0s?
The CLI included in both versions is the initial release, and because of this is limited in functionality. It will
only be accessible from the Console port, and cannot be accessed via Telnet or SSH. The CLI will be
expanded significantly in future releases to allow users to control every aspect of the devices
programming directly from the CLI. Telnet and SSHv1/v2 support will be added to the Enhanced firmware
featureset in the SonicOS 2.5 release. At present, the functionality is limited to basic interface
configuration commands, GMS configuration commands, and basic show commands to perform
troubleshooting directly from the Console port. For a complete list of all CLI commands, please refer to
the SonicOS 2.0e Administrators Guide.
Can I assign multiple public IP subnets to a WAN interface?
It is not currently possible to assign more than a single IP address to a primary or secondary WAN
interface, but the device is capable of answering on behalf of a 1-2-1 NAT policy set up for a network
resource. It is also possible to put a secondary WAN IP subnet on an internal interface, and not perform
NAT for the addresses on that interface. This would be useful in environments where the ISP has
assigned a customer multiple dissimilar public IP subnet blocks, and the customer wishes to use IPs from
these dissimilar blocks to provide access to internal network resources. What is required is for the ISPs
upstream routers to be capable of routing these subnets to the fixed IP address of the primary or
secondary WAN interfaces of the SonicWALL.
What are the features of the Network Address Translation (NAT) engine?
Source Remappings:
Many To One / Many To Few: used when the Original Source contains more addresses than the
Translated Source. This is the classic type of NAT found in SonicWALLs previous products,
where many addresses (i.e. the entire LAN subnet) are remapped to one address (the Many To
One public address). We can also remap to more than one Many To One address now, which is
called Many To Few. In these cases, we must select a dynamic source port for each connection
to keep track of where on the LAN these connections were created.
One To One: used Original Source and Translated Source have the same number of addresses.
This is also available in the previous products. Each source address will have a corresponding
remap address, and source port remapping is unnecessary.
Page 7 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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

Is there still a diag.html page?


Yes. This page is kept to store configuration settings that are rarely used, and for extremely specific
environments. Do not modify values on this page unless SonicWALL has requested you do so.
The access rules now have a discard radio button what is this?
When writing access rules, you now may specify that the SonicWALL silently drop (or discard) the
connection attempt, instead of sending an explicit connection close (reset). Doing so does not give a
potential attacker any indication that a security device is between he/she and the target, and increases
the level of security in the SonicWALL device.
I have AV enabled on an interface, but I cant seem to install the client on my system why?
The AV installation is done via browser and relies on a pop-up window to install properly. If you are not
able to install the SonicWALL AV Client on a system, check to see if the systems web browser is actively
blocking pop-ups, or that it does not have a third-party program (such as Pop-Up Stopper) that is
blocking the AV installation screen. In order to install the SonicWALL AV Client, you must allow pop-ups
during this process.
I activated CFS Premium, enabled all the categories, and none of the systems behind the
SonicWALL can access any site on the public Internet why?
CFS Premium contains a large number of new categories that, if activated, will block systems from
accessing sites that may seem innocuous, such as search engine portals, news media sites, and
computer manufacturers websites. There is also a final category called Not Rated that, if checked, will
block access to any site that is not in the CFS Premium database. Because of this, you will need to
carefully choose the appropriate categories for the CFS Premium policy applied to the SonicWALLs
zones.
My GroupVPN policy is set for AES, and some of my Global VPN Clients cannot connect why?
AES support is only in Global VPN Client version 2.0; version 1.0 does not support it. If you are mixing 1.x
and 2.x clients, you will need to specify 3DES as the encryption method for phase 1 and phase 2.

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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

What the SKUs for PRO 3060 & PRO 4060?


PRO 3060 w/SonicOS 2.0s SKUs are as follows:
North America (incl Canada): 01-SSC-5365
International [incl EMEA and APAC (except Japan)]: 01-SSC-5366
Japan: 01-SSC-5367
PRO 3060 SonicOS 2.0e Support Upgrade SKUs are as follows:
North America (incl Canada): 01-SSC-5375
International [incl EMEA and APAC (except Japan)]: 01-SSC-5376
Japan: 01-SSC-5377
PRO 4060 SKUs are as follows:
North America (incl Canada): 01-SSC-5370
International [incl EMEA and APAC (except Japan)]: 01-SSC-5371
Japan: 01-SSC-5372

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

Users & Groups In-Depth FAQ


From which of their user groups do users inherit settings?
Users inherit settings (privileges, VPN client access networks and CFS policies) from all user groups to
which they have membership either directly or indirectly though multiple levels of user group hierarchy,
including the Everyone group. In other words settings configured in a user group propagate down to any
member groups, and in turn to any member groups in those groups, etc.
Note that this is consistent with the use of user groups in policy rules. If a user group is specified in a
policy rule then all members of that group and any sub-groups are given access through the rule.
Similarly, if a user group is configured with any of these settings then all members of that group and any
sub-groups are given those settings.
How are hierarchies of user groups normally used?
Hierarchies of user groups (groups of groups) allow policy rules and VPN XAUTH access to be set for
multiple user groups. Say, for example, you have a Sales user group and a Marketing user group. If
you want to create a policy rule to give both Sales and Marketing access to something then you can
create a Sales and Marketing user group and add both user groups to it. You can then specify that
group for the users allowed in the policy rule. You can then also configure settings such as VPN client
access networks in the Sales and Marketing user group and those settings will get applied to all
members of both Sales and Marketing.
What is the Everyone user group for?
The Everyone user group always exists and all users, including RADIUS users, have implicit
membership to it. It is used to configure any settings that are to apply to all authenticated users. For
example, if web access to the Internet is to be available to anyone who can log in, then create a policy
rule for it and select the Everyone group for the users allowed.
When RADIUS is enabled All RADIUS Users appears as a local user. What is this for?
This is a virtual user that can be used to set user group memberships that will apply to all RADIUS users.
If you create a user group specifying those users who can have access to something and you want all
RADIUS users to have that access, then adding the All RADIUS Users user into that user group will
achieve this.
Note the All RADIUS Users virtual user can only be used for setting user group memberships you
cannot edit settings directly in it.
What is the purpose of the Default user group to which all RADIUS users belong?
This is a mechanism for selecting or creating a user group that can be used to configure settings that
apply to all RADIUS users - the All RADIUS Users virtual user will simply be added as a member of the
group. Note that other users can be added to or removed from this group, but the All RADIUS Users
user cannot be removed whilst the group is selected here.

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

SonicWALL PRO 3060 & PRO 4060 FAQ version 1.6

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.

You might also like