| L2 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. For example, a PRO 2040 could have two Bridge-Pairs (X1+X0, X2+X3), and a PRO 4100 could have five Bridge-Pairs, etc. 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-toone” 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 (e.g. 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 sub-interfaces 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 sub-interfaces | VLAN sub-interfaces 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 (e.g. as management traffic). | VLAN sub-interfaces can be assigned to physical interfaces operating in Transparent Mode, but their mode of operation will be independent of their parent. These VLAN sub-interfaces 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 no special configuration requirements. | 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. | Full stateful packet inspection will applied to traffic from/to 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 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. |
Next Generation FirewallNext-generation firewall for SMB, Enterprise, and Government
Security ServicesComprehensive security for your network security solution
Network Security ManagerModern Security Management for today’s security landscape
Capture ATPMulti-engine advanced threat detection
Capture Security applianceAdvanced Threat Protection for modern threat landscape
Cloud Edge Secure AccessDeploy Zero-Trust Security in minutes
Secure Mobile AccessRemote, best-in-class, secure access
Wireless Access PointsEasy to manage, fast and secure Wi-FI
SwitchesHigh-speed network switching for business connectivity
Email SecurityProtect against today’s advanced email threats
Cloud App SecurityVisibility and security for Cloud Apps
Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
Capture ClientStop advanced threats and rollback the damage caused by malware
Content Filtering ClientControl access to unwanted and unsecure web content
03/26/2020
102
16397