en-US
search-icon

SonicOS 6.2 Admin Guide

Network

Configuring Interfaces

Network > Interfaces

The Network > Interfaces page includes interface objects that are directly linked to physical interfaces. The SonicOS scheme of interface addressing works in conjunction with network zones and address objects.

NSA 2600 and Above Appliances

TZ Appliances

Topics:  

Show/Hide PortShield Interfaces

In IPv4 mode, you can show PortShield interfaces in the Interface Settings and Interface Traffic Statistics tables by clicking the Show PortShield Interfaces button in the upper right corner of the page. When you click the button, it becomes the Hide PortShield Interfaces button

To hide the PortShield interfaces, click the Hide PortShield Interfaces button.

Interface Settings

The Interface Settings table lists the following information for each interface:

Name - The name of the interface.
Zone - LAN, WAN, DMZ, and WLAN are listed by default. As zones are configured, the names are listed in this column.
Group - If the interface is assigned to a Load Balancing group, it is displayed in this column.
IP Address - IP address assigned to the interface.
Subnet Mask - The network mask assigned to the subnet.
IP Assignment - The available methods of IP assignment depend on which zone the interface is assigned to:
* 
NOTE: Wire Mode and Tap mode are available only on NSA 2600 and higher appliances.
LAN: Static, Transparent, Layer 2 Bridged Mode, Wire Mode, Tap mode, Portshield Switch Mode, IP Unnumbered Mode
WAN: Static, DHCP, PPPoE, PPTP, L2TP, Wire Mode, Tap mode
DMZ: Static, Transparent, Layer 2 Bridged Mode, Wire Mode, Tap mode, Portshield Switch Mode, IP Unnumbered Mode
WLAN: Static, Layer 2 Bridged Mode, Portshield Switch Mode
PortShield to Xn: If PortShield interfaces are configured, the PortShield assignment
Status - The link status and speed.
Enabled - Indicates ports that can be enabled/disabled through the Network > Interfaces page. Ports that are enabled are indicated by an Enabled icon, those that are disabled by a Disabled icon. Clicking on the icon displays a message verifying you want the port enabled/disabled. Click OK. The port is enabled/disabled and the icon changes.
* 
NOTE: This option is available only on NSA 2600 and above appliances.
Comment - Any user-defined comments.
Configure - Click the Edit icon to display the Edit Interface dialog, which allows you to configure the settings for the specified interface.

Interface Traffic Statistics

The Interface Traffic Statistics table lists, for each interface, received and transmitted information for all configured interfaces, including VLAN sub-interfaces:

Rx Unicast Packets - Indicates the number of point-to-point communications received by the interface.
Rx Broadcast Packets - Indicates the number of multipoint communications received by the interface.
RX Bytes - Indicates the volume of data, in bytes, received by the interface.
Tx Unicast Packets - Indicates the number of point-to-point communications transmitted by the interface.
Tx Broadcast Bytes - Indicates the number of mutlipoint communications received by the interface.
Tx Bytes - Indicates the volume of data, in bytes, transmitted by the interface.

To clear the current statistics, click the Clear button at the top right of the Network > Interfaces page.

Physical and Virtual Interfaces

Interfaces in SonicOS can be:

Physical interfaces – Physical interfaces are bound to a single port
Virtual interfaces – Virtual interfaces are assigned as subinterfaces to a physical interface and allow the physical interface to carry traffic assigned to multiple interfaces.

Physical Interfaces

The front panel of a SonicWall appliance has a number of physical interfaces. The number and type of interfaces depend on the model and version (for more information about the interfaces on your appliance, see the relevant Getting Started Guide):

 
1 GE – High-speed copper Gigabit Ethernet ports
1 GE SFP – 1 Gigabit Ethernet hot-pluggable SFP interfaces 1
10 GE SFP+ – 10 Gigabit Hot-pluggable ports a
MGMT – A 1 Gigabit Ethernet Management Interface port for secure firmware upgrading of the appliance in SafeMode. For more information about using the MGMT port for upgrading firmware in SafeMode, see the SonicOS 6.2 Upgrade Guide. The default IP address for the MGMT port is 192.168.1.254.

1
NSA 3600 Series and above and SuperMassive Series only

Physical interfaces must be assigned to a zone to allow for configuration of Access Rules to govern inbound and outbound traffic. Security zones are bound to each physical interface where it acts as a conduit for inbound and outbound traffic. If there is no interface, traffic cannot access the zone or exit the zone.

For more information on zones, see Network > Zones.

10 Gigabit Ethernet SFP+ Ports on NSA 6600 and SuperMassive 9000 Series

On NSA 6600 and the SuperMassive 9000 series appliances, the enhanced small form-factor pluggable (SFP+) ports, X16, X18, and X19 are designated with a dot to signify that they have a direct maximum throughput to the CPU. These dotted ports have a dedicated (non-shared) uplink to the CPU.

This is beneficial, for example, if you have a 10Gb corporate network backbone and you are using a SuperMassive 9200 as the gateway device for your department. You should connect one of the dotted ports (X16, X18, or X19) directly to the backbone. This provides the fastest access because these ports are direct connections from the CPU to anything connected to them. You do not want the connection to the backbone sharing bandwidth with users or any other devices on your network. For maximum speed and efficiency, a dotted port should be connected directly to the backbone.

As another example, business-critical and heavily multiplexed links should also be connected to a dotted interface. An example of a business-critical use case might involve an administrative unit connecting to a 10Gb backbone network. For maximum performance, the upstream backbone connection should connect via a dotted interface. This ensures that important backbone traffic will never be lost due to transient high load conditions on the other non-dotted interfaces that share a CPU uplink.

An example of a heavily multiplexed use case might involve a number of downstream enterprise switches that each have 10Gb uplinks. For maximum performance, each should be connected via a dotted interface. This ensures that differing high-level switching domains cannot starve each other of CPU resources.

10 Gigabit Ethernet hot-pluggable ports

The X17 interface is marked with an asterisk in the SonicOS management interface to indicate that it is connected to the common switching domain shared with ports X0 - X15, thereby allowing X17 to participate in SonicOS advanced switching features.

Virtual Interfaces (VLAN)

Supported on SonicWall security appliances, virtual Interfaces are subinterfaces assigned to a physical interface. Virtual interfaces allow you to have more than one interface on one physical connection.

Virtual interfaces provide many of the same features as physical interfaces, including zone assignment, DHCP Server, and NAT and Access Rule controls.

Virtual Local Area Networks (VLANs) can be described as a “tag-based LAN multiplexing technology” because through the use of IP header tagging, VLANs can simulate multiple LAN’s within a single physical LAN. Just as two physically distinct, disconnected LAN’s are wholly separate from one another, so too are two different VLANs; however, the two VLANs can exist on the very same wire. VLANs require VLAN aware networking devices to offer this kind of virtualization — switches, routers and firewalls that have the ability to recognize, process, remove and insert VLAN tags (IDs) in accordance with the network’s design and security policies.

VLANs are useful for a number of different reasons, most of which are predicated on the VLANs ability to provide logical rather than physical broadcast domain, or LAN boundaries. This works both to segment larger physical LAN’s into smaller virtual LAN’s, as well as to bring physically disparate LAN’s together into a logically contiguous virtual LAN. The benefits of this include:

Increased performance – Creating smaller, logically partitioned broadcast domains decreases overall network utilization, sending broadcasts only where they need to be sent, thus leaving more available bandwidth for application traffic.
Decreased costs – Historically, broadcast segmentation was performed with routers, requiring additional hardware and configuration. With VLANs, the functional role of the router is reversed – rather than being used for the purposes of inhibiting communications, it is used to facilitate communications between separate VLANs as needed.
Virtual workgroups – Workgroups are logical units that commonly share information, such as a Marketing department or an Engineering department. For reasons of efficiency, broadcast domain boundaries should be created such that they align with these functional workgroups, but that is not always possible: Engineering and Marketing users might be commingled, sharing the same floor (and the same workgroup switch) in a building, or just the opposite – the Engineering team might be spread across an entire campus. Attempting to solve this with complex feats of wiring can be expensive and impossible to maintain with constant adds and moves. VLANs allow for switches to be quickly reconfigured so that logical network alignment can remain consistent with workgroup requirements.
Security – Hosts on one VLAN cannot communicate with hosts on another VLAN unless some networking device facilitates communication between them.

Subinterfaces

VLAN support on SonicOS is achieved by means of subinterfaces, which are logical interfaces nested beneath a physical interface. Every unique (tag) requires its own subinterface. For reasons of security and control, SonicOS does not participate in any VLAN trunking protocols, but instead requires that each VLAN that is to be supported be configured and assigned appropriate security characteristics.

* 
NOTE: VLAN IDs range from 0 – 4094, with these restrictions: VLAN 0 is reserved for QoS and VLAN 1 is reserved by some switches for native VLAN designation.
* 
NOTE: Dynamic VLAN Trunking protocols, such as VTP (VLAN Trunking Protocol) or GVRP (Generic VLAN Registration Protocol), should not be used on trunk links from other devices connected to the firewall.

Trunk links from VLAN capable switches are supported by declaring the relevant VLAN ID’s as a subinterface on the firewall, and configuring them in much the same way that a physical interface would be configured. In other words, only those VLANs which are defined as subinterfaces will be handled by the firewall, the rest will be discarded as uninteresting. This method also allows the parent physical interface on the firewall to which a trunk link is connected to operate as a conventional interface, providing support for any native (untagged) VLAN traffic that might also exist on the same link. Alternatively, the parent interface may remain in an ‘unassigned’ state.

VLAN subinterfaces have most of the capabilities and characteristics of a physical interface, including zone assignability, security services, GroupVPN, DHCP server, IP Helper, routing, and full NAT policy and Access Rule controls. Multicast support is excluded from VLAN subinterfaces at this time.

SonicOS Secure Objects

The SonicOS scheme of interface addressing works in conjunction with network zones and address objects. This structure is based on secure objects, which are utilized by rules and policies within SonicOS.

Secured objects include interface objects that are directly linked to physical interfaces and managed in the Network > Interfaces page. Address objects are defined in the Network > Address Objects page. Service and Scheduling objects are defined in the Firewall section of the user interface, and User objects are defined in the Users section.

Zones are the hierarchical apex of SonicOS’s secure objects architecture. SonicOS includes predefined zones as well as allow you to define your own zones. Predefined zones include LAN, DMZ, WAN, WLAN, and Custom. Zones can include multiple interfaces; the WAN zone, however, is restricted to a maximum of the total number of interfaces minus one. Within the WAN zone, either one or more WAN interfaces can be actively passing traffic depending on the WAN Failover and Load Balancing configuration on the Network > WAN Failover & LB page.

For more information on WAN Failover and Load Balancing on the SonicWall Security Appliance, see Network > Failover & LB.

At the zone configuration level, the Allow Interface Trust setting for zones automates the processes involved in creating a permissive intra-zone Access Rule. It creates a comprehensive Address Object for the entire zone and a inclusively permissive Access Rule from zone address to zone addresses.

Transparent Mode

Transparent Mode in SonicOS uses interfaces is the top level of the management hierarchy. Transparent Mode supports unique addressing and interface routing.

IPS Sniffer Mode

Supported on SonicWall Security Appliances, IPS Sniffer Mode is a variation of Layer 2 Bridged Mode that is used for intrusion detection. IPS Sniffer Mode configuration allows an interface on the firewall to be connected to a mirrored port on a switch to examine network traffic. Typically, this configuration is used with a switch inside the main gateway to monitor traffic on the intranet.

In IPS Sniffer Mode: Network diagram, traffic flows into a switch in the local network and is mirrored through a switch mirror port into a IPS Sniffer Mode interface on the SonicWall Security Appliance. The firewall inspects the packets according to the settings configured on the Bridge-Pair. Alerts can trigger SNMP traps which are sent to the specified SNMP manager via another interface on the firewall. The network traffic is discarded after the firewall inspects it.

The WAN interface of the firewall is used to connect to the firewall Data Center for signature updates or other data.

IPS Sniffer Mode: Network diagram

In IPS Sniffer Mode, a Layer 2 Bridge is configured between two interfaces in the same zone on the firewall, such as LAN-LAN or DMZ-DMZ. You can also create a custom zone to use for the Layer 2 Bridge. Only the WAN zone is not appropriate for IPS Sniffer Mode.

The reason for this is that SonicOS detects all signatures on traffic within the same zone such as LAN-LAN traffic, but some directional specific (client-side versus server-side) signatures do not apply to some LAN-WAN cases.

Either interface of the Layer 2 Bridge can be connected to the mirrored port on the switch. As network traffic traverses the switch, the traffic is also sent to the mirrored port and from there into the firewall for deep packet inspection. Malicious events trigger alerts and log entries, and if SNMP is enabled, SNMP traps are sent to the configured IP address of the SNMP manager system. The traffic does not actually continue to the other interface of the Layer 2 Bridge. IPS Sniffer Mode does not place the firewall inline with the network traffic, it only provides a way to inspect the traffic.

The Edit Interfaces dialog available from the Network > Interfaces page provides a checkbox called Only sniff traffic on this bridge-pair for use when configuring IPS Sniffer Mode. When selected, this checkbox causes the firewall to inspect all packets that arrive on the L2 Bridge from the mirrored switch port. The Never route traffic on this bridge-pair checkbox should also be selected for IPS Sniffer Mode to ensure that the traffic from the mirrored switch port is not sent back out onto the network.

For detailed instructions on configuring interfaces in IPS Sniffer Mode, see Configuring IPS Sniffer Mode.

Sample IPS Sniffer Mode Topology

This example topology uses SonicWall IPS Sniffer Mode in a Hewlett Packard ProCurve switching environment. This scenario relies on the ability of HP’s ProCurve Manager Plus (PCM+) and HP Network Immunity Manager (NIM) server software packages to throttle or close ports from which threats are emanating.

This method is useful in networks where there is an existing firewall that remains in place, but you wish to use the firewall’s security services as a sensor.

IPS Sniffer Mode: Sample topology

In this deployment the WAN interface and zone are configured for the internal network’s addressing scheme and attached to the internal network. The X2 port is Layer 2 bridged to the LAN port, but it won’t be attached to anything. The X0 LAN port is configured to a second, specially programmed port on the HP ProCurve switch. This special port is set for mirror mode: it will forward all the internal user and server ports to the “sniff” port on the firewall. This allows the firewall to analyze the entire internal network’s traffic, and if any traffic triggers the security signatures it will immediately trap out to the PCM+/NIM server via the X1 WAN interface, which then can take action on the specific port from which the threat is emanating.

To configure this deployment:
1
Navigate to the Network > Interfaces page.
2
Click on the Edit icon for the X2 interface. The Edit Interface dialog displays.

3
Set the Mode / IP Assignment to Layer 2 Bridged Mode. The options change.

4
Set the Bridged To: interface to X0.
5
Select the checkbox for Only sniff traffic on the bridge-pair.
6
Click OK to save and activate the change. The dialog closes, and the Network > Interfaces page redisplays.
7
Click the Edit icon for the X1 WAN interface. The Edit Interface dialog displays.
8
Assign the X1 WAN interface a unique IP address for the internal LAN segment of your network — this may sound wrong, but this is actually be the interface from which you manage the appliance, and it is also the interface from which the appliance sends its SNMP traps as well as the interface from which it gets security services signature updates.
9
Click OK.
10
For traffic to pass successfully, you must also modify the firewall rules to allow traffic from the
LAN to WAN,
WAN to the LAN
11
Connect the:
Span/mirror switch port to X0 on the firewall, not to X2 (in fact, X2 isn’t plugged in at all)
X1 to the internal network
* 
IMPORTANT: Use care when programming ports spanned/mirrored to X0.
* 
VIDEO: Informational videos with interface configuration examples are available online. For example, see How to configure the SonicWall WAN / X1 Interface with PPPoE Connection. Additional videos are available at: https://support.sonicwall.com/videos-product-select.

Firewall Sandwich

Starting with SonicOS 6.2.5.1, you can deploy and configure a SonicWall Firewall Sandwich to improve availability, scalability, and manageability across the IT infrastructure. Deployment of the Firewall Sandwich provides the following features:

Scalability - add more capacity as you go, reusing existing equipment
Redundancy and resiliency – primary and secondary components
Inline upgrades – upgrade firewalls and switches without shutting down the system
Single point of management - manage policies for multiple firewall clusters and blades
Full security services - including DPI-SSL capability

Firewall Sandwich deployment and configuration can be implemented using the following supported equipment and services:

Dell Force10 S series switches, such as the S5000, S4810, S4048, or S6000 running FTOS v9.8+
SonicWall NSA 2600 and higher appliances or SuperMassive series appliances.
SonicWall services, such as GAV, IPS, ASPR, DPI-SSL, and CFS in conjunction with Single Sign-On All in Wire Mode.

For more information about Firewall Sandwich and how to deploy and configure it, see the SonicWall Firewall Sandwich Deployment Guide.

HTTP/HTTPS Redirection

When the firewall configuration requires user authentication, HTTP/HTTPS traffic from an unauthenticated source is redirected to the SonicOS login screen for the user to enter their credentials. A problem occurs when HTTP and HTTPS traffic arrive from sources from which users do not log in, and one or more such sources repeatedly try to open new connections, which keeps triggering this redirection. These could be non-user devices that are validly trying to get access or could be malicious code attempting a Denial of Service (DOS) attack. The effect that it has on the firewall is to cause high CPU load in the CP, both in the data plane task initiating the redirections and in the web server thread tasks that are serving up the target redirect pages.

To minimize this effect, ensure the Add rule to enable redirect from HTTP to HTTPS checkbox is selected when adding or editing an interface. Enabling this checkbox causes SonicOS to add an access rule that allows HTTP to the interface; a side effect of this rule is that it also allows SonicOS to be able to redirect HTTPS to HTTP in certain cases without security issues. One such case is the first step of redirecting traffic that needs to be authenticated, at which point there is no sensitive data that needs to be hidden. Then HTTP processing can occur on the data plane (DP) rather than on the CP.

* 
NOTE: This option is not available when adding or editing VPN tunnel interfaces or when Wire Mode (2-Port Wire), Tap Mode (1-Port Tap), or PortShield Switch Mode is selected for Mode/IP Assignment.

Configuring Interfaces

Topics:  

Configuring a Static Interface

For general information on interfaces, see Physical and Virtual Interfaces.

Static means that you assign a fixed IP address to the interface.

To configure a static interface:
1
Click on the Edit icon in the Configure column for the interface you want to configure. The Edit Interface dialog displays.

2
Select a zone to assign to the interface from the Zone drop-down menu:
LAN
WAN
DMZ
LAN
Custom zone you’ve created
Create new zone. The Add Zone dialog is displayed. See Network > Zones for instructions on adding a zone.
* 
NOTE: The options displayed change, depending on the Zone you select.
3
Select Static (WAN) or Static IP Mode (LAN) from the Mode / IP Assignment drop-down menu. This is the default mode.
4
Enter the IP address and subnet mask for the interface into the IP Address and Subnet Mask fields.
* 
NOTE: You cannot enter an IP address that is in the same subnet as another zone.
5
If configuring a WAN zone interface or the MGMT interface, type the IP address of the gateway device into the Default Gateway (Optional) field. The gateway device provides access between this interface and the external network, whether it is the Internet or a private network. A gateway is optional for DMZ or LAN zone interfaces.
* 
NOTE: A default gateway IP is required on the WAN interface if any destination is required to be reached via the WAN interface that is not part of the WAN subnet IP address space, regardless whether a default route is received dynamically from a routing protocol of a peer device on the WAN subnet.
6
If configuring a WAN zone interface, enter the IP addresses of up to three DNS servers into the DNS Server fields. These can be public or private DNS servers. For more information, see Configuring a WAN Interface.
7
Enter any optional comment text in the Comment field. This text is displayed in the Comment column of the Interface table.
8
If you want to enable remote management of the firewall from this interface, select the supported Management protocol(s): HTTPS, Ping, SNMP, and/or SSH.

To allow access to the WAN interface for management from another zone on the same appliance, access rules must be created. See Allowing WAN Primary IP Access from the LAN Zone for more information.

9
If you want to allow selected users with limited management rights to log in to the security appliance, select HTTP and/or HTTPS in User Login.
10
Click OK.
* 
NOTE: The administrator password is required to regenerate encryption keys after changing the firewall’s address.
Configuring Advanced Settings for a Static Interface
To configure advanced settings for a static interface.
1
In the Edit Interface dialog, click the Advanced tab.
* 
NOTE: The options available on the Advanced tab for a static interface vary depending on the selected zone.

2
For Link Speed, Auto Negotiate is selected by default, which causes the connected devices to negotiate the speed and duplex mode of the Ethernet connection automatically. To force Ethernet speed and duplex, select one of the following options from the Link Speed drop-down menu:

For 1 Gbps interfaces

For 10 Gbps interfaces

1 Gbps - Full Duplex

10 Gbps - Full Duplex

100 Mbps - Full Duplex

 

100 Mbps - Half Duplex

 

10 Mbps - Full Duplex

 

10 Mbps - Half Duplex

 

* 
CAUTION: If you select a specific Ethernet speed and duplex, you must force the connection speed and duplex from the Ethernet card to the firewall as well.
3
Use Default MAC Address is selected by default. You can choose to override the Use Default MAC Address for the Interface by selecting Override Default MAC Address and entering the MAC address in the field.
4
Select the Shutdown Port checkbox to temporarily take this interface offline for maintenance or other reasons. If connected, the link will go down.

Clear the checkbox to activate the interface and allow the link to come back up. This option is not selected by default.

* 
NOTE: This option is available only on the NSA 2600 and above appliances.
* 
NOTE: You cannot shut down the management interface or the interface you’re currently using.

If you select this option, a confirmation message is displayed:

Click OK to shut down the port.

TIP: You can shut down the interface by clicking the Enabled icon in the Enabled column for the interface. A confirmation message displays:

If you click OK, the Enabled icon turns to a Disabled icon. To enable the interface, click the Disabled icon. A confirmation message displays:

If you click OK, the Disabled icon turns to an Enabled icon.

5
For the AppFlow feature, select the Enable flow reporting checkbox to allow flow reporting on flows created for this interface. This option is selected by default.
6
Optionally, select the Enable Multicast Support checkbox to allow multicast reception on this interface. This option is not selected by default.
7
Optionally, select the Enable Default 802.1p CoS checkbox to tag information passing through this interface with 802.1p priority information for Quality of Service (QoS) management. This option is not selected by default.
* 
NOTE: This option is available only for VLAN interfaces.

Packets sent through this interface are tagged with VLAN id=0 and carry 802.1p priority information. To make use of this priority information, devices connected to this interface should support priority frames. QoS management is controlled by access rules on the Firewall > Access Rules page. For information on QoS and bandwidth management, see Firewall Settings > QoS Mapping.

8
Optionally, to exclude the interface from Route Advertisement, select the Exclude from Route Advertisement (NSM, OSPF, BGP, RIP) checkbox. This option is not selected by default.
9
Optionally, select Management Traffic Only to restrict traffic to only SonicWall management traffic and routing protocols. This option is not selected by default.
* 
NOTE: Only TZ series and SOHO W appliances have this option.
10
Optionally, if you have enabled DNS Proxy, the Enable DNS Proxy option for displays for LAN, DMZ, or WLAN interfaces:

To enable DNS Proxy on the interface, click the option’s checkbox.

11
Optionally, enable Asymmetric Route Support on the interface by selecting the Enable Asymmetric Route Support checkbox. If enabled, the traffic initialized from this interface supports asymmetric routes, that is, the initial packet or response packet can pass through from other interfaces. This checkbox is not selected by default. For more information about asymmetric routing, see Asymmetric Routing In Cluster Configurations.
12
Optionally select Link Aggregation or Port Redundancy from the Redundant /Aggregate Ports drop-down menu. For more information see Configuring Link Aggregation and Port Redundancy.
* 
NOTE: This option is available only on NSA 2600 and higher appliances.
13
Optionally select the Use Routed Mode – Add NAT Policy to prevent outbound/inbound translation checkbox. For more information about Routed Mode, see Configuring Routed Mode.
* 
NOTE: This option is not available for WAN interfaces.
14
To specify the largest packet size (MTU – maximum transmission unit) that the interface can forward without fragmenting the packet, enter the size of the packets that the port will receive and transmit in the Interface MTU field:
 

Standard packets (default)

1500

Jumbo frame packets

9000

* 
NOTE: Jumbo frame support must be enabled before a port can process jumbo frames, as explained in Jumbo Frame. Due to jumbo frame packet buffer size requirements, jumbo frames increase memory requirements by a factor of 4.

Jumbo frames are supported on NSA 3600 and higher appliances.

15
Optionally, enable Bandwidth Management for this interface. For more information about Bandwidth Management, see Enabling Bandwidth Management.
a
To limit outgoing traffic to a maximum bandwidth on the interface, select the Enable Interface Egress Bandwidth Limitation checkbox. This option is not selected by default.
Specify the maximum bandwidth, in kbps, in the Maximum Interface Egress Bandwidth field. The default is 384.000000 kbps.
b
To limit incoming traffic to a maximum bandwidth on the interface, select the Enable Interface Ingress Bandwidth Limitation checkbox. This option is not selected by default.
Specify the maximum bandwidth, in kbps, in the Maximum Interface Egress Bandwidth field. The default is 384.000000 kbps.

Configuring Routed Mode

Routed Mode provides an alternative for NAT for routing traffic between separate public IP address ranges. Consider the topology in Routed mode configuration, where the firewall is routing traffic across two public IP address ranges:

10.50.26.0/24
172.16.6.0/24

Routed mode configuration

By enabling Routed Mode on the interface for the 172.16.6.0 network, NAT translations will be automatically disabled for the interface, and all inbound and outbound traffic will be routed to the WAN interface configured for the 10.50.26.0 network.

* 
NOTE: Routed Mode is available when using Static IP Mode for interfaces in the LAN, DMZ, and WLAN zones. For DMZ, it is also available when using Layer 2 Bridged Mode.
To configure Routed Mode:
1
Navigate to the Network > Interfaces page.
2
Click on the Configure icon for the appropriate interface. The Edit Interface dialog displays.
3
Click on the Advanced tab.

4
Under the Expert Mode Settings heading, select the Use Routed Mode - Add NAT Policy to prevent outbound\inbound translation checkbox to enable Routed Mode for the interface. This option is not selected by default. When you select it, the other two Expert Mode settings become available.
5
In the NAT Policy outbound/inbound interface drop-down menu, select the WAN interface that is to be used to route traffic for the interface. The default is Any.
6
Optionally, specify the interface MTU in the Interface MTU field. The default is 1500.
7
Click OK.

The firewall creates “no-NAT” policies for both the configured interface and the selected WAN interface. These policies override any more general M21 NAT policies that may be configured for the interfaces.

Enabling Bandwidth Management

Bandwidth Management (BWM) allows you to guarantee minimum bandwidth and prioritize traffic. BWM is enabled in the Firewall Settings > BWM page. By controlling the amount of bandwidth to an application or user, you can prevent a small number of applications or users from consuming all available bandwidth. Balancing the bandwidth allocated to different network traffic and then assigning priorities to traffic improves network performance.

Various types of bandwidth management can be enabled on the Firewall > BWM page:

Advanced—Enables you to configure maximum egress and ingress bandwidth limitations per interface, by configuring bandwidth objects, access rules, and application policies.
Global—Allows you to enable BWM settings globally and apply them to any interfaces.
None (default)—Disables BWM.

For information on configuring bandwidth management and the effect of the various BWM types, see Firewall Settings > BWM.

SonicOS can apply bandwidth management to both egress (outbound) and ingress (inbound) traffic on any interfaces. Outbound bandwidth management is done using Class Based Queuing. Inbound Bandwidth Management is done by implementing an ACK delay algorithm that uses TCP’s intrinsic behavior to control the traffic.

Class Based Queuing (CBQ) provides guaranteed and maximum bandwidth Quality of Service (QoS) for the firewall. Every packet destined to the interface is queued in the corresponding priority queue. The scheduler then dequeues the packets and transmits them on the link depending on the guaranteed bandwidth for the flow and the available link bandwidth.

Enabling BWM
To enable or disable ingress and egress BWM:
1
Click the Edit icon of an interface. The Add/Edit Interface dialog displays.
2
Click the Advanced tab.

* 
NOTE: Advanced Settings may differ, depending on the firewall model.
3
Scroll to the Bandwidth Management section.

4
Select the Enable Interface Egress Bandwidth Limitation option. This option is not selected by default.

When this option is:

Selected, the maximum available egress BWM is defined, but as advanced BWM is policy based, the limitation is not enforced unless there is a corresponding Access Rule or App Rule.
Not selected, no bandwidth limitation is set at the interface level, but egress traffic can still be shaped using other options.
a
In the Maximum Interface Egress Bandwidth (kbps) field, enter the maximum egress bandwidth for the interface (in kilobytes per second). The default is 384.000000 Kbps.
5
Select the Enable Interface Ingress Bandwidth Limitation option. This option is not selected by default. This option is not selected by default. For information on using this option, see Step 4.
6
Click OK.

Configuring Interfaces in Transparent IP Mode (Splice L3 Subnet)

Transparent IP Mode enables the SonicWall Security Appliance to bridge the WAN subnet onto an internal interface.

To configure an interface for transparent mode:
1
Click on the Configure icon in the Configure column for Unassigned Interface you want to configure. The Edit Interface dialog is displayed.
2
Select an interface.
If you select a configurable interface, select LAN or DMZ for Zone.
* 
NOTE: The options available change according to the type of zone you select.
If you want to create a new zone for the configurable interface, select Create a new zone. The Add Zone window is displayed. See Network > Zones for instructions on adding a zone.
3
Select Transparent IP Mode (Splice L3 Subnet) from the IP Assignment menu.
4
From the Transparent Range menu, select an address object that contains the range of IP addresses you want to have access through this interface. The address range must be within an internal zone, such as LAN, DMZ, or another trusted zone matching the zone used for the internal transparent interface. If you do not have an address object configured that meets your needs:
a
In the Transparent Range menu, select Create New Address Object.
b
In the Add Address Object field, enter a name for the address range.
c
For Zone Assignment, select an internal zone, such as LAN, DMZ, or another trusted zone. The range must not include the LAN interface (X0) IP address.
d
For Type, select:
Host if you want only one network device to connect to this interface.
Range to specify a range of IP addresses by entering beginning and ending value of the range.
Network to specify a subnet by entering the beginning value and the subnet mask. The subnet must be within the WAN address range and cannot include the WAN interface IP address.
e
Enter the IP address of the host, the beginning and ending address of the range, or the IP address and subnet mask of the network.
f
Click OK to create the address object and return to the Edit Interface dialog.

See Network > Address Objects for more information.

5
Enter any optional comment text in the Comment field. This text is displayed in the Comment column of the Interface table.
6
If you want to enable remote management of the firewall from this interface, select the supported management protocol(s): HTTPS, Ping, SNMP, and/or SSH.

To allow access to the WAN interface for management from another zone on the same appliance, access rules must be created. See Allowing WAN Primary IP Access from the LAN Zone for more information.

7
If you want to allow selected users with limited management rights to log directly into the security appliance through this interface, select HTTP and/or HTTPS in User Login.
8
Click OK.
* 
NOTE: The administrator password is required to regenerate encryption keys after changing the firewall’s address.
Configuring Advanced Settings for a Transparent IP Mode Interface
To configure advanced settings for a transparent IP mode interface:
1
In the Edit Interface dialog, click the Advanced tab.
2
For Link Speed, Auto Negotiate is selected by default, which causes the connected devices to automatically negotiate the speed and duplex mode of the Ethernet connection. If you want to specify the forced Ethernet speed and duplex, select one of the following options from the Link Speed menu:
For 1 Gbps interfaces, select:
1 Gbps - Full Duplex
100 Mbps - Full Duplex
100 Mbps - Half Duplex
10 Mbps - Full Duplex
10 Mbps - Half Duplex
For 10 Gbps interfaces, the only selection is 10 Gbps - Full Duplex.
* 
CAUTION: If you select a specific Ethernet speed and duplex, you must force the connection speed and duplex from the Ethernet card to the firewall as well.
3
You can choose to override the Use Default MAC Address for the Interface by selecting Override Default MAC Address and entering the MAC address in the field.
4
Select the Shutdown Port checkbox to temporarily take this interface offline for maintenance or other reasons. If connected, the link will go down. Clear the checkbox to activate the interface and allow the link to come back up.
5
For the AppFlow feature, select the Enable flow reporting checkbox to allow flow reporting on flows created for this interface.
6
Select the Enable Multicast Support checkbox to allow multicast reception on this interface.
7
Select the Enable 802.1p tagging checkbox to tag information passing through this interface with 802.1p priority information for Quality of Service (QoS) management. Packets sent through this interface are tagged with VLAN id=0 and carry 802.1p priority information. In order to make use of this priority information, devices connected to this interface should support priority frames. QoS management is controlled by access rules on the Firewall > Access Rules page. For information on QoS and bandwidth management, see Firewall Settings > QoS Mapping.
8
Optionally select Link Aggregation or Port Redundancy from the Redundant /Aggregate Ports drop-down list. For more information see Configuring Link Aggregation and Port Redundancy.
9
Select the Enable Gratuitous ARP Forwarding Towards WAN checkbox to forward gratuitous ARP packets received on this interface towards the WAN, using the hardware MAC address of the WAN interface as the source MAC address.
10
Select the Enable Automatic Gratuitous ARP Generation Towards WAN checkbox to automatically send gratuitous ARP packets towards the WAN whenever a new entry is added to the ARP table for a new machine on this interface. The hardware MAC address of the WAN interface is used as the source MAC address of the ARP packet.
11
Optionally enable Bandwidth Management for this interface. For more information about Bandwidth Management, see Enabling Bandwidth Management.

Configuring Wireless Interfaces

* 
NOTE: The SuperMassive 9800 does not support SonicPoints.

A Wireless interface is an interface that has been assigned to a Wireless zone and is used to support SonicWall SonicPoint secure access points.

* 
NOTE: SonicPoints can only be provisioned and managed on the interfaces of security type wireless (WLAN by default).
1
Click on the Edit icon in the Configure column for the Interface you want to configure. The Edit Interface dialog displays.
2
From the Zone drop-down menu, select WLAN or a previously defined custom Wireless zone.
3
For Mode / IP Assignment, select Static IP Mode. You can also select Layer 2 Bridged Mode; see Layer 2 Bridged Mode for more information.
4
Enter the IP address and subnet mask of the zone in the IP Address and Subnet Mask fields.
* 
NOTE: The upper limit of the subnet mask is determined by the number of SonicPoints you select in the SonicPoint Limit field. If you are configuring several interfaces or subinterfaces as Wireless interfaces, you may want to use a smaller subnet (higher) to limit the number of potential DHCP leases available on the interface. Otherwise, if you use a class C subnet (a subnet mask of 255.255.255.0) for each Wireless interface, you may exceed the limit of DHCP leases available on the security appliance.
5
In the SonicPoint Limit field, select the maximum number of SonicPoints allowed on this interface.
This value determines the highest subnet mask you can enter in the Subnet Mask field. The following table shows the subnet mask limit for each SonicPoint Limit selection and the number of DHCP leases available on the interface if you enter the maximum allowed subnet mask.
Available Client IPs assumes 1 IP for the firewall gateway interface, in addition to the presence of the maximum number of SonicPoints allowed on this interface, each consuming an IP address.
 

Maximum subnet mask sizes allowed

SonicPoints per Interface

Maximum Subnet Mask

Total Usable IP addresses

Available Client IPs

No SonicPoints

30 bits – 255.255.255.252

2

2

2 SonicPoints

29 bits – 255.255.255.248

6

3

4 SonicPoints

29 bits – 255.255.255.248

6

1

8 SonicPoints

28 bits – 255.255.255.240

14

5

16 SonicPoints

27 bits – 255.255.255.224

30

13

32 SonicPoints

26 bits – 255.255.255.192

62

29

48 SonicPoints

25 bits - 255.255.255.128

126

77

64 SonicPoints

25 bits - 255.255.255.128

126

61

96 SonicPoints

24 bits - 255.255.255.0

190

93

128 SonicPoints

23 bits - 255.255.254.0

254

125

* 
NOTE: Maximum subnet mask sizes allowed depicts the maximum subnet mask sizes allowed. You can still use classful subnetting (class A, class B, or class C) or any variable-length subnet mask that you wish on WLAN interfaces. You are encouraged to use a smaller subnet mask (for example, 24-bit class C: 255.255.255.0 - 254 total usable IPs), thus allocating more IP addressing space to clients if you have the need to support larger numbers of wireless clients.
6
Enter any optional comment text in the Comment field. This text is displayed in the Comment column of the Interface table.
7
If you want to enable remote management of the firewall from this interface, select the supported management protocol(s): HTTPS, Ping, SNMP, and/or SSH.

To allow access to the WAN interface for management from another zone on the same appliance, access rules must be created. See Allowing WAN Primary IP Access from the LAN Zone for more information.

8
If you want to allow selected users with limited management rights to log in to the security appliance, select HTTP and/or HTTPS in User Login.
9
Click OK.
Configuring Advanced Settings for a Wireless Interface
* 
NOTE: The SuperMassive 9800 does not support SonicPoints.
To configure advanced settings for a wireless interface:
1
In the Edit Interface dialog, click the Advanced tab.
2
For Link Speed, Auto Negotiate is selected by default, which causes the connected devices to automatically negotiate the speed and duplex mode of the Ethernet connection. If you want to specify the forced Ethernet speed and duplex, select one of the following options from the Link Speed menu:
For 1 Gbps interfaces, select:
1 Gbps - Full Duplex
100 Mbps - Full Duplex
100 Mbps - Half Duplex
10 Mbps - Full Duplex
10 Mbps - Half Duplex
For 10 Gbps interfaces, the only selection is 10 Gbps - Full Duplex.
* 
CAUTION: If you select a specific Ethernet speed and duplex, you must force the connection speed and duplex from the Ethernet card to the firewall as well.
3
You can choose to override the Use Default MAC Address for the Interface by selecting Override Default MAC Address and entering the MAC address in the field.
4
Select the Shutdown Port checkbox to temporarily take this interface offline for maintenance or other reasons. If connected, the link will go down. Clear the checkbox to activate the interface and allow the link to come back up.
5
For the AppFlow feature, select the Enable flow reporting checkbox to allow flow reporting on flows created for this interface.
6
Select the Enable Multicast Support checkbox to allow multicast reception on this interface.
7
Select the Enable 802.1p tagging checkbox to tag information passing through this interface with 802.1p priority information for Quality of Service (QoS) management. Packets sent through this interface are tagged with VLAN id=0 and carry 802.1p priority information. To make use of this priority information, devices connected to this interface should support priority frames. QoS management is controlled by access rules on the Firewall > Access Rules page. For information on QoS and bandwidth management, see Firewall Settings > QoS Mapping.
8
Optionally select Link Aggregation or Port Redundancy from the Redundant /Aggregate Ports drop-down list. For more information see Configuring Link Aggregation and Port Redundancy.
9
Optionally select the Use Routed Mode checkbox. For more information about Routed Mode, see Configuring Routed Mode.
10
Optionally enable Bandwidth Management for this interface. For more information about Bandwidth Management, see Enabling Bandwidth Management.

Configuring a WAN Interface

* 
NOTE: A default gateway IP is required on the WAN interface if any destination is required to be reached via the WAN interface that is not part of the WAN subnet IP address space, regardless whether we receive a default route dynamically from a routing protocol of a peer device on the WAN subnet.
* 
NOTE: PPTP, L2TP, and PPPoE are not supported on the SuperMassive 9800.

Configuring a WAN interface enables Internet connectivity. You can configure up to N minus 2 WAN interfaces on the SonicWall Security Appliance, where N is the number of interfaces defined on the unit (both physical and VLAN). Only the X0 and MGMT interfaces cannot be configured as WAN interfaces.

To configure your WAN interface on the General tab of the Edit Interface dialog:
1
Click on the Edit icon in the Configure column for the Interface you want to configure. The Edit Interface dialog displays.
2
If you’re configuring an Unassigned Interface, select WAN from the Zone menu. If you selected the Default WAN Interface, WAN is already selected in the Zone menu.
3
Select one of the following WAN Network Addressing Modes from the IP Assignment drop-down menu.
* 
NOTE: Depending on the option you choose from the IP Assignment drop-down menu, the options available change. Complete the corresponding fields that are displayed after selecting the option.
* 
NOTE: PPTP, L2TP, and PPPoE are not supported on the SuperMassive 9800.
Static - configures the firewall for a network that uses static IP addresses.
DHCP - configures the firewall to request IP settings from a DHCP server on the Internet. NAT with DHCP Client is a typical network addressing mode for cable and DSL customers.
PPPoE - uses Point to Point Protocol over Ethernet (PPPoE) to connect to the Internet. If a username and password is required by your ISP, enter them into the User Name and User Password fields. This protocol is typically found when using a DSL modem.
PPTP - uses PPTP (Point to Point Tunneling Protocol) to connect to a remote server. It supports older Microsoft Windows implementations requiring tunneling connectivity.
L2TP - uses IPsec to connect a L2TP (Layer 2 Tunneling Protocol) server and encrypts all data transmitted from the client to the server. However, it does not encrypt network traffic to other destinations.
Wire Mode (2-Port Wire) - allows insertion of the firewall into a network, in Bypass, Inspect, or Secure mode. For detailed information, see Configuring Wire and Tap Mode.
Tap Mode (1-Port Tap) - allows insertion of the firewall into a network for use with network taps, port mirrors, or SPAN ports. For detailed information, see Configuring Wire and Tap Mode.
4
If using DHCP, optionally enter a descriptive name in the Host Name field and any desired comments in the Comment field.
5
If using PPPoE, PPTP, or L2TP, additional fields display:
* 
NOTE: PPTP, L2TP, and PPPoE are not supported on the SuperMassive 9800.
If Schedule is displayed, select the desired schedule from the drop-down list during which this interface should be connected.
In User Name and User Password, type in the account name and password provided by your ISP.
If the Server IP Address field is displayed, enter the server IP address provided by your ISP.
If the (Client) Host Name field is displayed, enter the host name of the appliance. This is the Firewall Name from the System > Administration page.
If the Shared Secret field is displayed, enter the value provided by your ISP.
6
If you want to enable remote management of the firewall from this interface, select the supported management protocol(s): HTTPS, Ping, SNMP, and/or SSH.

To allow access to the WAN interface for management from another zone on the same appliance, access rules must be created. See Allowing WAN Primary IP Access from the LAN Zone for more information.

7
If using PPPoE, PPTP, or L2TP, additional fields display:
* 
NOTE: PPTP, L2TP, and PPPoE are not supported on the SuperMassive 9800.
For PPPoE, select one of the following radio buttons:
Select Obtain IP Address Automatically to get the IP address from the PPPoE server.
Select Specify IP Address and enter the desired IP address into the field to use a static IP address for this interface.
Select Unnumbered interface and either:
Choose an unnumbered interface from the drop-down menu.
Create a new unnumbered interface by selecting Create new Unnumbered Interface.
* 
NOTE: The interface must be unassigned.
For PPTP or L2TP, configure the following options:
Select the Inactivity Disconnect checkbox and enter the number of minutes of inactivity after which the connection will be terminated. Clear this checkbox to disable inactivity timeouts.
From the IP Assignment drop-down menu, select either:
DHCP; the IP Address, Subnet Mask, and Gateway Address fields are automatically provisioned by the server.
Static, enter the appropriate values for these fields.
8
If using DHCP, optionally select the following checkboxes:
Request renew of previous IP on startup to request the same IP address for the WAN interface that was previously provided by the DHCP server.
Renew DHCP lease on any link up occurrence to send a lease renewal request to the DHCP server every time this WAN interface reconnects after being disconnected.

The fields displayed below these options are provisioned by the DHCP server. After provisioning, the Renew, Release, and Refresh buttons are available; click:

Renew to restart the DHCP lease duration for the currently assigned IP address.
Release to cancel the DHCP lease for the current IP address. The connection will be dropped. You need to obtain a new IP address from the DHCP server to reestablish connectivity.
Refresh to obtain a new IP address from the DHCP server.
9
If you want to allow selected users with limited management rights to log directly into the security appliance from this interface, select HTTP and/or HTTPS in User Login.
10
Check Add rule to enable redirect from HTTP to HTTPS, if you want an HTTP connection automatically redirected to a secure HTTPS connection to the firewall. For more information about this option, see HTTP/HTTPS Redirection.
11
Continue the configuration on the Advanced and Protocol tabs (if displayed) as described in Configuring Advanced Settings for a WAN Interface.
12
After completing the WAN configuration for your Network Addressing Mode, click OK.
Configuring Advanced Settings for a WAN Interface
To configure advanced settings for a WAN interface:
1
In the Edit Interface dialog, click the Advanced tab.
2
For Link Speed, Auto Negotiate is selected by default, which causes the connected devices to automatically negotiate the speed and duplex mode of the Ethernet connection. If you want to specify the forced Ethernet speed and duplex, select one of the following options from the Link Speed menu:
For 1 Gbps interfaces, select:
1 Gbps - Full Duplex
100 Mbps - Full Duplex
100 Mbps - Half Duplex
10 Mbps - Full Duplex
10 Mbps - Half Duplex
For 10 Gbps interfaces, the only selection is 10 Gbps - Full Duplex.
* 
IMPORTANT: If you select a specific Ethernet speed and duplex, you must force the connection speed and duplex from the Ethernet card to the firewall as well.
3
You can choose to override the Use Default MAC Address for the Interface by selecting Override Default MAC Address and entering the MAC address in the field.
4
Select the Shutdown Port checkbox to temporarily take this interface offline for maintenance or other reasons. If connected, the link will go down. Clear the checkbox to activate the interface and allow the link to come back up.
5
For the AppFlow feature, select the Enable flow reporting checkbox to allow flow reporting on flows created for this interface.
6
Select the Enable Multicast Support checkbox to allow multicast reception on this interface.
7
Select the Enable 802.1p tagging checkbox to tag information passing through this interface with 802.1p priority information for Quality of Service (QoS) management. Packets sent through this interface are tagged with VLAN id=0 and carry 802.1p priority information. In order to make use of this priority information, devices connected to this interface should support priority frames. QoS management is controlled by access rules on the Firewall > Access Rules page. For information on QoS and bandwidth management, see Firewall Settings > QoS Mapping.
8
Optionally select Link Aggregation or Port Redundancy from the Redundant /Aggregate Ports drop-down list. For more information see Configuring Link Aggregation and Port Redundancy.
9
Interface MTU - Specifies the largest packet size that the interface can forward without fragmenting the packet. Identify the size of the packets that the port will receive and transmit:
 

Standard packets (default)

1500

Jumbo frame packets

9000

* 
NOTE: Jumbo frame support must be enabled before a port can process jumbo frames, as explained in Jumbo Frame. Due to jumbo frame packet buffer size requirements, jumbo frames increase memory requirements by a factor of 4.

Jumbo frames are supported by NSA 3600 and higher appliances.

Fragment non-VPN outbound packets larger than this Interface’s MTU - Specifies all non-VPN outbound packets larger than this Interface’s MTU be fragmented. Specifying the fragmenting of VPN outbound packets is set in the VPN > Advanced page.
Ignore Don’t Fragment (DF) Bit - Overrides DF bits in packets.
Suppress ICMP Fragmentation Needed message generation - blocks notification that this interface can receive fragmented packets.
10
If using DHCP, the following options are displayed:
Select the Initiate renewals with a Discover when using DHCP checkbox if the server might change.
Select the Use an interval of _ seconds between DHCP Discovers during lease acquisition checkbox and adjust the number of seconds for the interval if the DHCP server might not respond immediately.
11
Optionally enable Bandwidth Management for this interface. For more information about Bandwidth Management, see Enabling Bandwidth Management.
Configuring Protocol Settings for a WAN Interface

If you specified a PPPoE, PPTP, or L2TP IP assignment when configuring the WAN interface, the Edit Interface dialog displays the Protocol tab.

The Internet Service Provider (ISP) provisions the fields (for example, SonicWall IP Address, Subnet Mask, and Gateway Address) in the Settings Acquired via section of the Protocol tab. These fields will show actual values after you connect the appliance to the ISP.

Additionally, specifying PPPoE causes SonicOS to set the Interface MTU option in the Advanced tab to 1492 and provides additional settings in the Protocol tab.

To configure additional settings for PPPoE:
1
In the Edit Interface dialog box, click the Protocol tab.
2
Select the checkboxes to enable the following options in the PPPoE Client Settings section:
Inactivity Disconnect (minutes): Enter the number of minutes (the default is 10) after which SonicOS will terminate the connection if it detects that packets are not being sent.
Strictly use LCP echo packets for server keep-alive: Select this to have SonicOS terminate the connection if it detects that the PPoE server has not sent a ppp LCP echo request packet within a minute. Select this option only if your PPPoE server supports the send LCP echo function.
Reconnect the PPPOE client if the server does not send traffic for __ minutes: Enter the number of minutes (the default is 5) after which SonicOS will terminate the PPPoE server's connection, and then reconnect, if the server does not send any packets (including the LCP echo request).

Configuring Tunnel Interfaces

You can configure several types of tunnel interfaces in SonicOS. Numbered tunnel interfaces, WLAN tunnel interfaces, and IPv6 6to4 tunnel interfaces are configured on the Network > Interfaces page. Drop tunnel interfaces are configured from Network > Routing, and unnumbered tunnel interfaces are configured as part of a VPN policy from the VPN > Settings page.

Numbered and unnumbered tunnel interfaces are used with VPNs. A numbered tunnel interface is assigned its own IP address, but an unnumbered tunnel interface borrows an IP address from an existing physical or virtual (VLAN) interface.

Support for numbered and unnumbered tunnel interface types has varied in different versions of SonicOS 6.2, see the SonicOS 6.2 Upgrade Guide for details. In SonicOS 6.2.6 and higher, both types support static routing and dynamic routing with RIP and OSPF, while numbered tunnel interfaces can also be used with BGP.

See the following sections for configuring the various types of tunnel interfaces:

Numbered Tunnel Interfaces; see Configuring VPN Tunnel Interfaces
Unnumbered Tunnel Interfaces; see Route-Based VPN with Tunnel Interface Policies
WLAN Tunnel Interfaces; see Creating a WLAN Tunnel Interface
Drop Tunnel Interfaces; see Configuring a Drop Tunnel Interface
IPv6 6to4 Tunnel Interfaces; see Configuring the 6to4 Auto Tunnel
Configuring VPN Tunnel Interfaces

You can create a numbered tunnel interface by selecting VPN Tunnel Interface from the Add Interface drop-down list. VPN tunnel interfaces are added to the Interface Settings table and then can be used with dynamic routing, including RIP, OSPF, and BGP, or a static route policy can use the VPN tunnel interface as the interface in a configuration for a static route-based VPN.

A VPN Tunnel Interface can be configured like a standard interface, including options to enable appliance management or user login using HTTP, HTTPS, Ping, or SSH in addition to multicast, flow reporting, asymmetric routing, fragmented packet handling, and Don't Fragment (DF) Bit settings.

* 
NOTE: A similar VPN policy and numbered tunnel interface must be configured on the remote gateway. The IP addresses assigned to the numbered tunnel interfaces (on the local gateway and the remote gateways) must be on the same subnet.

VPN tunnel interface deployment lists how a VPN Tunnel Interface can be deployed.

 

VPN tunnel interface deployment

TI can be configured as an interface in

TI cannot be configured as

Static Route

Static ARP entries interface

NAT

HA interface

ACL (Virtual Access Point Access Control List)

WLB (WAN Load Balancing) interface

Static NDP (Neighbor Discovery Protocol) entries interface

OSPF

OSPFv3/RIPnG: currently not supported for IPv6 advanced routing

RIP

MAC_IP Anti-spoof interface

BGP

DHCP server interface

For all platforms, the maximum supported number of VPN Tunnel Interfaces (numbered tunnel interfaces) is 64. The maximum number of unnumbered tunnel interfaces differs by platform and directly corresponds to the maximum number of VPN policies supported on each platform.

To configure a VPN Tunnel Interface:
1
Navigate to the Network > Interfaces page.
2
From the Add Interface drop-down menu under the Interface Settings table, select VPN Tunnel Interface. The Add Tunnel Interface dialog displays.

3
From the VPN Policy drop-down menu, select a VPN policy.
4
In the Name field, enter a friendly name for this interface. The name can contain alphanumeric characters, periods (dots), or underscores; it cannot contain spaces or hyphens.
5
Enter an IP address in the IP Address field. The default is 0.0.0.0, but you need to enter an explicit IP address or an error message displays.
6
In the Subnet Mask field, enter the subnet mask. The default is 255.255.255.0.
7
Optionally, add a comment in the Comment field.
8
Optionally, specify the Management protocol(s) allowed on this interface: HTTPS, Ping, SNMP, and/or SSH.
9
Optionally, specify the User Login protocol(s) allowed on this interface: HTTP and/or HTTPS.
10
Click the Advanced tab.

11
To enable flow reporting on flows created for the tunnel interface, select Enable flow reporting. This checkbox is selected by default.
12
Optionally, enable multicast reception on the interface by selecting the Enable Multicast Support checkbox. This checkbox is not selected by default.
13
Optionally, enable Asymmetric Route Support on the tunnel interface by selecting the Enable Asymmetric Route Support checkbox. This checkbox is not selected by default. For more information about asymmetric routing, see Asymmetric Routing In Cluster Configurations.
14
To enable fragmented packet handling on this interface, select the Enable Fragmented Packet Handling checkbox. If this option is not selected, fragmented packets are dropped and the VPN log report shows the log message Fragmented IPsec packet dropped. This option is selected by default.

If this option is selected, the Ignore Don’t Fragment (DF) Bit option is available.

15
Select the Ignore DF (Don't Fragment) Bit checkbox to ignore the DF bit in the packet header. Some applications can explicitly set the Don’t Fragment option in a packet, which tells all security appliances to not fragment the packet. This option, when enabled, causes the firewall to ignore the DF bit and fragment the packet regardless.
16
Click OK. The numbered VPN tunnel interface is added to the Interface Settings table.

Configuring Link Aggregation and Port Redundancy

Both Link Aggregation and Port Redundancy are configured on the Advanced tab of the Edit Interface dialog in the SonicOS UI.

Link Aggregation - Groups multiple Ethernet interfaces together forming a single logical link to support greater throughput than a single physical interface could support. This provides the ability to send multi-gigabit traffic between two Ethernet domains.
* 
NOTE: Link Aggregation is supported on NSA 2600 and higher appliances. The NSA 2600 supports Link Aggregation for Network Interfaces, but the NSA 2600 does not support Switching and, therefore, does not support Link Aggregation for Switching, which is covered in Switching > Link Aggregation.

Link Aggregation is not supported in Layer 2 Bridged Mode.

Port Redundancy - Configures a single redundant port for any physical interface that can be connected to a second switch to prevent a loss of connectivity in the event that either the primary interface or primary switch fail.
* 
NOTE: Port Redundancy is supported on NSA 2600 and higher appliances. Link Aggregation and Port Redundancy are not supported for the HA Control Interface.
Topics:  
Link Aggregation

Link Aggregation is used to increase the available bandwidth between the firewall and a switch by aggregating up to four interfaces into a single aggregate link, referred to as a Link Aggregation Group (LAG). All ports in an aggregate link must be connected to the same switch. The firewall uses a round-robin algorithm for load balancing traffic across the interfaces in a Link Aggregation Group. Link Aggregation also provides a measure of redundancy, in that if one interface in the LAG goes down, the other interfaces remain connected.

Link Aggregation is referred to using different terminology by different vendors, including Port Channel, Ether Channel, Trunk, and Port Grouping.

Topics:  
Link Aggregation Failover

SonicWall provides multiple methods for protecting against loss of connectivity in the case of a link failure, including High Availability (HA), Load Balancing Groups (LB Groups), and now Link Aggregation. If all three of these features are configured on a firewall, the following order of precedence is followed in the case of a link failure:

1
High Availability
2
Link Aggregation
3
Load Balancing Groups

HA takes precedence over Link Aggregation. Because each link in the LAG carries an equal share of the load, the loss of a link on the Active firewall will force a failover to the Idle firewall (if all of its links remain connected). Physical monitoring needs to be configured only on the primary aggregate port.

When Link Aggregation is used with a LB Group, Link Aggregation takes precedence. LB will take over only if all the ports in the aggregate link are down.

Link Aggregation Limitations
Currently only static addressing is supported for Link Aggregation. Static port channel, which is referred to as PAG (port aggregation), is one way of configuring Ethernet port channels. No LACP or PAGP packets are sent out to form an EtherChannel with the partnering device (switch or server etc).
A static Link Aggregation Group (LAG) configured with Ethernet port channels must be manually configured/bundled for NSA 3600 or higher appliances.
The dynamic Link Aggregation Control Protocol (LACP) is currently not supported. Dynamic, via a protocol to bundle Ethernet ports such as IEEE LACP or Cisco's PAGP, is another way of configuring Ethernet port channels. In this method, LACP or PAGP packets are sent out on the port.
Link Aggregation Configuration
To configure Link Aggregation:
1
On the Network > Interfaces page, click the configure icon for the interface that is to be designated the master of the Link Aggregation Group. The Edit Interface dialog displays.
2
Click on the Advanced tab.
3
In the Redundant/Aggregate Ports drop-down menu, select Link Aggregation.
4
The Aggregate Port option is displayed with a checkbox for each of the currently unassigned interfaces on the firewall. Select up to three other interfaces to assign to the LAG.
* 
NOTE: After an interface is assigned to a Link Aggregation Group, its configuration is governed by the Link Aggregation master interface and it cannot be configured independently. In the Interface Settings table, the interface's zone is displayed as Aggregate Port and the configuration icon is removed.
5
Set the Link Speed for the interface to Auto-Negotiate.
6
Click OK.
* 
NOTE: Link Aggregation requires a matching configuration on the Switch. The switch's method of load balancing will vary depending on the vendor. Consult the documentation for the switch for information on configuring Link Aggregation. Remember that it may be referred to as Port Channel, Ether Channel, Trunk, or Port Grouping.
Port Redundancy

Port Redundancy provides a simple method for configuring a redundant port for a physical Ethernet port. This is a valuable feature, particularly in high-end deployments, to protect against switch failures being a single point of failure.

When the primary interface is active, it processes all traffic to and from the interface. If the primary interface goes down, the secondary interface takes over all outgoing and incoming traffic. The secondary interface assumes the MAC address of the primary interface and sends the appropriate gratuitous ARP on a failover event. When the primary interface comes up again, it resumes responsibility for all traffic handling duties from the secondary interface.

In a typical Port Redundancy configuration, the primary and secondary interfaces are connected to different switches. This provides for a failover path in case the primary switch goes down. Both switches must be on the same Ethernet domain. Port Redundancy can also be configured with both interfaces connected to the same switch.

Port Redundancy Failover

SonicWall provides multiple methods for protecting against loss of connectivity in the case of a link failure, including High Availability (HA), Load Balancing Groups (LB Groups), and now Port Redundancy. If all three of these features are configured on a firewall, the following order of precedence is followed in the case of a link failure:

1
Port Redundancy
2
HA
3
LB Group

When Port Redundancy is used with HA, Port Redundancy takes precedence. Typically an interface failover will cause an HA failover to occur, but if a redundant port is available for that interface, then an interface failover will occur but not an HA failover. If both the primary and secondary redundant ports go down, then an HA failover will occur (assuming the secondary firewall has the corresponding port active).

When Port Redundancy is used with a LB Group, Port Redundancy again takes precedence. Any single port (primary or secondary) failures are handled by Port Redundancy just like with HA. When both the ports are down then LB kicks in and tries to find an alternate interface.

Port Redundancy Configuration
To configure Port Redundancy:
1
On the Network > Interfaces page, click the configure icon for the interface that is to be designated the master of the Link Aggregation Group. The Edit Interface dialog displays.
2
Click on the Advanced tab.
3
In the Redundant/Aggregate Ports drop-down menu, select Port Redundancy.
4
The Redundant Port drop-down menu is displayed, with all of the currently unassigned interfaces available. Select one of the interfaces.
* 
NOTE: After an interface is selected as a Redundant Port, its configuration is governed by the primary interface and it can not be configured independently. In the Interface Settings table, the interface's zone is displayed as Redundant Port, and the configuration icon is removed.
5
Set the Link Speed for the interface to Auto-Negotiate.
6
Click OK.

Configuring Virtual Interfaces (VLAN Subinterfaces)

When you add a VLAN subinterface, you need to assign it to a zone, assign it a VLAN Tag, and assign it to a physical interface. Based on your zone assignment, you configure the VLAN subinterface the same way you configure a physical interface for the same zone.

To add a virtual interface:
1
Navigate to the Network > Interfaces page.
2
At the bottom of the Interface Settings table, select Virtual Interface from the Add Interface drop-down menu. The Add Interface dialog displays.

3
Select a zone to assign to the interface. You can select LAN, WAN, DMZ, WLAN, or a custom zone. The zone assignment does not have to be the same as the parent (physical) interface. In fact, the parent interface can even remain Unassigned.

Your configuration choices for the network settings of the subinterface depend on the zone you select.

LAN, DMZ, or a custom zone of Trusted type: Static or Transparent
WLAN or a custom Wireless zone: static IP only (no IP Assignment list).
4
Assign a VLAN tag (ID) to the subinterface in the VLAN Tag field. Valid VLAN IDs are 0 (default) to 4094, although some switches reserve VLAN 1 for native VLAN designation and VLAN 0 is reserved for QoS. You need to create a VLAN subinterface with a corresponding VLAN ID for each VLAN you wish to secure with your firewall.
5
Select the parent (physical) interface to which this subinterface will belong from the Parent Interface drop-down menu. There is no per-interface limit to the number of subinterfaces you can assign – you may assign subinterfaces up to the system limit.
6
Configure the subinterface network settings based on the zone you selected. See the interface configuration instructions:
7
Select the management and user-login methods for the subinterface.
8
Click OK.

Configuring Wire Mode over VLAN Interfaces (SuperMassive 9800 Only)

Wire mode between any two VLAN interfaces is the same as Wire Mode between two physical interfaces. The feature supports:

Bypass mode, Inspect mode, and Secure mode
Both 1 gigabit and 10 gigabit interfaces
Disabling Stateful Inspection

The feature does not support Link Aggregation and Link State Propagation.

* 
NOTE: Wire Mode over VLAN interfaces and VLAN Translation cannot be enabled at the same time.
To configure Wire Mode over VLAN interfaces:
1
Navigate to Network > Interfaces.
2
Configure at least two VLAN subinterfaces of different physical parent interfaces as described in Configuring Virtual Interfaces (VLAN Subinterfaces) and Configuring an Interface for Wire Mode.
3
Click OK. The Interface Settings table is updated. For example, see Wire Mode with Bypass mode and Inspect mode over VLAN interfaces and Wire Mode with Secure mode over VLAN interfaces.

Wire Mode with Bypass mode and Inspect mode over VLAN interfaces

Wire Mode with Secure mode over VLAN interfaces

Enabling DNS Proxy on an Interface

When DNS Proxy is enabled globally, you can enable it on individual interfaces. This allows you to enable the feature for different network segments independently. For how to enable DNS Proxy on an interface, see Enabling DNS Proxy.

Configuring IPS Sniffer Mode

To configure the firewall for IPS Sniffer Mode, you use two interfaces in the same zone for the L2 Bridge-Pair. You can use any interfaces except the WAN interface. For this example, X2 and X3 are used for the Bridge-Pair and are configured in the LAN zone. The WAN interface (X1) is used by the firewall for access to the firewall Data Center as needed. The mirrored port on the switch connects to one of the interfaces in the Bridge-Pair.

Topics:  

Configuration Task List for IPS Sniffer Mode

Configure the Primary Bridge Interface
Select LAN as the Zone for the Primary Bridge Interface
Assign a static IP address
Configure the Secondary Bridge Interface
Select LAN as the Zone for the Secondary Bridge Interface
Enable the L2 Bridge to the Primary Bridge interface
Enable SNMP and configure the IP address of the SNMP manager system where traps can be sent
Configure Security Services for LAN traffic
Configure logging alert settings to “Alert” or below
Connect the mirrored port on the switch to either one of the interfaces in the Bridge-Pair
Connect and configure the WAN to allow access to dynamic signature data over the Internet

Configuring the Primary Bridge Interface

To configure the primary bridge interface:
1
Navigate to Network > Interfaces.
2
Click the Configure icon in the right column of interface X2. The Edit Interface dialog displays.
3
Select LAN from the Zone drop-down menu. More options display.
* 
NOTE: You do not need to configure settings on the Advanced or VLAN Filtering tabs.
4
For IP Assignment, select Static IP Mode from the drop-down menu.
5
Configure the interface with a static IP Address (for example, 10.1.2.3). The IP address you choose should not collide with any of the networks that are seen by the switch.
* 
NOTE: The Primary Bridge Interface must have a static IP assignment.
6
Configure the Subnet Mask.
7
Type in a descriptive comment.
8
Select Management options for the interface: HTTPS, Ping, SNMP, SSH.
9
Select User Login options: HTTP, HTTPS.
10
To enable redirect to HTTPS from HTTP, select the Add rule to enable redirect from HTTP to HTTPS checkbox. For more information about this option, see HTTP/HTTPS Redirection.
11
Click OK.

Configuring the Secondary Bridge Interface

Our example continues with X3 as the secondary bridge interface.

To configure the secondary bridge interface:
1
Navigate to Network > Interfaces.
2
Click the Configure icon in the right column of interface X2. The Edit Interface dialog displays.
3
Select LAN from the Zone drop-down menu. More options display.
* 
NOTE: You do not need to configure settings on the Advanced or VLAN Filtering tabs.
4
In the IP Assignment drop-down menu, select Layer 2 Bridged Mode.
5
In the Bridged to drop-down menu, select the X2 interface.
6
Do not enable the Block all non-IPv4 traffic setting if you want to monitor non-IPv4 traffic.
7
Select Never route traffic on this bridge-pair to ensure that the traffic from the mirrored switch port is not sent back out onto the network.
8
Select Only sniff traffic on this bridge-pair to enable sniffing or monitoring of packets that arrive on the L2 Bridge from the mirrored switch port.
9
Select Disable stateful-inspection on this bridge-pair to exempt these interfaces from stateful high availability inspection. If Deep Packet Inspection services are enabled for these interfaces, the DPI services will continue to be applied.
10
Select Management options for the interface: HTTPS, Ping, SNMP, SSH.
11
Select User Login options: HTTP, HTTPS.
12
To enable redirect to HTTPS from HTTP, select the Add rule to enable redirect from HTTP to HTTPS checkbox. For more information about this option, see HTTP/HTTPS Redirection.
13
Click OK.

Enabling and Configuring SNMP

When SNMP is enabled, SNMP traps are automatically triggered for many events that are generated by SonicWall Security Services such as Intrusion Prevention and Gateway Anti-Virus (GAV).

More than 50 IPS and GAV events currently trigger SNMP traps. The SonicOS Log Event Reference Guide contains a list of events that are logged by SonicOS, and includes the SNMP trap number where applicable. The guide is available online at http://www.sonicwall.com/us/Support.html by typing Log Event into the Search field at the top of the page.

To determine the traps that are possible when using IPS Sniffer Mode with Intrusion Prevention enabled, search for Intrusion in the table found in the Index of Log Event Messages section in the SonicOS Log Event Reference Guide. The SNMP trap number, if available for that event, is printed in the SNMP Trap Type column of the table.

To determine the possible traps with Gateway Anti-Virus enabled, search the table for Security Services, and view the SNMP trap number in the SNMP Trap Type column.

To enable and configure SNMP:
1
Navigate to the System > SNMP page.

2
Select Enable SNMP.
3
Click Accept. The Configure icon becomes active and the View, User/Group, and Access sections are displayed.

4
Click Configure. The SNMP Settings dialog displays.

5
In the System Name field, type the name of the SNMP manager system that will receive the traps sent from the firewall.
6
Enter the name or email address of the contact person for the SNMP Contact in the System Contact field.
7
Enter a description of the system location, such as 3rd floor lab, in the System Location field.
8
Enter the system’s asset number in the Asset Number field.
9
In the Get Community Name field, type the community name that has permissions to retrieve SNMP information from the firewall, for example, public.
10
In the Trap Community Name field, type the community name that will be used to send SNMP traps from the firewall to the SNMP manager, for example, public.
11
In the Host 1/2/3/4 fields, type in the IP address(es) of the SNMP manager system(s) that will receive the traps.
12
Click OK.

Configuring Security Services (Unified Threat Management)

The settings that you enable in this section control what type of malicious traffic you detect in IPS Sniffer Mode. Typically, you will want to enable Intrusion Prevention, but you may also want to enable other Security Services, such as Gateway Anti-Virus or Anti-Spyware.

To enable Security Services, your SonicWall must be licensed for them and the signatures must be downloaded from the firewall Data Center. For complete instructions on enabling and configuring IPS, GAV, and Anti-Spyware, see Security Services.

Topics:  

Configuring Logging

You can configure logging on the Log > Settings page to record entries for attacks that are detected by the firewall. For how to enable logging, see Log > Settings.

Connecting the Mirrored Switch Port to a IPS Sniffer Mode Interface

Use a standard Cat-5 Ethernet cable to connect the mirrored switch port to either interface in the Bridge-Pair. Network traffic is sent automatically from the switch to the firewall where it can be inspected.

Consult the switch documentation for instructions on setting up the mirrored port.

Connecting and Configuring the WAN Interface to the Data Center

Connect the WAN port on the firewall, typically port X1, to your gateway or to a device with access to the gateway. The firewall communicates with the firewall Data Center automatically. For detailed instructions on configuring the WAN interface, see Configuring a WAN Interface.

Configuring Wire and Tap Mode

SonicOS supports Wire Mode and Tap Mode, which provide methods of non‑disruptive, incremental insertion into networks. Wire and Tap mode settings describes the wire and tap modes.

* 
NOTE: Wire mode is supported on NSA 2600 and higher appliances.
 

Wire and Tap mode settings

Wire mode setting

Description

Bypass Mode

Bypass Mode allows for the quick and relatively non-interruptive introduction of firewall hardware into a network. Upon selecting a point of insertion into a network (for example, between a core switch and a perimeter firewall, in front of a VM server farm, at a transition point between data classification domains), the firewall is inserted into the physical data path, requiring a very short maintenance window. One or more pairs of switch ports on the firewall are used to forward all packets across segments at full line rates, with all the packets remaining on the firewall’s 240Gbps switch fabric rather than getting passed up to the multi-core inspection and enforcement path. While Bypass Mode does not offer any inspection or firewalling, this mode allows you to physically introduce the firewall into the network with a minimum of downtime and risk, and to obtain a level of comfort with the newly inserted component of the networking and security infrastructure. You can then transition from Bypass Mode to Inspect or Secure Mode instantaneously through a simple user-interface driven reconfiguration.

Inspect Mode

Inspect Mode extends Bypass Mode without functionally altering the low-risk, zero-latency packet path. Packets continue to pass through the firewall’s switch fabric, but they are also mirrored to the multi-core RF-DPI engine for the purposes of passive inspection, classification, and flow reporting. This reveals the firewall’s Application Intelligence and threat detection capabilities without any actual intermediate processing.

Secure Mode

Secure Mode is the progression of Inspect Mode, actively interposing the firewall’s multi-core processors into the packet processing path. This unleashes the inspection and policy engines’ full-set of capabilities, including Application Intelligence and Control, Intrusion Prevention Services, Gateway and Cloud-based Anti-Virus, Anti-Spyware, and Content Filtering. Secure Mode affords the same level of visibility and enforcement as conventional NAT or L2 Bridged Mode deployments, but without any L3/L4 transformations, and with no alterations of ARP or routing behavior. Secure Mode thus provides an incrementally attainable NGFW deployment requiring no logical and only minimal physical changes to existing network designs.

Secure mode should be used when creating wire-mode pairs for VLAN translation.

Tap Mode

Tap Mode provides the same visibility as Inspect Mode, but differs from the latter in that it ingests a mirrored packet stream via a single switch port on the firewall, eliminating the need for physically intermediated insertion. Tap Mode is designed for use in environments employing network taps, smart taps, port mirrors, or SPAN ports to deliver packets to external devices for inspection or collection. Like all other forms of Wire Mode, Tap Mode can operate on multiple concurrent port instances, supporting discrete streams from multiple taps.

Wire modes: Functional differences summarizes the key functional differences between modes of interface configuration:

 

Wire modes: Functional differences

Interface configuration

Bypass mode

Inspect mode

Secure mode

Tap mode

L2 Bridge, Transparent, NAT, Route modes

Active/Active Clustering 1

No

No

No

No

Yes

Application Control

No

No

Yes

No

Yes

Application Visibility

No

Yes

Yes

Yes

Yes

ARP/Routing/NAT a

No

No

No

No

Yes

Comprehensive Anti‑Spam Service a

No

No

No

No

Yes

Content Filtering

No

No

Yes

No

Yes

DHCP Server a

No

No

No

No

Yes 2

DPI Detection

No

Yes

Yes

Yes

Yes

DPI Prevention

No

No

Yes

No

Yes

DPI-SSLa

No

No

Yes

No

Yes

High-Availability

Yes

Yes

Yes

Yes

Yes

Link-State Propagation 3

Yes

Yes

Yes

No

No

Stateful Packet Inspection

No

Yes

Yes

Yes

Yes

TCP Handshake Enforcement 4

No

No

No

No

Yes

Virtual Groups a

No

No

No

No

Yes

VLAN Translation 5

No

No

Yes

No

No


1
These functions or services are unavailable on interfaces configured in Wire Mode, but remain available on a system-wide level for any interfaces configured in other compatible modes of operation.

2
Not available in L2 Bridged Mode.

3
Link State Propagation is a feature whereby interfaces in a Wire Mode pair mirror the link-state triggered by transitions of their partners. This is essential to proper operations in redundant path networks. Link State Propagation is not supported in Wire Mode over VLAN interfaces.

4
Disabled by design in Wire Mode to allow for failover events occurring elsewhere on the network to be supported when multiple Wire Mode paths, or when multiple firewall units are in use along redundant or asymmetric paths.

5
VLAN Translation is not supported in Wire Mode over VLAN interfaces.

* 
NOTE: When operating in Wire Mode, the firewall’s dedicated Management interface is used for local management. To enable remote management and dynamic security services and application intelligence updates, a WAN interface (separate from the Wire Mode interfaces) must be configured for internet connectivity. This is easily done given that SonicOS supports interfaces in mixed-modes of almost any combination.

Configuring an Interface for Wire Mode

* 
NOTE: Wire Mode over VLAN interfaces is similar to Wire Mode, but does not support all the options that Wire Mode does. For more information, see Configuring Wire Mode over VLAN Interfaces (SuperMassive 9800 Only).

Wire Mode can be configured on WAN, LAN, DMZ, and custom zones (except wireless zones). Wire Mode is a simplified form of Layer 2 Bridged Mode, and is configured as a pair of interfaces. In Wire Mode, the destination zone is the Paired Interface Zone. Access rules are applied to the Wire Mode pair based on the direction of traffic between the source Zone and its Paired Interface Zone. For example, if the source Zone is WAN and the Paired Interface Zone is LAN, then WAN to LAN and LAN to WAN rules are applied, depending on the direction of the traffic.

In Wire Mode, you can enable Link State Propagation, which propagates the link status of an interface to its paired interface. If an interface goes down, its paired interface is forced down to mirror the link status of the first interface. Both interfaces in a Wire Mode pair always have the same link status.

In Wire Mode, you can Disable Stateful Inspection. When Disable Stateful Inspection is selected, Stateful Packet Inspection is turned off. When Disable Stateful Inspection is not selected, new connections can be established without enforcing a 3-way TCP handshake. Disable Stateful Inspection must be selected if asymmetrical routes are deployed.

To configure an interface for Wire Mode:
1
On the Network > Interfaces page, click the Configure icon for the interface you want to configure for Wire Mode. The Edit Interface dialog displays.

2
In the Zone drop-down menu, select any zone type except WLAN.
3
From the Mode / IP Assignment drop-down menu, to configure the Interface for:
Tap mode, select Tap Mode (1-Port Tap)
Wire Mode, select Wire Mode (2-Port Wire).
4
In the Wire Mode Type drop-down menu, select t he appropriate mode:
Bypass (via Internal Switch/Relay)
Inspect (Passive DPI of Mirrored Traffic)
Secure (Active DPI of Inline Traffic)
5
In the Paired Interface drop-down menu, select the interface that will connect to the upstream firewall. The paired interfaces must be of the same type (two 1 GB interfaces or two 10 GB interfaces).
* 
NOTE: Only unassigned interfaces are available in the Paired Interface drop-down menu. To make an interface unassigned, click on the Configure button for it, and in the Zone drop-down menu, select Unassigned.
6
Click OK.

Configuring Wire Mode for a WAN/LAN Zone Pair

The following configuration is an example of how Wire Mode can be configured. This example is for a WAN zone paired with a LAN zone. Wire Mode can also be configured for DMZ and custom zones.

To configure Wire Mode for a WAN/LAN Zone Pair:
1
Go to Network > Interfaces.
2
Click one of these:
Add Interface button.
Configure icon for the interface you want to configure.

The Add/Edit Interface dialog displays.

3
Under the General tab, from the IP Assignment drop-down menu, select Wire Mode (2-Port Wire).

4
In the Zone list, select WAN.
5
In the Paired Interface Zone list, select LAN.
6
Select the Disable Stateful Inspection option.
7
Select the Enable Link State Propagation option.
8
Click the OK button. The Interface Settings table is updated:

Wire Mode with Link Aggregation

* 
NOTE: Wire Mode over VLAN interfaces does not support Link Aggregation. For more information, see Configuring Wire Mode over VLAN Interfaces (SuperMassive 9800 Only).

Link Aggregation (LAG) is used to bundle multiple links into a single interface to increase bandwidth. To inspect traffic over a LAG interface, a SonicWall network security appliance can be connected inline, allowing packets sent on one link to be bridged across to the destination transparently. Existing Wire Mode features such as link state propagation are supported. Up to 8 members per LAG are supported.

Wire Mode and Link Aggregation are configured from the Network > Interfaces page in SonicOS. When Link Aggregation is selected on the Advanced tab, the Edit Interface dialog lists unassigned interfaces. You can select member interfaces for each side of the Wire Mode connection. The number of members on each side must be equal. It is recommended that the type and bandwidth size of the member interfaces also match.

To configure Wire Mode with LAG:
1
Go to the Network > Interfaces page
2
Click the Configure icon for the interface you want to configure.

3
From the Zone drop-down menu, select the zone you want.
4
From the Mode / IP Assignment drop-down menu, select Wire Mode (2-Port Wire).
5
From the Wire Mode Type drop-down menu, select Secure (Active DPI of Inline Traffic).
6
From the Paired Interface drop-down menu, select the interface you want.
7
From the Paired Interface Zone drop-down menu, select the interface you want.
8
Select the Bypass when SonicOS is restarting or down option. This option is selected by default.
* 
NOTE: This option is available on the SuperMassive 9800 only.
9
Select the Disable Stateful Inspection option. This option is selected by default.
10
(Optional) Select the Enable Link State Propagation option if you want it. This option is not selected by default.
11
Click the Advanced tab.
To continue on the Advanced tab:

1
From the Redundant/Aggregate Ports drop-down menu, select Link Aggregation. The options change.

2
For the Aggregate Port, select the port that you want.
3
For the Paired Interface Aggregate Port, select the port that you want.
4
Click OK. The configuration is displayed in the Interface Settings table on the Network > Interfaces page.

Layer 2 Bridged Mode

SonicOS includes L2 (Layer 2) Bridged Mode, a method of unobtrusively integrating a firewall into any Ethernet network. L2 Bridged Mode is ostensibly similar to SonicOS’s Transparent Mode in that it enables a firewall to share a common subnet across two interfaces, and to perform stateful and deep-packet inspection on all traversing IP traffic, but it is functionally more versatile.

In particular, L2 Bridged Mode employs a secure learning bridge architecture, enabling it to pass and inspect traffic types that cannot be handled by many other methods of transparent security appliance integration. Using L2 Bridged Mode, a SonicWall Security Appliance can be non-disruptively added to any Ethernet network to provide in-line deep-packet inspection for all traversing IPv4 TCP and UDP traffic. In this scenario, the firewall is not used for security enforcement, but instead for bidirectional scanning, blocking viruses and spyware, and stopping intrusion attempts.

Unlike other transparent solutions, L2 Bridged Mode can pass all traffic types, including IEEE 802.1Q VLANs, Spanning Tree Protocol, multicast, broadcast, and IPv6, ensuring that all network communications will continue uninterrupted.

Another aspect of the versatility of L2 Bridged Mode is that you can use it to configure IPS Sniffer Mode. Supported on SonicWall Security Appliances, IPS Sniffer Mode uses a single interface of a Bridge-Pair to monitor network traffic from a mirrored port on a switch. IPS Sniffer Mode provides intrusion detection, but cannot block malicious traffic because the firewall is not connected inline with the traffic flow. For more information about IPS Sniffer Mode, see IPS Sniffer Mode.

L2 Bridged Mode provides an ideal solution for networks that already have an existing firewall, and do not have immediate plans to replace their existing firewall but wish to add the security of SonicWall deep-packet inspection and security services such as Intrusion Prevention Services, Gateway Anti Virus, and Gateway Anti Spyware. If you do not have SonicWall security services subscriptions, you may sign up for free trials from the Security Service > Summary page of your SonicWall.

You can also use L2 Bridged Mode in a High Availability deployment. This scenario is explained in the Layer 2 Bridged Mode with High Availability.

* 
NOTE: Link Aggregation is not supported in Layer 2 Bridged Mode.
Topics:  

Key Features of SonicOS Layer 2 Bridged Mode

The following table outlines the benefits of each key feature of layer 2 bridged mode:

 

SonicOS Layer 2 Bridged Mode: Key features and benefits

Feature

Benefit

L2 Bridging with Deep Packet Inspection

This method of transparent operation means that a SonicWall Security Appliance can be added to any network without the need for readdressing or reconfiguration, enabling the addition of deep-packet inspection security services with no disruption to existing network designs. Developed with connectivity in mind as much as security, L2 Bridged Mode can pass all Ethernet frame types, ensuring seamless integration.

Secure Learning Bridge Architecture

True L2 behavior means that all allowed traffic flows natively through the L2 Bridge. Whereas other methods of transparent operation rely on ARP and route manipulation to achieve transparency, which frequently proves problematic, L2 Bridged Mode dynamically learns the topology of the network to determine optimal traffic paths.

Universal Ethernet Frame‑Type Support

All Ethernet traffic can be passed across an L2 Bridge, meaning that all network communications will continue uninterrupted. While many other methods of transparent operation will only support IPv4 traffic, L2 Bridged Mode will inspect all IPv4 traffic, and will pass (or block, if desired) all other traffic, including LLC, all Ethertypes, and even proprietary frame formats.

Mixed-Mode Operation

L2 Bridged Mode can concurrently provide L2 Bridging and conventional security appliance services, such as routing, NAT, VPN, and wireless operations. This means it can be used as an L2 Bridge for one segment of the network, while providing a complete set of security services to the remainder of the network. This also allows for the introduction of the SonicWall Security Appliance as a pure L2 bridge, with a smooth migration path to full security services operation.

Wireless Layer 2 Bridging

NOTE: Does not apply to the SuperMassive 9800.

Use a single IP subnet across multiple zone types, including LAN, WLAN, DMZ, or custom zones. This feature allows wireless and wired clients to seamlessly share the same network resources, including DHCP addresses. The Layer 2 protocol can run between paired interfaces, allowing multiple traffic types to traverse the bridge, including broadcast and non-ip packets.

Key Concepts to Configuring L2 Bridged Mode and Transparent Mode

The following terms are used when referring to the operation and configuration of L2 Bridged Mode:

L2 Bridged Mode – A method of configuring a SonicWall Security Appliance, which enables the firewall to be inserted inline into an existing network with absolute transparency, beyond even that provided by Transparent Mode. Layer 2 Bridged Mode also refers to the IP Assignment configuration that is selected for Secondary Bridge Interfaces that are placed into a Bridge-Pair.
Transparent Mode – A method of configuring a SonicWall Security Appliance that allows the firewall to be inserted into an existing network without the need for IP reconfiguration by spanning a single IP subnet across two or more interfaces through the use of automatically applied ARP and routing logic.
IP Assignment – When configuring a Trusted (LAN) or Public (DMZ) interface, the IP Assignment for the interface can either be:
Static – The IP address for the interface is manually entered.
Transparent Mode – The IP address(es) for the interface is assigned using an Address Object (Host, Range, or Group) that falls within the WAN Primary IP subnet, effectively spanning the subnet from the WAN interface to the assigned interface.
Layer 2 Bridged Mode – An interface placed in this mode becomes the Secondary Bridge Interface to the Primary Bridge Interface to which it is paired. The resulting Bridge-Pair will then behave like a two-port learning bridge with full L2 transparency, and all IP traffic that passes through will be subjected to full stateful failover and deep packet inspection.
Bridge-Pair – The logical interface set composed of a Primary Bridge Interface and a Secondary Bridge Interface. The terms primary and secondary do not imply any inherent level of operational dominance or subordination; both interfaces continue to be treated according to their zone type, and to pass IP traffic according to their configured Access Rules. Non-IPv4 traffic across the Bridge-Pair is controlled by the Block all non-IPv4 traffic setting on the Secondary Bridge Interface. A system may support as many Bridge Pairs as it has interface pairs available. In other words, the maximum number of Bridge-Pairs is equal to ½ the number of physical interfaces on the platform. Membership in a Bridge-Pair does not preclude an interface from conventional behavior; for example, if X1 is configured as a Primary Bridge Interface paired to X3 as a Secondary Bridge Interface, X1 can simultaneously operate in its traditional role as the Primary WAN, performing NAT for Internet-bound traffic through the Auto-added X1 Default NAT Policy.
Primary Bridge Interface – A designation that is assigned to an interface once a Secondary Bridge Interface has been paired to it. A Primary Bridge Interface can belong to an Untrusted (WAN), Trusted (LAN), or Public (DMZ) zone.
Secondary Bridge Interface – A designation that is assigned to an interface whose IP Assignment has been configured for Layer 2 Bridged Mode. A Secondary Bridge Interface can belong to a Trusted (LAN), or Public (DMZ) zone.
Bridge Management Address – The address of the Primary Bridge Interface is shared by both interfaces of the Bridge-Pair. If the Primary Bridge Interface also happens to be the Primary WAN interface, it is this address that is uses for outbound communications by the firewall, such as NTP, and License Manager updates. Hosts that are connected to either segment of the Bridge-Pair may also use the Bridge Management Address as their gateway, as will be common in Mixed-Mode deployments.
Bridge-Partner – The term used to refer to the other member of a Bridge-Pair.
Non-IPv4 Traffic - SonicOS supports the following IP protocol types: ICMP (1), IGMP (2), TCP (6), UDP (17), GRE (47), ESP (50), AH (51), EIGRP (88), OSPF (89), PIM-SM (103), L2TP (115). More esoteric IP types, such as Combat Radio Transport Protocol (126), are not natively handled by the firewall, nor are non-IPv4 traffic types such as IPX or (currently) IPv6. L2 Bridged Mode can be configured to either pass or drop Non-IPv4 traffic.
Captive-Bridged Mode – This optional mode of L2 Bridge operation prevents traffic that has entered an L2 bridge from being forwarded to a non-Bridge-Pair interface. By default, L2 Bridge logic will forward traffic that has entered the L2 Bridge to its destination along the most optimal path as determined by ARP and routing tables. In some cases, the most optimal path might involve routing or NATing to a non-Bridge-Pair interface. Activating Captive-Bridged Mode ensures that traffic which enters an L2 Bridge exits the L2 Bridge rather than taking its most logically optimal path. In general, this mode of operation is only required in complex networks with redundant paths, where strict path adherence is required.
Pure L2 Bridge Topology – Refers to deployments where the firewall will be used strictly in L2 Bridged Mode for the purposes of providing in-line security to a network. This means that all traffic entering one side of the Bridge-Pair will be bound for the other side, and will not be routed/NATed through a different interface. This will be common in cases where there is an existing perimeter security appliance, or where in-line security is desired along some path (for example, inter-departmentally, or on a trunked link between two switches) of an existing network. Pure L2 Bridge Topology is not a functional limitation, but rather a topological description of a common deployment in heterogeneous environments.
Mixed-Mode Topology – Refers to deployments where the Bridge-Pair will not will not be the only point of ingress/egress through the firewall. This means that traffic entering one side of the Bridge-Pair may be destined to be routed/NATed through a different interface. This will be common when the firewall is simultaneously used to provide security to one or more Bridge-Pair while also providing:
Perimeter security, such as WAN connectivity, to hosts on the Bridge-Pair or on other interfaces.
Firewall and Security services to additional segments, such as Trusted (LAN) or Public (DMZ) interface, where communications will occur between hosts on those segments and hosts on the Bridge-Pair.
Wireless services with SonicPoints, where communications will occur between wireless clients and hosts on the Bridge-Pair.

Comparing L2 Bridged Mode to Transparent Mode

While Transparent Mode allows a security appliance running SonicOS to be introduced into an existing network without the need for re-addressing, it presents a certain level of disruptiveness, particularly with regard to ARP, VLAN support, multiple subnets, and non-IPv4 traffic types. Consider a scenario where a Transparent Mode SonicWall appliance has just been added to the network with a goal of minimally disruptive integration, particularly:

Negligible or no unscheduled downtime
No need to re-address any portion of the network
No need to reconfigure or otherwise modify the gateway router (as is common when the router is owned by the ISP)
Topics:  
ARP in Transparent Mode

ARP – Address Resolution Protocol (the mechanism by which unique hardware addresses on network interface cards are associated to IP addresses) is proxied in Transparent Mode. If the Workstation on Server on the left had previously resolved the Router (192.168.0.1) to its MAC address 00:99:10:10:10:10, this cached ARP entry would have to be cleared before these hosts could communicate through the firewall. This is because the firewall proxies (or answers on behalf of) the gateway’s IP (192.168.0.1) for hosts connected to interfaces operating in Transparent Mode. So when the Workstation at the left attempts to resolve 192.168.0.1, the ARP request it sends is responded to by the firewall with its own X0 MAC address (00:06:B1:10:10:10).

The firewall also proxy ARPs the IP addresses specified in the Transparent Range (192.168.0.100 to 192.168.0.250) assigned to an interface in Transparent Mode for ARP requests received on the X1 (Primary WAN) interface. If the Router had previously resolved the Server (192.168.0.100) to its MAC address 00:AA:BB:CC:DD:EE, this cached ARP entry would have to be cleared before the router could communicate with the host through the firewall. This typically requires a flushing of the router’s ARP cache either from its management interface or through a reboot. Once the router’s ARP cache is cleared, it can then send a new ARP request for 192.168.0.100, to which the firewall will respond with its X1 MAC 00:06:B1:10:10:11.

VLAN Support in Transparent Mode

While the network depicted in the above diagram is simple, it is not uncommon for larger networks to use VLANs for segmentation of traffic. If this was such a network, where the link between the switch and the router was a VLAN trunk, a Transparent Mode SonicWall would have been able to terminate the VLANs to subinterfaces on either side of the link, but it would have required unique addressing; that is, non-Transparent Mode operation requiring re-addressing on at least one side. This is because only the Primary WAN interface can be used as the source for Transparent Mode address space.

Multiple Subnets in Transparent Mode

It is also common for larger networks to employ multiple subnets, be they on a single wire, on separate VLANs, multiple wires, or some combination. Transparent Mode is capable of supporting multiple subnets through the use of Static ARP and Route entries.

Non-IPv4 Traffic in Transparent Mode

Transparent Mode drops (and generally logs) all non-IPv4 traffic, precluding it from passing other traffic types, such as IPX, or unhandled IP types.

L2 Bridged Mode addresses these common Transparent Mode deployment issues and is described in the following sections.

ARP in L2 Bridged Mode

L2 Bridged Mode employs a learning bridge design where it will dynamically determine which hosts are on which interface of an L2 Bridge (referred to as a Bridge-Pair). ARP is passed through natively, meaning that a host communicating across an L2 Bridge will see the actual host MAC addresses of their peers. For example, the Workstation communicating with the Router (192.168.0.1) sees the router as 00:99:10:10:10:10, and the Router sees the Workstation (192.168.0.100) as 00:AA:BB:CC:DD:EE.

This behavior allows for a SonicWall operating in L2 Bridged Mode to be introduced into an existing network with no disruption to most network communications other than that caused by the momentary discontinuity of the physical insertion.

* 
NOTE: Stream-based TCP protocols communications (for example, an FTP session between a client and a server) will need to be re-established upon the insertion of an L2 Bridged Mode firewall. This is by design so as to maintain the security afforded by stateful packet inspection. As the stateful packet inspection engine can not have knowledge of the TCP connections which pre-existed it, it drops these established packets with a log event such as TCP packet received on non-existent/closed connection; TCP packet dropped.
VLAN Support in L2 Bridged Mode

On SonicWall Security Appliances, L2 Bridged Mode provides fine control over 802.1Q VLAN traffic traversing an L2 Bridge. The default handling of VLANs is to allow and preserve all 802.1Q VLAN tags as they pass through an L2 Bridge, while still applying all firewall rules, and stateful and deep-packet inspection to the encapsulated traffic. It is further possible to specify white/black lists for allowed/disallowed VLAN IDs through the L2 Bridge.

This allows a SonicWall operating in L2 Bridged Mode to be inserted, for example, inline into a VLAN trunk carrying any number of VLANs, and to provide full security services to all IPv4 traffic traversing the VLAN without the need for explicit configuration of any of the VLAN IDs or subnets. Firewall Access Rules can also, optionally, be applied to all VLAN traffic passing through the L2 Bridged Mode because of the method of handling VLAN traffic.

L2 Bridge IP Packet Path

L2 Bridge IP packet flow

The following sequence of events describes flow in L2 Bridge IP packet flow:

1
802.1Q encapsulated frame enters an L2 Bridge interface (this first step, the next step, and the final step apply only to 802.1Q VLAN traffic).
2
The 802.1Q VLAN ID is checked against the VLAN ID white/black list. If the VLAN ID is:
Disallowed, the packet is dropped and logged.
Allowed, the packet is de-capsulated, the VLAN ID is stored, and the inner packet (including the IP header) is passed through the full packet handler.
3
As any number of subnets is supported by L2 Bridging, no source IP spoof checking is performed on the source IP of the packet. It is possible to configure L2 Bridges to only support a certain subnet or subnets using Firewall Access Rules.
4
SYN Flood checking is performed.
5
A destination route lookup is performed to the destination zone, so that the appropriate Firewall Access rule can be applied. Any zone is a valid destination, including the same zone as the source zone (for example, LAN to LAN), the Untrusted zone (WAN), the Encrypted (VPN), Wireless (WLAN), Multicast, or custom zones of any type.
6
A NAT lookup is performed and applied, as needed:
In general, the destination for packets entering an L2 Bridge will be the Bridge-Partner interface (that is, the other side of the bridge). In these cases, no translation is performed.
In cases where the L2 Bridge Management Address is the gateway, as will sometimes be the case in Mixed-Mode topologies, then NAT will be applied as needed (for more details, see L2 Bridge Path Determination).
7
Firewall Access Rules are applied to the packet. For example, on SonicWall Security Appliances, the following packet decode shows an ICMP packet bearing VLAN ID 10, source IP address 110.110.110.110 destined for IP address 4.2.2.1.

It is possible to construct a Firewall Access Rule to control any IP packet, independent of its VLAN membership, by any of its IP elements, such as source IP, destination IP, or service type. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue.

8
A connection cache entry is made for the packet, and required NAT translations (if any) are performed.
9
Stateful packet inspection and transformations are performed for TCP, VoIP, FTP, MSN, Oracle, RTSP and other media streams, PPTP and L2TP. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue.
10
Deep packet inspection, including GAV, IPS, Anti-Spyware, CFS and email-filtering is performed. If the packet is disallowed, it will be dropped and logged. If the packet is allowed, it will continue. Client notification will be performed as configured.
11
If the packet is destined for the Encrypted zone (VPN), the Untrusted zone (WAN), or some other connected interface (the last two of which might be the case in Mixed-Mode Topologies) the packet will be sent via the appropriate path.
12
If the packet is not destined for the VPN/WAN/Connected interface, the stored VLAN tag will be restored, and the packet (again bearing the original VLAN tag) will be sent out the Bridge-Partner interface.
Multiple Subnets in L2 Bridged Mode

L2 Bridged Mode is capable of handling any number of subnets across the bridge, as described above. The default behavior is to allow all subnets, but Access Rules can be applied to control traffic as needed.

Non-IPv4 Traffic in L2 Bridged Mode

Unsupported traffic is, by default, passed from one L2 Bridge interface to the Bridge-Partner interface. This allows the firewall to pass other traffic types, including LLC packets such as Spanning Tree, other EtherTypes, such as MPLS label switched packets (EtherType 0x8847), Appletalk (EtherType 0x809b), and the ever-popular Banyan Vines (EtherType 0xbad). These non-IPv4 packets will only be passed across the Bridge, they will not be inspected or controlled by the packet handler. If these traffic types are not needed or desired, the bridging behavior can be changed by enabling the Block all non-IPv4 traffic option on the Secondary Bridge Interface configuration dialog.

Comparison of L2 Bridged Mode to Transparent Mode
 

Comparison of L2 Bridged Mode to Transparent Mode

Attribute

Layer 2 Bridged Mode

Transparent Mode

Layer of Operation

Layer 2 (MAC)

Layer 3 (IP)

ARP behavior

ARP (Address Resolution Protocol) information is unaltered. MAC addresses natively traverse the L2 bridge. Packets that are destined for SonicWall’s MAC addresses will be processed, others will be passed, and the source and destinations will be learned and cached.

ARP is proxied by the interfaces operating in Transparent Mode.

Path determination

Hosts on either side of a Bridge-Pair are dynamically learned. There is no need to declare interface affinities.

The Primary WAN interface is always the master ingress/egress point for Transparent mode traffic, and for subnet space determination. Hosts transparently sharing this subnet space must be explicitly declared through the use of Address Object assignments.

Maximum interfaces

Two interfaces, a Primary Bridge Interface and a Secondary Bridge Interface.

Two or more interfaces. The master interface is always the Primary WAN. There can be as many transparent subordinate interfaces as there are interfaces available.

Maximum pairings

The maximum number of Bridge-Pairs allowed is limited only by available physical interfaces. This can be described as “many One-to-One pairings”.

Transparent Mode only allows the Primary WAN subnet to be spanned to other interfaces, although it allows for multiple interfaces to simultaneously operate as transparent partners to the Primary WAN. This can be described as “a single One-to-One” or “a single One-to-Many pairing”.

Zone restrictions

The Primary Bridge Interface can be Untrusted, Trusted, or Public. The Secondary Bridge Interface can be Trusted or Public.

Interfaces in a Transparent Mode pair must consist of one Untrusted interface (the Primary WAN, as the master of the pair’s subnet) and one or more Trusted/Public interface (such as, LAN or DMZ).

Subnets supported

Any number of subnets is supported. Firewall Access Rules can be written to control traffic to/from any of the subnets as needed.

In its default configuration, Transparent Mode only supports a single subnet (that which is assigned to, and spanned from the Primary WAN). It is possible to manually add support for additional subnets through the use of ARP entries and routes.

Non-IPv4 Traffic

All non-IPv4 traffic, by default, is bridged from one Bridge-Pair interface to the Bridge-Partner interface, unless disabled on the Secondary Bridge Interface configuration page. This includes IPv6 traffic, STP (Spanning Tree Protocol), and unrecognized IP types.

Non IPv4 traffic is not handled by Transparent Mode, and is dropped and logged.

VLAN traffic

VLAN traffic is passed through the L2 Bridge, and is fully inspected by the Stateful and Deep Packet Inspection engines.

VLAN subinterfaces can be created and can be given Transparent Mode Address Object assignments, but the VLANs will be terminated by the firewall rather than passed.

VLAN subinterfaces

VLAN subinterfaces can be configured on Bridge-Pair interfaces, but they will be passed through the bridge to the Bridge-Partner unless the destination IP address in the VLAN frame matches the IP address of the VLAN subinterface on the firewall, in which case it will be processed (for example, as management traffic).

VLAN subinterfaces can be assigned to physical interfaces operating in Transparent Mode, but their mode of operation will be independent of their parent. These VLAN subinterfaces can also be given Transparent Mode Address Object assignments, but in any event VLAN subinterfaces will be terminated rather than passed.

Dynamic addressing

Although a Primary Bridge Interface may be assigned to the WAN zone, only static addressing is allowable for Primary Bridge Interfaces.

Although Transparent Mode employs the Primary WAN as a master interface, only static addressing is allowable for Transparent Mode.

VPN support

VPN operation is supported with one additional route configured. See VPN Integration with Layer 2 Bridged Mode for details.

VPN operation is supported with no special configuration requirements.

DHCP support

DHCP can be passed through a Bridge-Pair.

Interfaces operating in Transparent Mode can provide DHCP services, or they can pass DHCP using IP Helper.

Routing and NAT

Traffic is intelligently routed in/out of the L2 Bridge-Pair from/to other paths. By default, traffic will not be NATed from one Bridge-Pair interface to the Bridge-Partner, but it can be NATed to other paths, as needed. Custom routes and NAT policies can be added as needed.

Traffic is intelligently routed from/to other paths. By default, traffic will not be NATed from/to the WAN to/from Transparent Mode interface, but it can be NATed to other paths, as needed. Custom routes and NAT policies can be added as needed.

Stateful Packet Inspection

Full stateful packet inspection will be applied to all IPv4 traffic traversing the L2 Bridge for all subnets, including VLAN traffic on firewalls.

Full stateful packet inspection will applied to traffic from/to the subnets defined by Transparent Mode Address Object assignment.

Security services

All security services (GAV, IPS, Anti-Spy, CFS) are fully supported. All regular IP traffic, as well as all 802.1Q encapsulated VLAN traffic.

All security services (GAV, IPS, Anti-Spy, CFS) are fully supported from/to the subnets defined by Transparent Mode Address Object assignment.

Broadcast traffic

Broadcast traffic is passed from the receiving Bridge-Pair interface to the Bridge-Partner interface.

Broadcast traffic is dropped and logged, with the possible exception of NetBIOS which can be handled by IP Helper.

Multicast traffic

Multicast traffic is inspected and passed across L2 Bridge-Pairs providing Multicast has been activated on the Firewall > Multicast page. It is not dependent upon IGMP messaging, nor is it necessary to enable multicast support on the individual interfaces.

Multicast traffic, with IGMP dependency, is inspected and passed by Transparent Mode providing Multicast has been activated on the Firewall > Multicast page, and multicast support has been enabled on the relevant interfaces.

Benefits of Transparent Mode over L2 Bridged Mode

Two interfaces are the maximum allowed in an L2 Bridge Pair. If more than two interfaces are required to operate on the same subnet, Transparent Mode should be considered.

L2 Bridge Path Determination

Packets received by the firewall on Bridge-Pair interfaces must be forwarded along to the appropriate and optimal path toward their destination, whether that path is the Bridge-Partner, some other physical or sub interface, or a VPN tunnel. Similarly, packets arriving from other paths (physical, virtual or VPN) bound for a host on a Bridge-Pair must be sent out over the correct Bridge-Pair interface.

The following summary describes, in order, the logic applied to path determinations for these cases:

1
If present, the most specific non-default route to the destination is chosen. This would cover, for example:
a
A packet arriving on X3 (non-L2 Bridge LAN) destined for host 15.1.1.100 subnet, where a route to the 15.1.1.0/24 subnet exists through 192.168.0.254 via the X0 (Secondary Bridge Interface, LAN) interface. The packet would be forwarded via X0 to the destination MAC address of 192.168.0.254, with the destination IP address 15.1.1.100.
b
A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.100, where a route to the 10.0.1.0/24 exists through 192.168.10.50 via the X5 (DMZ) interface. The packet would be forwarded via X5 to the destination MAC address of 192.168.10.50, with the destination IP address 10.0.1.100.
2
If no specific route to the destination exists, an ARP cache lookup is performed for the destination IP address. A match will indicate the appropriate destination interface. This would cover, for example:
a
A packet arriving on X3 (non-L2 Bridge LAN) destined for host 192.168.0.100 (residing on L2 Primary Bridge Interface X2). The packet would be forwarded via X2 to the known destination MAC and IP address of 192.168.0.100, as derived from the ARP cache.
b
A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host 10.0.1.10 (residing on X5 – DMZ). The packet would be forwarded via X5 to the known destination MAC and IP address of 10.0.1.10, as derived from the ARP cache.
3
If no ARP entry is found:
a
If the packet arrives on a Bridge-Pair interface, it is sent to the Bridge-Partner interface.
b
If the packet arrives from some other path, the firewall will send an ARP request out both interfaces of the Bridge-Pair to determine on which segment the destination IP resides.

In this last case, since the destination is unknown until after an ARP response is received, the destination zone also remains unknown until that time. This precludes the firewall from being able to apply the appropriate Access Rule until after path determination is completed. Upon completion, the correct Access Rule will be applied to subsequent related traffic.

With regard to address translation (NAT) of traffic arriving on an L2 Bridge-Pair interface:

1
If it is determined to be bound for the Bridge-Partner interface, no IP translation (NAT) will be performed.
2
If it is determined to be bound for a different path, appropriate NAT policies will apply:
a
If the path is another connected (local) interface, there will likely be no translation. That is, it will effectively be routed as a result of hitting the last-resort Any->Original NAT Policy.
b
If the path is determined to be via the WAN, then the default Auto-added [interface] outbound NAT Policy for X1 WAN will apply, and the packet’s source will be translated for delivery to the Internet. This is common in the case of Mixed-Mode topologies as described in Internal Security.

L2 Bridge Interface Zone Selection

Bridge-Pair interface zone assignment should be done according to your network’s traffic flow requirements. Unlike Transparent Mode, which imposes a system of “more trusted to less trusted” by requiring that the source interface be the Primary WAN, and the transparent interface be Trusted or Public, L2 Bridged Mode allows for greater control of operational levels of trust. Specifically, L2 Bridged Mode allows for the Primary and Secondary Bridge Interfaces to be assigned to the same or different zones (for example, LAN+LAN, LAN+DMZ, WAN+CustomLAN) This affects not only the default Access Rules that are applied to the traffic, but also the manner in which Deep Packet Inspection security services are applied to the traffic traversing the bridge. Important areas to consider when choosing and configuring interfaces to use in a Bridge-Pair are Security Services, Access Rules, and WAN connectivity:

Security Services Directionality

As it will be one of the primary employments of L2 Bridged Mode, understanding the application of security services is important to the proper zone selection for Bridge-Pair interfaces. Security services applicability is based on the following criteria:

1
The direction of the service:
GAV is primarily an Inbound service, inspecting inbound HTTP, FTP, IMAP, SMTP, POP3, and TCP Streams. It also has an additional Outbound element for SMTP.
Anti Spyware is primarily Inbound, inspecting inbound HTTP, FTP, IMAP, SMTP, POP3 for the delivery (i.e. retrieval) of Spyware components as generally recognized by their class IDs. It also has an additional Outbound component, where Outbound is used relative to the directionality (namely, Outgoing) ascribed to it by the IPS signatures that trigger the recognition of these Spyware components. The Outgoing classifier (described in the table below) is used because these components are generally retrieved by the client (for example, LAN host) via HTTP from a Web-server on the Internet (WAN host). Referring to the table below, that would be an Outgoing connection, and requires a signature with an Outgoing directional classification.
IPS has three directions: Incoming, Outgoing, and Bidirectional. Incoming and Outgoing are described in the table below, and Bidirectional refers to all points of intersection on the table.
For additional accuracy, other elements are also considered, such as the state of the connection (for example, SYN or Established), and the source of the packet relative to the flow (for example, initiator or responder).
2
The direction of the traffic. The direction of the traffic as it pertains to IPS is primarily determined by the Source and Destination zone of the traffic flow. When a packet is received by the firewall, its source zone is generally immediately known, and its destination zone is quickly determined by doing a route (or VPN) lookup.

Based on the source and destination, the packet’s directionality is categorized as either Incoming or Outgoing, (not to be confused with Inbound and Outbound) where the criteria shown in IPS: Direction of traffic is used to make the determination.

IPS: Direction of traffic 1

Dest/Src

Untrusted

Public

Wireless

Encrypted

Trusted

Multicast

Untrusted

Incoming

Incoming

Incoming

Incoming

Incoming

Incoming

Public

Outgoing

Outgoing

Outgoing

Incoming

Incoming

Incoming

Wireless

Outgoing

Outgoing

Trust

Trust

Trust

Incoming

Encrypted

Outgoing

Outgoing

Trust

Trust

Trust

Outgoing

Trusted

Outgoing

Outgoing

Trust

Trust

Trust

Outgoing


1
Table data is subject to change.

In addition to this categorization, packets traveling to/from zones with levels of additional trust, which are inherently afforded heightened levels of security (LAN|Wireless|Encrypted <--> LAN|Wireless|Encrypted) are given the special Trust classification. Traffic with the Trust classification has all signatures applied (Incoming, Outgoing, and Bidirectional).

3
The direction of the signature. This pertains primarily to IPS, where each signature is assigned a direction by SonicWall’s signature development team. This is done as an optimization to minimize false positives. Signature directions are:
Incoming – Applies to Incoming and Trust. The majority of signatures are Incoming, and they include all forms of application exploits and all enumeration and footprinting attempts. Approximately 85% of signatures are Incoming.
Outgoing – Applies to Outgoing and Trust. Examples of Outgoing signatures would include IM and P2P login attempts, and responses to successfully launched exploits (for example, Attack Responses). Approximately 10% of signatures are Outgoing.
Bidirectional – Applies to all. Examples of Bidirectional signatures would include IM file transfers, various NetBIOS attacks (for example, Sasser communications) and a variety of DoS attacks (for example, UDP/TCP traffic destined to port 0). Approximately 5% of signatures are Bidirectional.
4
Zone application. For a signature to be triggered, the desired security service must be active on at least one of the zones it traverses. For example, a host on the Internet (X1, WAN) accessing a Microsoft Terminal Server (on X3, Secondary Bridge Interface, LAN) will trigger the Incoming signature “IPS Detection Alert: MISC MS Terminal server request, SID: 436, Priority: Low” if IPS is active on the WAN, the LAN, or both.
Access Rule Defaults

Default, zone-to-zone Access Rules. The default Access Rules should be considered, although they can be modified as needed. The defaults are shown in Access rule defaults:

Access rule defaults

WAN Connectivity

Internet (WAN) connectivity is required for stack communications, such as licensing, security services signature downloads, NTP (time synchronization), and CFS (Content Filtering Services). At present, these communications can only occur through the Primary WAN interface. If you require these types of communication, the Primary WAN should have a path to the Internet. Whether or not the Primary WAN is employed as part of a Bridge-Pair will not affect its ability to provide these stack communications.

* 
NOTE: If Internet connectivity is not available, licensing can be performed manually and signature updates can also be performed manually (http://www.mysonicwall.com/).

Sample Topologies

The following are sample topologies depicting common deployments. Inline Layer 2 Bridged Mode represents the addition of a SonicWall Security Appliance to provide security services in a network where an existing firewall is in place. Perimeter Security represents the addition of a SonicWall Security Appliance in pure L2 Bridged Mode to an existing network, where the firewall is placed near the perimeter of the network. Internal Security represents the full integration of a SonicWall Security Appliance in mixed-mode, where it provides simultaneous L2 bridging, WLAN services, and NATed WAN access. Layer 2 Bridged Mode with High Availability represents the mixed-mode scenario where the firewall HA pair provide high availability along with L2 bridging. Layer 2 Bridged Mode with SSL VPN represents the scenario where a SonicWall SMA SSL VPN or SonicWall SSL VPN Series appliance is deployed in conjunction with L2 Bridged Mode.

Topics:  
Wireless Layer 2 Bridge
* 
NOTE: Wireless Layer 2 Bridge does not apply to the SuperMassive 9800.

In wireless mode, after bridging the wireless (WLAN) interface to a LAN or DMZ zone, the WLAN zone becomes the secondary bridged interface, allowing wireless clients to share the same subnet and DHCP pool as their wired counterparts.

To configure a WLAN to LAN Layer 2 interface bridge:
1
Navigate to the Network > Interfaces page in the SonicOS management interface.
2
Click the Configure icon for the wireless interface you wish to bridge. The Edit Interface dialog displays.
* 
TIP: If you have a Virtual Access Point configured, then you already have a VLAN interface under an interface, such as X4, in the WLAN zone, and your Virtual Access Point is configured to use that VLAN ID.
3
Select Layer 2 Bridged Mode as the Mode / IP Assignment from the drop-down men.
* 
NOTE: Although a general rule is automatically created to allow traffic between the WLAN zone and your chosen bridged interface, WLAN zone type security properties still apply. Any specific rules must be manually added.
4
Select the Interface to which the WLAN should be bridged from the Bridged To drop-down menu. In this instance, the X0 (default LAN zone) is chosen.
5
Configure the remaining options normally. For more information on configuring WLAN interfaces, see Configuring Wireless Interfaces.
Inline Layer 2 Bridged Mode

This method is useful in networks where there is an existing firewall that will remain in place, but you wish to utilize the firewall’s security services without making major changes to the network. By placing the firewall in Layer 2 Bridged Mode, the X0 and X1 interfaces become part of the same broadcast domain/network (that of the X1 WAN interface).

This example refers to a SonicWall Security Appliance installed in a Hewlett Packard ProCurve switching environment. SonicWall is a member of HP’s ProCurve Alliance – more details can be found at the following location: http://www.procurve.com/alliance/members/sonicwall.htm.

HP’s ProCurve Manager Plus (PCM+) and HP Network Immunity Manager (NIM) server software packages can be used to manage the switches as well as some aspects of the SonicWall Security Appliance.

To configure inline Layer 2 bridged mode:
1
Navigate to the Network > Interfaces page.
2
Click the Configure icon for the X0 LAN interface.
3
On the Edit Interface dialog, set the IP Assignment to Layer 2 Bridged Mode (IP Route Option). The options change.

4
Set the Bridged To: interface to X1.
5
To block all non-IP traffic on the bridged pair, select the Block all non-IP traffic checkbox. This option is not selected by default.
6
To prevent traffic from being routed on the bridged pair, select the Never route traffic on this bridge-pair checkbox. This option is not selected by default.
7
To only sniff traffic on the bridged pair, select the Only sniff traffic on this bridge-pair checkbox. This option is not selected by default.
8
To prevent stateful inspection on the bridged pair, select the Disable stateful-inspection on this bridge-pair checkbox. This option is not selected by default.
9
Ensure the interface is configured for HTTPS and SNMP so it can be managed from the DMZ by PCM+/NIM.
10
Configure the remaining options normally.
11
Click OK to save and activate the change.

You will also need to make sure to modify the firewall access rules to allow traffic from the LAN to WAN, and from the WAN to the LAN, otherwise traffic will not pass successfully. You may also need to modify routing information on your firewall if your PCM+/NIM server is placed on the DMZ.

Perimeter Security

Perimeter Security is a network scenario where the firewall is added to the perimeter for the purpose of providing security services (the network may or may not have an existing firewall between the firewall and the router). In this scenario, everything below the firewall (the Primary Bridge Interface segment) will generally be considered as having a lower level of trust than everything to the left of the firewall (the Secondary Bridge Interface segment). For that reason, it would be appropriate to use X1 (Primary WAN) as the Primary Bridge Interface.

Traffic from hosts connected to the Secondary Bridge Interface (LAN) would be permitted outbound through the firewall to their gateways (VLAN interfaces on the L3 switch and then through the router), while traffic from the Primary Bridge Interface (WAN) would, by default, not be permitted inbound.

If there are public servers, for example, a mail and Web server, on the Secondary Bridge Interface (LAN) segment, an Access Rule allowing WAN -> LAN traffic for the appropriate IP addresses and services could be added to allow inbound traffic to those servers.

Internal Security

A network scenario where the firewall will act as the perimeter security device and secure wireless platform. Simultaneously, it will provide L2 Bridge security between the workstation and server segments of the network without having to readdress any of the workstation or servers.

This typical inter-departmental Mixed Mode topology deployment demonstrates how the firewall can simultaneously Bridge and route/NAT. Traffic to/from the Primary Bridge Interface (Server) segment from/to the Secondary Bridge Interface (Workstation) segment will pass through the L2 Bridge.

As both interfaces of the Bridge-Pair are assigned to a Trusted (LAN) zone, the following will apply:

All traffic will be allowed by default, but Access Rules could be constructed as needed.

Consider, for the point of contrast, what would occur if the X2 (Primary Bridge Interface) was instead assigned to a Public (DMZ) zone: All the Workstations would be able to reach the Servers, but the Servers would not be able to initiate communications to the Workstations. While this would probably support the traffic flow requirements (i.e. Workstations initiating sessions to Servers), it would have two undesirable effects:

The DHCP server would be in the DMZ. DHCP requests from the Workstations would pass through the L2 Bridge to the DHCP server (192.168.0.100), but the DHCP offers from the server would be dropped by the default DMZ->LAN Deny Access Rule. An Access Rule would have to be added, or the default modified, to allow this traffic from the DMZ to the LAN.
Security services directionality would be classified as Outgoing for traffic from the Workstations to the Server since the traffic would have a Trusted source zone and a Public destination zone. This might be sub-optimal since it would provide less scrutiny than the Incoming or (ideally) Trust classifications.
Security services directionality would be classified as Trust, and all signatures (Incoming, Outgoing, and Bidirectional) will be applied, providing the highest level of security to/from both segments.

For detailed instructions on configuring interfaces in Layer 2 Bridged Mode, see Configuring Layer 2 Bridged Mode

Layer 2 Bridged Mode with High Availability

This method is appropriate in networks where both High Availability (HA) and Layer 2 Bridged Mode are desired. This example is for SonicWall Security Appliances, and assumes the use of switches with VLANs configured. See Internal security example: Both High Availability and Layer 2 Bridged Mode are desired.

Internal security example: Both High Availability and Layer 2 Bridged Mode are desired

The firewall HA pair consists of two firewalls, connected together on port X5, the designated HA port. Port X1 on each appliance is configured for normal WAN connectivity and is used for access to the management interface of that device. Layer 2 Bridged Mode is implemented with port X0 bridged to port X2.

When setting up this scenario, there are several things to take note of on both the firewalls and the switches.

On the firewalls:

Do not enable the Virtual MAC option when configuring High Availability. In a Layer 2 Bridged Mode configuration, this function is not useful.
Enabling Preempt Mode is not recommended in an inline environment such as this. If Preempt Mode is required, follow the recommendations in the documentation for your switches, as the trigger and failover time values play a key role here.
Consider reserving an interface for the management network (this example uses X1). If it is necessary to assign IP addresses to the bridge interfaces for probe purposes or other reasons, SonicWall recommends using the management VLAN network assigned to the switches for security and administrative purposes.
* 
NOTE: The IP addresses assigned for HA purposes do not directly interact with the actual traffic flow.

On the switches:

Using multiple tag ports: As shown in the above diagram, two tag (802.1q) ports were created for VLAN 100 on both the Edge switch (ports 23 and 24) and Core switch (C24 - D24). The appliances are connected inline between these two switches. In a high performance environment, it is usually recommended to have Link Aggregation/ Port Trunking, Dynamic LACP, or even a completely separate link designated for such a deployment (using OSPF), and the fault tolerance of each of the switches must be considered. Consult your switch documentation for more information.
On HP ProCurve switches, when two ports are tagged in the same VLAN, the port group will automatically be placed into a failover configuration. In this case, as soon as one port fails, the other one becomes active.
Layer 2 Bridged Mode with SSL VPN

This sample topology covers the proper installation of a SonicWall network security appliance into your existing SonicWall EX-Series SSL VPN or SonicWall SSL VPN networking environment. By placing the appliance into Layer 2 Bridged Mode, with an internal, private connection to the SSL VPN appliance, you can scan for viruses, spyware, and intrusions in both directions. In this scenario the firewall is not used for security enforcement, but instead for bidirectional scanning, blocking viruses and spyware, and stopping intrusion attempts. When programmed correctly, the network security appliance will not interrupt network traffic, unless the behavior or content of the traffic is determined to be undesirable. Both one- and two-port deployments of the SonicWall Security Appliance are covered in this section.

WAN to LAN Access Rules

Because the network security appliance will be used in this deployment scenario only as an enforcement point for anti-virus, anti-spyware and intrusion prevention, its existing security policy must be modified to allow traffic to pass in both directions between the WAN and LAN.

To allow traffic to pass in both directions between WAN and LAN:
1
Navigate to the Firewall > Access Rules page.
2
Click the Configure icon for the intersection of WAN to LAN traffic.
3
Click the Configure icon next to the default rule that implicitly blocks uninitiated traffic from the WAN to the LAN.
4
In the Edit Rule dialog, select Allow for the Action setting,.
5
Click OK.
Configure the Network Interfaces and Activate L2B Mode

In this scenario the WAN interface is used for the following:

Access to the management interface for the administrator
Subscription service updates on MySonicWall
The default route for the device and subsequently the “next hop” for the internal traffic of the SSL VPN appliance (this is why the WAN interface must be on the same IP segment as the internal interface of the SSL VPN appliance)

The LAN interface on the network security appliance is used to monitor the unencrypted client traffic coming from the external interface of the SSL VPN appliance. This is the reason for running in Layer 2 Bridged Mode (instead of reconfiguring the external interface of the SSL VPN appliance to see the LAN interface as the default route).

On the Network > Interfaces page of the SonicOS management interface, click the Configure icon for the WAN interface, and then assign it an address that can access the Internet so that the appliance can obtain signature updates and communicate with NTP.

The gateway and internal/external DNS address settings will match those of your SSL VPN appliance:

IP address: This must match the address for the internal interface on the SSL VPN appliance.
Subnet Mask, Default Gateway, and DNS Server(s): Make these addresses match your SSL VPN appliance settings.

For the Management setting, select the HTTPS and Ping check boxes. Click OK to save and activate the changes.

To configure the LAN interface settings:
1
Navigate to the Network > Interfaces page.
2
Click the Configure icon for the LAN interface.
3
For the IP Assignment setting, select Layer 2 Bridged Mode. For the Bridged to setting, select X1.
4
If you also need to pass VLAN tagged traffic, supported on firewalls, click the VLAN Filtering tab and add all of the VLANs that will need to be passed.
5
Click OK to save and activate the change.

You may be automatically disconnected from the network security appliance’s management interface. You can now disconnect your management laptop or desktop from the appliance’s X0 interface and power the appliance off before physically connecting it to your network.

Install the Firewall between the Network and SSL VPN Appliance

Regardless of your deployment method (single- or dual-homed), the firewall should be placed between the X0/LAN interface of the SSL VPN appliance and the connection to your internal network. This allows the device to connect out to SonicWall’s licensing and signature update servers, and to scan the decrypted traffic from external clients requesting access to internal network resources.

If your SSL VPN appliance is in two-port mode behind a third-party firewall, it is dual-homed.

To connect a dual-homed SSL VPN appliance:
1
Cable the X0/LAN port on the network security appliance to the X0/LAN port on the SSL VPN appliance.
2
Cable the X1/WAN port on the network security appliance to the port where the SSL VPN was previously connected.
3
Power on the appliance.

If your SSL VPN appliance is in one-port mode in the DMZ of a third-party firewall, it is single-homed.

To connect a single-homed SSL VPN appliance:
1
Cable the X0/LAN port on the network security appliance to the X0/LAN port of the SSL VPN appliance.
2
Cable the X1/WAN port on the network security appliance to the port where the SSL VPN was previously connected.
3
Power on the appliance.
Configure or Verify Settings

From a management station inside your network, you should now be able to access the management interface on the network security appliance using its WAN IP address.

To configure or verify settings:
1
Make sure that all security services for the SonicWall Security Appliance are enabled. See Licensing Services and Activating Security Services on Each Zone.
2
SonicWall Content Filtering Service must be disabled before the device is deployed in conjunction with a SonicWall SMA SSL VPN appliance.
a
Navigate to the Network > Zones page/
b
Click Configure next to the LAN (X0) zone.
c
Clear the Enforce Content Filtering Service checkbox.
d
Click OK.
3
If you have not yet changed the administrative password on the SonicWall Security Appliance, you can do so on the System > Administration page.
4
To test access to your network from an external client, connect to the SSL VPN appliance and log in.
5
When connected, attempt to access to your internal network resources. If there are any problems, review your configuration and see Configuring the Common Settings for L2 Bridged Mode Deployments.

Configuring Layer 2 Bridged Mode

Topics:  

Configuration Task List for Layer 2 Bridged Mode

Choose a topology that suits your network
License security services
Disable DHCP server
Configure and enable SNMP and HTTP/HTTPS management
Enable syslog
Activate security services on affected zones
Create firewall access rules
Configure log settings
Configure wireless zone settings
* 
NOTE: Wireless zone settings do not apply to the SuperMassive 9800.
Select the zone for the Primary Bridge Interface
Activate management
Activate security services
Select the zone for the Secondary Bridge Interface
Activate management
Activate security services
Apply security services to the appropriate zones

Configuring the Common Settings for L2 Bridged Mode Deployments

The following settings need to be configured on your SonicWall Security Appliance prior to using it in most of the Layer 2 Bridged Mode topologies:

Licensing Services

When the appliance is successfully registered, go to the System > Licenses page and click Synchronize under Manage Security Services Online. This will contact the firewall licensing server and ensure that the appliance is properly licensed.

To check licensing status, go to the System > Status page and view the license status of all the security services (Gateway Anti-Virus, Anti-Spyware, and Intrusion Prevention).

Disabling DHCP Server

When using a SonicWall Security Appliance in Layer 2 Bridged Mode in a network configuration where another device is acting as the DHCP server, you must first disable its internal DHCP engine, which is configured and running by default.

To disable the DHCP server:
1
On the Network > DHCP Server page, clear the Enable DHCP Server checkbox.
2
Click the Accept button.
Configuring SNMP Settings
To configure SNMP settings:
1
Navigate to the System > Administration page.
2
Select the Enable SNMP checkbox.
3
Click the Accept button. The Configure button becomes active and the SNMP information is populated.
4
Click the Configure button. The Configure SNMP dialog displays. For how to configure SNMP, see Setting Up SNMP Access.
Enabling SNMP and HTTPS on the Interfaces
To enable SNMP and HTTPS on the interfaces:
1
Navigate to the Network > Interfaces page.
2
Click the Edit icon for the interface through which you manage the appliance. The Edit Interface dialog displays.
3
For the Management option, enable HTTPS and SNMP.
4
Click OK.
Enabling Syslog

You enable Syslog on the Log > Syslog page. For how to enable Syslog, see Configuring Syslog Settings.

Activating Security Services on Each Zone

On the Network > Zones page, for each zone you will be using, make sure that the security services are activated.

Then, on the Security Services page for each service, activate and configure the settings that are most appropriate for your environment.

See these Security Services pages:

Security Services > Gateway Anti-Virus settings

Security Services > Intrusion Prevention Settings

Security Services > Anti-Spyware settings

Creating Firewall Access Rules

If you plan to manage the appliance from a different zone, or if you will be using a server such as the HP PCM+/NIM server for management, SNMP, or syslog services, create access rules for traffic between the zones. On the Firewall > Access Rules page, click on the icon for the intersection of the zone of the server and the zone that has users and servers (your environment may have more than one of these intersections). Create a new rule to allow the server to communicate with all devices in that zone.

Configuring Log Settings
To configure log settings:
1
On the Log > Settings page, set the priority and other log settings.

2
Go to the Log > Name Resolution page.

3
Set the Name Resolution Method to DNS then NetBios.
4
Click Accept to save and activate the change.
Configuring Wireless Zone Settings
* 
NOTE: Wireless Zone settings do not apply to the SuperMassive 9800.

When you are using a HP PCM+/NIM system, if it will be managing a HP ProCurve switch on an interface assigned to a WLAN/Wireless zone, you will need to deactivate two features; otherwise, you will not be able to manage the switch. Go to the Network > Zones page and select your Wireless zone. On the Wireless tab, clear the checkboxes next to Only allow traffic generated by a SonicPoint and WiFiSec Enforcement. Click OK to save and activate the change.

Configuring Layer 2 Bridged Mode Procedure

Refer to the L2 Bridge Interface Zone Selection for choosing a topology that best suits your network. In this example, we will be using a topology that most closely resembles the Simple L2 Bridge Topology.

Choose an interface to act as the Primary Bridge Interface. Refer to the L2 Bridge Interface Zone Selection for information in making this selection. In this example, we will use X1 (automatically assigned to the Primary WAN):

Topics:  
Configuring the Primary Bridge Interface
To configure the primary bridge interface:
1
Navigate to Network > Interfaces.
2
Click the Configure icon in the right column of the X1 (WAN) interface.
3
Configure the interface with a Static IP address (for example, 192.168.0.12).
* 
NOTE: The Primary Bridge Interface must have a Static IP assignment.
4
For WAN interfaces only:
a
Configure the default gateway. This is required for the security appliance itself to reach the Internet.
b
Configure the DNS server.
5
Select one or more Management options for the interface: HTTPS, Ping (selected by default), SNMP, SSH.
* 
NOTE: Selecting HTTPS activates and selects Add rule to enable redirect from HTTP to HTTPS automatically.
6
Select User Login options: HTTP, HTTPS.
7
To enable redirect to HTTPS from HTTP, select the Add rule to enable redirect from HTTP to HTTPS checkbox. For more information about this option, see HTTP/HTTPS Redirection.
8
Click OK.

Choose an interface to act as the Secondary Bridge Interface. Refer to the L2 Bridge Interface Zone Selection for information in making this selection.

Configuring the Secondary Bridge Interface

In this example, we use X0 (automatically assigned to the LAN):

1
Navigate to Network > Interfaces.
2
Click the Configure icon in the right column of the X0 (LAN) interface.
3
In the IP Assignment drop-down menu, select Layer 2 Bridged Mode.
4
In the Bridged to drop-down menu, select the X1 interface.
5
Select one or more Management options for the interface: HTTPS, Ping (selected by default), SNMP, SSH.
* 
NOTE: Selecting HTTPS activates and selects Add rule to enable redirect from HTTP to HTTPS automatically.
6
Select User Login options: HTTP, HTTPS.
7
To enable redirect to HTTPS from HTTP, select the Add rule to enable redirect from HTTP to HTTPS checkbox. For more information about this option, see HTTP/HTTPS Redirection.
8
You may optionally enable the Block all non-IPv4 traffic setting to prevent the L2 bridge from passing non-IPv4 traffic.
9
To control VLAN traffic through the L2 bridge, click the VLAN Filtering tab. By default, all VLANs are allowed:
Select Block listed VLANs (blacklist) from the drop-down list and add the VLANs you wish to block from the left pane to the right pane. All VLANs added to the right pane will be blocked, and all VLANs remaining in the left pane will be allowed.
Select Allow listed VLANs (whitelist) from the drop-down list and add the VLANs you wish to explicitly allow from the left pane to the right pane. All VLANs added to the right pane will be allowed, and all VLANs remaining in the left pane will be blocked.
10
Click OK. The Network > Interfaces page displays the updated configuration:

You may now apply security services to the appropriate zones, as desired. In this example, they should be applied to the LAN, WAN, or both zones.

Configuring an L2 Bypass for Hardware Failures

An L2 bypass enables you to perform a physical bypass of the firewall when an interface is bridged to another interface with LAN bypass capability. This allows network traffic to continue flowing if an unrecoverable firewall error occurs.

When the L2 bypass relay is closed, the network cables attached to the bypassed interfaces (X0 and X1) are physically connected as if they were a single continuous network cable. The Engage physical bypass on malfunction option provides the user the choice of avoiding disruption of network traffic by bypassing the firewall in the event of a malfunction.

L2 bypass is only applicable to interfaces in Layer 2 Bridged Mode. The Engage physical bypass on malfunction option only appears when the Layer 2 Bridged Mode option is selected from the Mode / IP Assignment menu. This option does not appear unless a physical bypass relay exists between the two interfaces of the bridge-pair.

When the Engage physical bypass on malfunction option is enabled, the other Layer 2 Bridged Mode options are automatically set as follows:

Block all non-IPv4 traffic – disabled. When enabled, this option blocks all non-IPv4 Ethernet frames. So, this option is disabled.
Never route traffic on this bridge-pair – enabled. When enabled, this option prevents packets from being routed to a network other than the peer network of the bridged pair. So, this option is enabled.
Only sniff traffic on this bridge-pair – disabled. When enabled, traffic received on the bridge-pair interface is never forwarded. So, this option is disabled.
Disable stateful-inspection on this bridge-pair – unchanged. This option is not affected.
To configure an L2 bypass:
1
Go to the Network > Interfaces page.
2
Click on the Edit icon in the Configure column for the interface you want to configure. The Edit Interface dialog displays.

3
Select the Engage physical bypass on malfunction checkbox
* 
NOTE: The Engage physical bypass on malfunction checkbox is available only when the X0 and X1 interfaces are bridged together on an NSA-6600 or above.
4
Click OK to configure the interface.

VLAN Integration with Layer 2 Bridged Mode

VLANs are supported on SonicWall Security Appliances. When a packet with a VLAN tag arrives on a physical interface, the VLAN ID is evaluated to determine if it is supported. The VLAN tag is stripped, and packet processing continues as it would for any other traffic. A simplified view of the inbound and outbound packet path includes the following potentially reiterative steps:

IP validation and reassembly
Decapsulation (802.1q, PPP)
Decryption
Connection cache lookup and management
Route policy lookup
NAT Policy lookup
Access Rule (policy) lookup
Bandwidth management
NAT translation
Advanced Packet Handling (as applicable)
TCP validation
Management traffic handling
Content Filtering
Transformations and flow analysis (on SonicWall Security Appliances): H.323, SIP, RTSP, ILS/LDAP, FTP, Oracle, NetBIOS, Real Audio, TFTP
IPS and GAV

At this point, if the packet has been validated as acceptable traffic, it is forwarded to its destination. The packet egress path includes:

Encryption
Encapsulation
IP fragmentation

On egress, if the route policy lookup determines that the gateway interface is a VLAN subinterface, the packet is tagged (encapsulated) with the appropriate VLAN ID header. The creation of VLAN subinterfaces automatically updates the firewall’s routing policy table:

The auto-creation of NAT policies, Access Rules with regard to VLAN subinterfaces behave exactly the same as with physical interfaces. Customization of the rules and policies that govern the traffic between VLANs can be performed with customary SonicOS ease and efficiency.

When creating a zone (either as part of general administration, or as a step in creating a subinterface), a checkbox will be presented on the zone creation page to control the auto-creation of a GroupVPN for that zone. By default, only newly created Wireless type zones have Create GroupVPN for this zone enabled, although the option can be enabled for other zone types by selecting the checkbox during creation.

Management of security services between VLAN subinterfaces is accomplished at the zone level. All security services are configurable and applicable to zones comprising physical interfaces, VLAN subinterfaces, or combinations of physical and VLAN subinterfaces.

Gateway Anti-Virus and Intrusion Prevention Services between the different workgroups can easily be employed with the use of VLAN segmentation, obviating the need for dedicated physical interfaces for each protected segment.

VLAN support enables organizations to offer meaningful internal security (as opposed to simple packet filtering) between various workgroups, and between workgroups and server farms without having to use dedicated physical interfaces on the firewall.

Here the ability to assign VLAN subinterfaces to the WAN zone, and to use the WAN client mode (only Static addressing is supported on VLAN subinterfaces assigned to the WAN zone) is illustrated, along with the ability to support WAN Load Balancing and failover. Also demonstrated is the distribution of SonicPoints throughout the network by means of connecting them to access mode VLAN ports on workgroup switches. These switches are then backhauled to the core switch, which then connects all the VLANs to the appliance via a trunk link.

VPN Integration with Layer 2 Bridged Mode

When configuring a VPN on an interface that is also configured for Layer 2 Bridged Mode, you must configure an additional route to ensure that incoming VPN traffic properly traverses the firewall. Navigate to the Network > Routing page, scroll to the bottom of the page, and click on the Add button. In the Add Route Policy window, configure the route as follows:

Source: ANY
Destination: custom-VPN-address-object (This is the address object for the local VPN tunnel IP address range.)
Service: ANY
Gateway: 0.0.0.0
Interface: X0

Asymmetric Routing

SonicOS 6.2.4.0 introduced support for asymmetric routing. Asymmetric routing is when the flow of packets in one direction passes through a different interface than that used for the return path. This can occur when traffic flows across different layer 2 bridged pair interfaces on the firewall or when it flows across different firewalls in a high availability cluster.

Any network appliance that performs deep packet inspection or stateful firewall activity must “see” all packets associated with a packet flow. This is in contrast to traditional IP routing in which each packet in a flow may technically be forwarded along a different path as long as it arrives at its intended destination — the intervening routers do not have to see every packet. Today’s routers do attempt to forward packets with a consistent next-hop for each packet flow, but this applies only to packets forwarded in one direction. Routers make no attempt to direct return traffic to the originating router. This IP routing behavior presents problems for a firewall cluster that does not support asymmetric routing because the set of Cluster Nodes all provide a path to the same networks. Routers forwarding packets to networks through the cluster may choose any of the Cluster Nodes as the next-hop. The result is asymmetric routing, in which the flow of packets in one direction go through a node different than that used for the return path. This difference in flow causes traffic to be dropped by one or both Cluster Nodes as neither is “seeing” all of the traffic from the flow. See Asymmetric routing.

Asymmetric routing

In Asymmetric routing, PC1 communicates with Server1, two-way traffic passes through different routers, that is, some packets of same connection go through blue path, some go through green path. On such deployment, the routers may run some redundancy route protocol or load balancing protocol. for example.Cisco HSRP protocol.

SonicOS uses stateful inspection. All connections passing through the firewall are bound to interfaces. With support for asymmetric routing, however, SonicOS tracks ingress and egress traffic, even when the flows go across different interfaces, and provides stateful, deep packet inspection.

* 
NOTE: Asymmetric routing is not the same as one-way connections without reply, that is, TCP State Bypass.

Configuring Interfaces for IPv6

For a complete description of configuring IPv6 interfaces, see IPv6 Interface Configuration.

31-Bit Network

SonicOS 6.2.7 introduces support for RFC 3021, which defines the use of a 31-bit subnet mask. This mask allows only two host addresses in the subnet, with no network or gateway address and no broadcast address. Such a configuration can be used within a larger network to connect two hosts with a point-to-point link. The savings in address space resulting from this change is easily seen as each point-to-point link in a large network would consume two addresses instead of four.

In this context, the point-to-point link is not equivalent to PPP (point to point protocol). A point-to-point link using a 31-bit mask can use or not use the PPP protocol. 31-bit prefixed IPv4 addresses on a point-to-point link can also be used in the Ethernet network.

Topics:  

Example Network Environment

In this network environment, Host PC1 and Host PC2 can visit each other, while hosts in the LAN network can visit Host PC2.

To configure settings for this environment:
1
For Host PC1, add two route entries:
Route add 10.5.10.0 mask 255.255.255.0 15.6.8.10
Route add 10.102.234.0 mask 255.255.255.0 15.6.8.10
2
For Host PC2, add two route entries:
Route add 10.5.10.0 mask 255.255.255.0 10.102.234.70
Route add 15.6.8.0 mask 255.255.255.0 10.102.234.70
3
On the Cisco router (F0/0):
interface fastEthernet 0/0
ip address 10.5.10.120 255.255.255.254
4
On the Cisco 2811, add one route entry:

!

ip route 15.6.8.0 255.255.255.0 10.5.10.120

!

5
On the firewall, add one route entry to enable the WAN zone data flow from X2 to X5, and X5 to X2:

Any    10.102.234.0    Any    X2 Default Gateway    X2

Configuring SonicOS

To configure an interface for a 31-bit subnet:
1
On the Network > Interfaces page, edit the desired interface.
2
Set the Subnet Mask to 255.255.255.254.

3
Enter one host IP address into the IP Address field.
4
Enter the other host IP address into the Default Gateway field.
5
Set the other fields according to your network, as needed.
6
Click OK.

PPPoE Unnumbered Interface Support

A PPPoE Unnumbered interface allows you to manage a range of IP addresses with only a single PPPoE connection. The Internet Service Provider (ISP) provides multiple static IP addresses that can be allocated within a subnet. The first address is designated as the network address, and the last one as the broadcast address.

The default MTU of PPPoE is 1492.

Topics:  

Sample Network Topography

In this topology, X2 is the PPPoE unnumbered interface, and X3 is an unnumbered interface.

SonicOS adds two policies to the Network > Routing Route Policies table:

SonicOS also adds two NAT policies:

Caveats

To change X3 to another mode when X2 unnumbered to X3 is configured, first terminate the relationship with X2 by changing X2 to another mode. Otherwise, if you change the IP address or mask of interface X3, it causes X3 to reconnect to the PPPoE server.

If X3 is set as unnumbered interface, other interfaces cannot connect to X3 using an L2 Bridge.

Configuring a PPPoE Unnumbered Interface

* 
NOTE: Configuring a PPPoE unnumbered interface is not supported on the SuperMassive 9800.
To configure a PPPoE unnumbered interface:
1
Configure the PPPoE client settings on a WAN interface by clicking its Edit icon:

2
Select Unnumbered interface. The drop-down menu activates.
3
Select Create new unnumbered Interface. The Add Unnumbered Interface dialog displays.

4
For Zone, select LAN, DMZ, or create a new zone.
* 
NOTE: The Mode / IP Assignment drop-down menu is set to IP Unnumbered and dimmed.
5
For IP Address, enter the address provided by your ISP. Usually it is the second IP address assigned by the provider.
6
Enter the subnet mask assigned by the ISP in the Subnet Mask field.
7
Finish configuring this interface.
8
Click OK.
9
Finish configuring the first interface.
10
Click OK.

Configuring HA with PPPoE Unnumbered

For how to configure HA with PPPoE Unnumbered, see Configuring Active/Standby High Availability Settings.

 

Configuring PortShield Interfaces

* 
NOTE: Beginning in Release 6.2.5.1, TZ series firewalls supported Dell X‑Series switches and the SonicWall X‑Series Solution, which expand the capability of the firewalls, especially for portshielding interfaces. Beginning in Release 6.2.7, SM and NSA series firewalls also support X‑Series switches and the X‑Series Solution.
* 
NOTE: The NSA2600 firewall does not support PortShield, and the SM 9800 and SOHO W firewalls do not support the X‑Series Solution.

Network > PortShield Groups

Topics:  

About PortShield

A PortShield interface is a virtual interface with a set of ports, including ports on Dell X-Series, or extended, switches, assigned to it. PortShield architecture enables you to configure some or all of the LAN ports into separate security contexts, providing protection not only from the WAN and DMZ, but between devices inside your network as well. In effect, each context has its own wire-speed PortShield that enjoys the protection of a dedicated, deep packet inspection firewall.

* 
TIP: Zones can always be applied to multiple interfaces in the Network > Interfaces page, even without the use of PortShield groupings. These interfaces, however, do not share the same network subnet unless they are grouped using PortShield.

You can assign any combination of ports to a PortShield interface. All ports not assigned to a PortShield interface are assigned to the LAN interface.

Static Mode and Transparent Mode

There are two IP assignment methods you can deploy to create PortShield interfaces:

Static mode
Transparent mode
Working in Static Mode

When you create a PortShield interface in Static Mode, you manually create an explicit address to be applied to the PortShield interface. All ports mapped to the interface are identified by this address. Static mode is available on interfaces assigned to Trusted, Public, or Wireless zones.

* 
NOTE: When you create a PortShield interface in Static Mode, make sure the IP address you assign to the interface is not already in use by another PortShield interface.
Working in Transparent Mode

Transparent Mode addressing allows for the WAN subnetwork to be shared by the current interface through Address Object assignments. The interface’s IP address is the same as the WAN interface IP address. Transparent mode is available on interfaces assigned to Trusted and Public Zones.

* 
NOTE: Make sure the IP address you assign to the PortShield interface is within the WAN subnetwork.

When you create a PortShield interface in Transparent Mode, you create a range of addresses to be applied to the PortShield interface. You include these addresses in one entity called an Address Object. Address Objects allow for entities to be defined one time and to be re-used in multiple referential instances throughout the SonicOS interface. When you create a PortShield interface using an address object, all ports mapped to the interface are identified by any of the addresses specified in the address range.

* 
NOTE: Each statically addressed PortShield interface must be on a unique subnetwork. You can not overlap PortShield interfaces across multiple subnetworks.

SonicOS Support of X‑Series Switches

Topics:  

About the X‑Series Solution

* 
NOTE: The X‑Series Solution is not supported on the SM 9800, NSA 2600, or SOHO W firewall.

Critical network elements, such as a firewall and switch, need to be managed, usually individually. SonicOS allows unified management of both the firewall and a Dell X‑Series switch using the firewall management interface (UI) and GMS.

The maximum number of interfaces available on the SonicWall firewalls vary depending on the model, as shown in Interfaces per firewall.

 

Interfaces per firewall

Firewall model

Available interfaces

SM 9800

24 (4 10 GbE SFP+, 12 1 GbE SFP, 8 1GE copper), 1 GbE Management, and 1 Console

SM 9600

20 (4 10 GbE SFP+, 8 1 GbE SFP, 8 1GE copper), 1 GbE Management, and 1 Console

SM 9400

20 (4 10 GbE SFP+, 8 1 GbE SFP, 8 1GE copper), 1 GbE Management, and 1 Console

SM 9200

20 (4 10 GbE SFP+, 8 1 GbE SFP, 8 1GE copper), 1 GbE Management, and 1 Console

NSA 6600

20 (4 10 GbE SFP+, 8 1 GbE SFP, 8 1GE copper), 1 GbE Management, and 1 Console

NSA 5600

18 (2 10 GbE SFP+, 4 1 GbE SFP, 12 1GE copper) and 1 Management

NSA 4600

18 (2 10 GbE SFP+, 4 1 GbE SFP, 12 1GE copper) and 1 Management

NSA 3600

18 (2 10 GbE SFP+, 4 1 GbE SFP, 12 1GE copper) and 1 Management

TZ600

10 GbE

TZ500 Series

8 GbE

TZ400 Series

7 GbE

TZ300 Series

5 GbE

In certain deployments, the number of ports required might easily exceed the maximum number of interfaces available on a firewall. With the X‑Series Solution, ports on a Dell X-Series switch are viewed as extended interfaces of the firewall, thereby increasing the number of interfaces available for use up to 192, depending on the X‑Series switch. These extended ports can be portshielded and/or configured for High Availability (HA) and treated as any other interface on the firewall.

* 
NOTE: X‑Series switch, X‑Switch, external switch, and extended switch are used interchangeably.

Beginning in SonicOS Release 6.2.5.1, the TZ Series firewalls supported a maximum of two X‑Series switches. Beginning in SonicOS Release 6.2.7, the SonicWall firewalls shown in X‑Series switches supported by SonicWall firewalls support up to four of the listed X‑Series switches.

* 

X‑Series switches supported by SonicWall firewalls

These SonicWall firewalls

 

 

SuperMassive 9600
SuperMassive 9400
SuperMassive 9200
NSA 6600
NSA 5600
NSA 4600
NSA 3600
TZ600
TZ500/TZ500W
TZ400/TZ400W
TZ300/TZ300W

Support these X‑Series switches (ports)

 

X1008 (8 10/100/1000Base-T GbE)
X1008P (8 10/100/1000Base-T GbE, 2 1GbE SFP fiber, 8 PoE up to 123 W total)
X1018 (16 10/100/1000Base-T GbE, 2 1GbE SFP fiber)
X1018P (16 10/100/1000Base-T GbE, 2 1GbE SFP fiber, 16 PoE up to 246W total)
X1026 (24 10/100/1000Base-T GbE, 2 1GbE SFP fiber)
X1026P (24 10/100/1000Base-T GbE, 2 1GbE SFP fiber, 24 PoE/12 PoE+ up to 369W total)
X1052 (48 10/100/1000Base-T GbE, 2 10GbE SFP/SFP+ fiber)
X1052P (48 10/100/1000Base-T GbE, 24 PoE/12 PoE+ up to 369W total)
X4012 (12 10GbE SFP/SFP+ fiber)
* 
NOTE: The X‑Series Solution is not supported on the SM 9800, NSA 2600, or SOHO W firewalls.
Topics:  
Terminology
 

HA

High Availability

Extended switch

Same as X‑Series switch.

External switch

Same as X‑Series switch.

IDV

Interface Disambiguation via VLAN – The reconfiguring of ports, portshielded to firewall interfaces, on the extended switch as access ports of the VLAN corresponding to the PortShield VLAN.

PoE

Power over Ethernet – A system than passes electrical power along with data on Ethernet cabling, which allows a single cable to provide both data connection and electrical power to devices.

PoE+

Power over Ethernet Plus – An enhanced version of PoE (standard 802.3at) that provides more power than PoE.

SFP

Small form-factor pluggable – A compact, hot-pluggable transceiver used for both telecommunication and data communications applications and supports 1Gb fiber modules.

SFP+

Enhanced small form-factor pluggable – An enhanced version of SFP that supports 10 Gb fiber modules.

SPM

Single Point Management

STP

Spanning Tree Protocol – A network protocol that ensures a loop-free topology for Ethernet networks and allows redundant (spare) links to provide backup paths if an active link fails.

Performance Requirements

With SonicOS 6.2.7, X‑Series switch integration functionality has been extended from just TZ Series firewalls to include both SM Series and NSA Series firewalls. A SonicOS firewall can now

Be provisioned for a maximum of four X‑Series switches.
Manage an increased number of ports.

If multiple switches are provisioned, they must be connected directly to the firewall; they cannot be cascaded or daisy chained, that is, one switch connected to another switch, which is then connected to the firewall.

Key Features Supported with X‑Series Switches
* 
NOTE: For information about these features, see the SonicWall X‑Series Solution Deployment Guide.
Provisioning an X‑Series Switch as an extended switch
PortShield functionality
Configuring extended switch Interface settings
Managing basic extended switch global parameters
Managing the extended switch using GMS
High Availability (HA) with PortShield functionality

In SonicOS 6.2.7, support for PortShield functionality in HA mode is available using Common Uplink. In this configuration, a link between the active/standby firewall and the X‑Series switch serves as a common uplink to carry all the PortShield traffic. In this configuration, firewall interfaces that serve as PortShield hosts should be connected to a separate switch and not the same X‑Series switch connected to the active and standby units. This avoids looping of packets for the same PortShield VLAN. The PortShield members can be connected to ports on the X‑Series switch that is controlled by the active/standby firewall.

Diagnostics support for extended switch
Support for VLANs in a common uplink with SPM configuration
Support for VLANs in a dedicated uplink configuration
Single Point of Management over Common Uplink for VLAN Traffic

In SonicOS 6.2.7, VLANs are also supported with Common Uplink. This allows a single link between the firewall and the X‑Series switch to carry management traffic of the firewall managing the X‑Series switch plus PortShield traffic for the Interface Disambiguation via VLAN (IDV) VLANs corresponding to the firewall interfaces plus traffic for the VLAN sub-interfaces present under the Common Uplink interface.

* 
NOTE: Overlapping VLANs cannot exist under firewall interfaces configured as dedicated uplinks or common uplinks to the same switch. This is because the VLAN space is global on the X‑Series switch.
* 
NOTE: PortShield of Extended Switch Interfaces to Common Uplink Interfaces without selecting any VLANs for access/trunk configuration is not supported.
PoE/PoE+ and SFP/SFP+ functionality for SonicWall firewalls by certain Dell X‑Series switches
Batching configuration messages – To facilitate support of the X‑Series switches, configuration messages can be batched before being sent to an X‑Series switch.
PortShield Functionality and X-Series Switches

PortShield architecture allows configuration of firewall ports into separate security zones, thereby allowing protection of a deep-packet inspection firewall for traffic between devices across zones. For more information about PortShield functionality, see Configuring PortShield Interfaces.

The SonicWall X‑Series Solution allows support for portshielding interfaces on the extended switch to firewall interfaces. X‑Series switches are L2 switches, and by default, all ports on the extended switch are configured as access ports of the default VLAN 1. When ports of the extended switch are portshielded to firewall interfaces, the ports are reconfigured as access ports of the VLAN corresponding to the PortShield VLAN, also known as the IDV VLAN of the PortShield host interface.

Topics:  
Different Traffic Scenarios with PortShield
Traffic between network devices connected to the ports on the extended switch that are part of the same PortShield group are switched automatically by the extended switch.
Traffic between network devices connected to the ports on the extended switch and devices connected to ports on the firewall that are part of the same PortShield group are switched by the internal switch on the firewall.
Traffic between network devices connected to the ports on the extended switch destined to firewall interfaces are handled by the data path in software. Such traffic may be subjected to firewall security services such as access rules, deep packet inspection, and intrusion prevention.
Traffic between network devices connected to the ports on the extended switch and devices connected to ports on the firewall that are part of a different zone or part of a different PortShield group are forwarded by the data path in software. Such traffic is subjected to firewall security services in software.
Prerequisites for Portshielding X-Series Switches
* 
IMPORTANT: If the topology has two or more X‑Series switches, all X‑Series switches must be connected directly to the firewall and not cascaded or daisy chained, that is, one X‑Series switch cannot be connected to another X‑Series switch that is connected to the firewall.
X‑Series switches (excluding X1052/X1052P models) are delivered from the factory in unmanaged mode to avoid unauthorized access to the switch. You need to put the switch into Managed mode by pressing the Mode button, near the power plug, for at least seven seconds.

X1052/X1052P models delivered from the factory are by default in Managed mode.

For further details, see the Dell™ Networking™ X1000 and X4000 Series Switches User Guide and the SonicWall X‑Series Solution Deployment Guide.

During the initial set up of the switch, to ensure the X‑Series switch’s IP does not change dynamically when the DHCP server is enabled on the firewall interfaces, choose Static IP instead of Dynamic IP. For further information, see the SonicWall X‑Series Solution Deployment Guide.

Apart from the initial IP address, username/password configuration, which can be found on the switch, no other configuration is recommended to be performed on the X‑Series switch directly via the switch’s GUI/console. To do so results in the firewall being out-of-sync with the configuration state of the X‑Series switch.
To manage the X‑Series switch from the firewall, one of the interfaces of the firewall must be in the same subnet as the X‑Series switch. For example, to manage an X‑Series switch with a default IP 192.168.2.1, an interface of the firewall needs to be configured in the 192.168.2.0/24 subnet and connected to the X‑Series switch.
Ensure the firewall can reach the X‑Series switch by pinging the X‑Series switch from the firewall before provisioning/managing the switch from the firewall.
VLAN support:
Support for VLANs is available on shared and common uplinks. For example, VLANs can be configured under the firewall interface, which is provisioned as the shared uplink for the X‑Series switch.
For details on VLAN support, see the SonicWall X‑Series Solution Deployment Guide.
Overlapping VLANs cannot exist under firewall interfaces configured as dedicated uplinks. For example, if X3 and X5 are configured for dedicated uplinks, VLAN 100 cannot be present under both X3 and X5. Such a configuration is rejected.
PoE/PoE+ and SFP/SFP+ Support

SonicWall firewalls do not support PoE/PoE+, but this functionality can be added with certain X‑Series switches, as shown in X‑Series switch PoE/PoE+ and SFP/SFP+ support. This additional functionality enhances SonicPoint usage by SonicWall firewalls, especially for new SonicPoints supporting 802.11ac (supports up to 30W maximum power; 802.11a/b/g/h supports up to 15.4 W maximum power).

Some X‑Series switches also support SFP/SFP+, as shown in X‑Series switch PoE/PoE+ and SFP/SFP+ support.

* 
NOTE: Configuration of the PoE/PoE+ ports on the X‑Series switch is managed from the UI of the X‑Series switch and not the Network > PortShield Groups page on the SonicWall firewall.

X‑Series switch PoE/PoE+ and SFP/SFP+ support

This X-Series switch

Supports

X1008

1 PoE PD port; by default, port 8 is the PD port

X1008P

8 PoE ports, up to 123W total; by default, ports 1 through 8 support PoE

X1018

2 1GbE SFP ports; by default, ports 17 and 18 support SFP

X1018P

16 PoE ports, up to 246W total; by default, ports 1 through 16 support PoE

2 1GbE SFP ports; by default, ports 17 and 18 support SFP

X1026

2 1GbE SFP ports; by default, ports 25 and 26 support SFP

X1026P

24 PoE/12 PoE+ ports, up to 369W total; by default:

Ports 1 through 12 support PoE+
Ports 13 through 24 support PoE

2 1GbE SFP ports; by default, ports 25 and 26 support SFP