to display the Edit Interface window, which allows you to configure the settings for the specified interface.
Network_netInterfaces
Network > Interfaces
This chapter contains the following sections:
The Network > Interfaces page includes interface objects that are directly linked to physical interfaces. The SonicOS Enhanced scheme of interface addressing works in conjunction with network zones and address objects. The interfaces displayed on the Network > Interfaces page depend on the type of SonicWALL appliance. The page pictured below is for SonicWALL TZ 100 or 200 Wireless-N appliances.
Setup Wizard
The Setup Wizard button accesses the Setup Wizard. The Setup Wizard walks you through the configuration of the SonicWALL security appliance for Internet connectivity. For Setup Wizard instructions, see Wizards > Setup Wizard.
Interface Settings
The Interface Settings table lists the following information for each interface:
Note: The X0 and X1 gigabit interfaces are for LAN and WAN, respectively. On the TZ 210 Series, X0 and X1 are the only gigabit interfaces. X2 is the only gigabit interface for the NSA 240.
to display the Edit Interface window, which allows you to configure the settings for the specified interface.
Interface Traffic Statistics
The Interface Traffic Statistics table lists received and transmitted information for all configured interfaces.
The following information is displayed for all SonicWALL security appliance interfaces:
To clear the current statistics, click the Clear Statistics button at the top right of the Network > Interfaces page.
Physical and Virtual Interfaces
Interfaces in SonicOS can be:
Physical Interfaces
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.
The first two interfaces, LAN and WAN are fixed interfaces, permanently bound to the Trusted and Untrusted Zone types. The TZ series appliances can also have two special interfaces for Modem and WLAN. The remaining Interfaces can be configured and bound to any Zone type, depending on your SonicWALL security appliance.
Virtual Interfaces (SonicWALL MSA series appliances)
Supported on SonicWALL NSA series 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 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:
Subinterfaces
VLAN support on SonicOS Enhanced is achieved by means of subinterfaces, which are logical interfaces nested beneath a physical interface. Every unique VLAN ID 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: 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 SonicWALL.
Trunk links from VLAN capable switches are supported by declaring the relevant VLAN ID’s as a subinterface on the SonicWALL, 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 SonicWALL, the rest will be discarded as uninteresting. This method also allows the parent physical interface on the SonicWALL 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. Features excluded from VLAN subinterfaces at this time are WAN dynamic client support and multicast support. The following table lists the maximum number of subinterfaces supported on each platform.
|
SonicOS Enhanced Secure Objects
The SonicOS Enhanced 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 Enhanced.
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 SonicWALL security appliance Management Interface, and User objects are defined in the Users section of the SonicWALL security appliance Management Interface.
Zones are the hierarchical apex of SonicOS Enhanced’s secure objects architecture. SonicOS Enhanced 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, however, the WAN zone is restricted to a total of two interfaces. Within the WAN zone, either one or both 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 & Load Balancing.
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 Enhanced uses interfaces as the top level of the management hierarchy. Transparent Mode supports unique addressing and interface routing.
Layer 2 Bridge Mode
SonicOS Enhanced firmware versions 4.0 and higher includes L2 (Layer 2) Bridge Mode, a new method of unobtrusively integrating a SonicWALL security appliance into any Ethernet network. L2 Bridge Mode is ostensibly similar to SonicOS Enhanced’s Transparent Mode in that it enables a SonicWALL security appliance 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 Bridge 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 Bridge 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 SonicWALL UTM appliance is not used for security enforcement, but instead for bidirectional scanning, blocking viruses and spyware, and stopping intrusion attempts.
Unlike other transparent solutions, L2 Bridge Mode can pass all traffic types, including IEEE 802.1Q VLANs (on SonicWALL NSA appliances), Spanning Tree Protocol, multicast, broadcast, and IPv6, ensuring that all network communications will continue uninterrupted.
Another aspect of the versatility of L2 Bridge Mode is that you can use it to configure IPS Sniffer Mode. Supported on SonicWALL NSA series 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 SonicWALL security appliance is not connected inline with the traffic flow. For more information about IPS Sniffer Mode, see IPS Sniffer Mode (SonicWALL NSA series appliances) .
L2 Bridge 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 Unified Threat Management (UTM) deep-packet inspection, such as Intrusion Prevention Services, Gateway Anti Virus, and Gateway Anti Spyware. If you do not have SonicWALL UTM security services subscriptions, you may sign up for free trials from the Security Service > Summary page of your SonicWALL.
You can also use L2 Bridge Mode in a High Availability deployment. This scenario is explained in the Layer 2 Bridge Mode with High Availability (SonicWALL NSA series appliances).
See the following sections:
Key Features of SonicOS Enhanced Layer 2 Bridge Mode
The following table outlines the benefits of each key feature of layer 2 bridge mode:
|
Key Concepts to Configuring L2 Bridge Mode and Transparent Mode
The following terms will be used when referring to the operation and configuration of L2 Bridge Mode:
Comparing L2 Bridge Mode to Transparent Mode
This comparison of L2 Bridge Mode to Transparent Mode contains the following sections:
While Transparent Mode allows a security appliance running SonicOS Enhanced 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 the diagram below, in a scenario where a Transparent Mode SonicWALL appliance has just been added to the network with a goal of minimally disruptive integration, particularly:
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 SonicWALL. This is because the SonicWALL 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 SonicWALL with its own X0 MAC address (00:06:B1:10:10:10).
The SonicWALL 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 SonicWALL. 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 SonicWALL 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. While Transparent Mode is capable of supporting multiple subnets through the use of Static ARP and Route entries, as the Technote http://www.sonicwall.com/us/support/2134_3468.html describes, it is not an effortless process.
Non-IPv4 Traffic in Transparent Mode
Transparent Mode will drop (and generally log) all non-IPv4 traffic, precluding it from passing other traffic types, such as IPX, or unhandled IP types.
L2 Bridge Mode addresses these common Transparent Mode deployment issues and is described in the following section.
Simple Transparent Mode Topology
ARP in L2 Bridge Mode
L2 Bridge 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) will see the router as 00:99:10:10:10:10, and the Router will see the Workstation (192.168.0.100) as 00:AA:BB:CC:DD:EE.
This behavior allows for a SonicWALL operating in L2 Bridge 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.
Please note that 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 Bridge Mode SonicWALL. This is by design so as to maintain the security afforded by stateful packet inspection (SPI); since the SPI engine can not have knowledge of the TCP connections which pre-existed it, it will drop these established packets with a log event such as TCP packet received on non-existent/closed connection; TCP packet dropped.
VLAN Support in L2 Bridge Mode (SonicWALL NSA series appliances)
On SonicWALL NSA series appliances, L2 Bridge 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 Bridge 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 Bridge Mode because of the method of handling VLAN traffic.
L2 Bridge IP Packet Path
The following sequence of events describes the above flow diagram:
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.
Multiple Subnets in L2 Bridge Mode
L2 Bridge 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 Bridge Mode
Unsupported traffic will, by default, be passed from one L2 Bridge interface to the Bridge-Partner interface. This allows the SonicWALL 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 page.
Comparison of L2 Bridge Mode to Transparent Mode
Benefits of Transparent Mode over L2 Bridge Mode
The following are circumstances in which Transparent Mode might be preferable over L2 Bridge Mode:
Comparing L2 Bridge Mode to the CSM Appliance
L2 Bridge Mode is more similar in function to the CSM than it is to Transparent Mode, but it differs from the current CSM behavior in that it handles VLANs and non-IPv4 traffic types, which the CSM does not. Future versions of the SonicOS CF Software for the CSM will likely adopt the more versatile traffic handling capabilities of L2 Bridge Mode.
L2 Bridge Path Determination
Packets received by the SonicWALL 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 that is applied to path determinations for these cases:
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 SonicWALL 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:
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 Bridge mode allows for greater control of operational levels of trust. Specifically, L2 Bridge Mode allows for the Primary and Secondary Bridge Interfaces to be assigned to the same or different zones (e.g. LAN+LAN, LAN+DMZ, WAN+CustomLAN, etc.) This will affect 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 Bridge 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:
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 following criteria is used to make the determination:
|
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).
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 as follows:
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.sonicwall.com/us/support/2134_4170.html).
Sample Topologies
The following are sample topologies depicting common deployments. Inline Layer 2 Bridge Mode represents the addition of a SonicWALL security appliance to provide UTM services in a network where an existing firewall is in place. Perimeter Security represents the addition of a SonicWALL security appliance in pure L2 Bridge mode to an existing network, where the SonicWALL 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 Bridge Mode with High Availability represents the mixed-mode scenario where the SonicWALL HA pair provide high availability along with L2 bridging. Layer 2 Bridge Mode with SSL VPN represents the scenario where a SonicWALL Aventail SSL VPN or SonicWALL SSL VPN Series appliance is deployed in conjunction with L2 Bridge mode.
See the following sections:
Wireless Layer 2 Bridge
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:
Note: Although a general rule is automatically created to allow traffic between the WLAN zone and your choosen bridged interface, WLAN zone type security properties still apply. Any specific rules must be manually added.
Inline Layer 2 Bridge Mode
This method is useful in networks where there is an existing firewall that will remain in place, but you wish to utilize the SonicWALL’s UTM services without making major changes to the network. By placing the SonicWALL in Layer 2 Bridge 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 UTM appliance installed in a Hewlitt Packard ProCurve switching environment. SonicWALL is a member of HP’s ProCurve Alliance – more details can be found at the following location:http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA1-9147ENUC.pdf
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 UTM appliance.
To configure the SonicWALL appliance for this scenario, navigate to the Network > Interfaces page and click on the configure icon for the X0 LAN interface. On the X0 Settings page, set the IP Assignment to ‘Layer 2 Bridged Mode’ and set the Bridged To: interface to ‘X1’. Also make sure that the interface is configured for HTTP and SNMP so it can be managed from the DMZ by PCM+/NIM. 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
The following diagram depicts a network where the SonicWALL is added to the perimeter for the purpose of providing security services (the network may or may not have an existing firewall between the SonicWALL and the router).
In this scenario, everything below the SonicWALL (the Primary Bridge Interface segment) will generally be considered as having a lower level of trust than everything to the left of the SonicWALL (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 SonicWALL 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 were 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
This diagram depicts a network where the SonicWALL 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 SonicWALL 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.
Since both interfaces of the Bridge-Pair are assigned to a Trusted (LAN) zone, the following will apply:
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:
For detailed instructions on configuring interfaces in Layer 2 Bridge Mode, see Configuring Layer 2 Bridge Mode
Layer 2 Bridge Mode with High Availability (SonicWALL NSA series appliances)
This method is appropriate in networks where both High Availability and Layer 2 Bridge Mode are desired. This example is for SonicWALL NSA series appliances, and assumes the use of switches with VLANs configured.
The SonicWALL HA pair consists of two SonicWALL NSA 3500 appliances, 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 Bridge 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 SonicWALLs and the switches.
On the SonicWALL appliances:
On the switches:
Layer 2 Bridge Mode with SSL VPN
This sample topology covers the proper installation of a SonicWALL UTM device into your existing SonicWALL EX-Series SSL VPN or SonicWALL SSL VPN networking environment. By placing the UTM appliance into Layer 2 Bridge 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 SonicWALL UTM appliance is not used for security enforcement, but instead for bidirectional scanning, blocking viruses and spyware, and stopping intrusion attempts. When programmed correctly, the UTM 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 UTM appliance are covered in this section.
WAN to LAN Access Rules
Because the UTM 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.
On the Firewall > Access Rules page, click the Configure icon for the intersection of WAN to LAN traffic. Click the Configure icon next to the default rule that implicitly blocks uninitiated traffic from the WAN to the LAN.
In the Edit Rule window, select Allow for the Action setting, and then click OK.
Configure the Network Interfaces and Activate L2B Mode
In this scenario the WAN interface is used for the following:
The LAN interface on the UTM 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 Bridge 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 Enhanced 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:
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, navigate to the Network > Interfaces page and click the Configure icon for the LAN interface.
For the IP Assignment setting, select Layer 2 Bridged Mode. For the Bridged to setting, select X1.
If you also need to pass VLAN tagged traffic, supported on SonicWALL NSA series appliances, click the VLAN Filtering tab and add all of the VLANs that will need to be passed.
Click OK to save and activate the change. You may be automatically disconnected from the UTM appliance’s management interface. You can now disconnect your management laptop or desktop from the UTM appliance’s X0 interface and power the UTM appliance off before physically connecting it to your network.
Install the SonicWALL UTM appliance between the network and SSL VPN appliance
Regardless of your deployment method (single- or dual-homed), the SonicWALL UTM appliance 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, follow these steps:
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, follow these steps:
Configure or verify settings
From a management station inside your network, you should now be able to access the management interface on the UTM appliance using its WAN IP address.
Make sure that all security services for the SonicWALL UTM appliance are enabled. See Licensing Services and Activating UTM Services on Each Zone.
SonicWALL Content Filtering Service must be disabled before the device is deployed in conjunction with a SonicWALL Aventail SSL VPN appliance. On the Network > Zones page, click Configure next to the LAN (X0) zone, clear the Enforce Content Filtering Service check box and then click OK.
If you have not yet changed the administrative password on the SonicWALL UTM appliance, you can do so on the System > Administration page.
To test access to your network from an external client, connect to the SSL VPN appliance and log in. Once connected, attempt to access to your internal network resources. If there are any problems, review your configuration and see the Configuring the Common Settings for L2 Bridge Mode Deployments.
IPS Sniffer Mode (SonicWALL NSA series appliances)
Supported on SonicWALL NSA series appliances, IPS Sniffer Mode is a variation of Layer 2 Bridge Mode that is used for intrusion detection. IPS Sniffer Mode configuration allows an interface on the SonicWALL 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 the network diagram below, 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 SonicWALL inspects the packets according to the Unified Threat Management (UTM) settings configured on the Bridge-Pair. Alerts can trigger SNMP traps which are sent to the specified SNMP manager via another interface on the SonicWALL. The network traffic is discarded after the SonicWALL inspects it.
The WAN interface of the SonicWALL is used to connect to the SonicWALL Data Center for signature updates or other data.
In IPS Sniffer Mode, a Layer 2 Bridge is configured between two interfaces in the same zone on the SonicWALL, 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 SonicWALL 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 SonicWALL appliance inline with the network traffic, it only provides a way to inspect the traffic.
The Edit Interfaces screen available from the Network > Interfaces page provides a new checkbox called Only sniff traffic on this bridge-pair for use when configuring IPS Sniffer Mode. When selected, this checkbox causes the SonicWALL 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. (The Never route traffic on this bridge-pair setting is known as Captive-Bridge Mode.)
For detailed instructions on configuring interfaces in IPS Sniffer Mode, see Configuring IPS Sniffer Mode (SonicWALL NSA series appliances).
Sample IPS Sniffer Mode Topology
This section provides an example topology that uses SonicWALL IPS Sniffer Mode in a Hewlitt 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 will remain in place, but you wish to use the SonicWALL’s UTM services as a sensor.
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 SonicWALL. This allows the SonicWALL to analyze the entire internal network’s traffic, and if any traffic triggers the UTM 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, navigate to the Network > Interfaces page and click on the configure icon for the X2 interface. On the X2 Settings page, set the IP Assignment to ‘Layer 2 Bridged Mode’ and set the Bridged To: interface to ‘X0’. Select the checkbox for Only sniff traffic on the bridge-pair. Click OK to save and activate the change.
Next, go to the Network > Interfaces page and click on the configure icon for the X1 WAN interface. On the X1 Settings page, assign it a unique IP address for the internal LAN segment of your network – this may sound wrong, but this will 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 UTM signature updates. Click OK.
You must also modify the firewall rules to allow traffic from the LAN to WAN, and from the WAN to the LAN, otherwise traffic will not pass successfully.
Connect the span/mirror switch port to X0 on the SonicWALL, not to X2 (in fact X2 isn’t plugged in at all), and connect X1 to the internal network. Use care when programming the ports that are spanned/mirrored to X0.