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:
Address Resolution Protocol (ARP) is the mechanism by which unique hardware addresses on network interface cards are associated to IP addresses, and 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.
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.
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, it is not an effortless process.
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
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) 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 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.
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.
Layer 2 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.
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.
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
|
Attribute
|
Layer 2 Bridge 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 (for example, 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 SonicWall 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 SonicWall, 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.
|
|
PortShield interfaces
|
PortShield interfaces cannot be assigned to either interface of an L2 Bridge Pair.
|
PortShield interfaces may be assigned a Transparent Mode range.
|
|
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 Bridge 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 will be 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 will be 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 SonicWall NSA series appliances.
|
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.
|
The following are circumstances in which Transparent Mode might be preferable over L2 Bridge Mode:
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.
