SonicOS 7 System
- SonicOS 7.0
- Overview
- Interfaces
- About Interfaces
- Interface Settings IPv4
- Adding Virtual Interfaces
- Configuring Routed Mode
- Enabling Bandwidth Management on an Interface
- Configuring Interfaces in Transparent IP Mode (Splice L3 Subnet)
- Configuring Wireless Interfaces
- Configuring WAN Interfaces
- Configuring Tunnel Interfaces
- Configuring VPN Tunnel Interfaces
- Configuring Link Aggregation and Port Redundancy
- Configuring One Arm Mode
- Configuring an IPS Sniffer Mode Appliance
- Configuring Security Services (Unified Threat Management)
- Configuring Wire and Tap Mode
- Layer 2 Bridged Mode
- Key Features of SonicOS Layer 2 Bridged Mode
- Key Concepts to Configuring L2 Bridged Mode and Transparent Mode
- Comparing L2 Bridged Mode to Transparent Mode
- Comparison of L2 Bridged Mode to Transparent Mode
- Benefits of Transparent Mode over L2 Bridged Mode
- ARP in Transparent Mode
- VLAN Support in Transparent Mode
- Multiple Subnets in Transparent Mode
- Non-IPv4 Traffic in Transparent Mode
- ARP in L2 Bridged Mode
- VLAN Support in L2 Bridged Mode
- L2 Bridge IP Packet Path
- Multiple Subnets in L2 Bridged Mode
- Non-IPv4 Traffic in L2 Bridged Mode
- L2 Bridge Path Determination
- L2 Bridge Interface Zone Selection
- Sample Topologies
- Configuring Network Interfaces and Activating L2B Mode
- Configuring Layer 2 Bridged Mode
- Asymmetric Routing
- Configuring Interfaces for IPv6
- 31-Bit Network Settings
- PPPoE Unnumbered Interface Support
- Failover & LB
- Neighbor Discovery
- ARP
- MAC IP Anti-Spoof
- Web Proxy
- PortShield Groups
- SonicOS Support of X-Series Switches
- About the X-Series Solution
- Performance Requirements
- Key Features Supported with X-Series Switches
- PortShield Functionality and X-Series Switches
- PoE/PoE+ and SFP/SFP+ Support
- X-Series Solution and SonicPoints
- Managing Extended Switches using GMS
- Extended Switch Global Parameters
- About Links
- Logging and Syslog Support
- Supported Topologies
- Port Graphics
- Port Configuration
- External Switch Configuration
- External Switch Diagnostics
- Configuring PortShield Groups
- SonicOS Support of X-Series Switches
- PoE Settings
- VLAN Translation
- IP Helper
- Dynamic Routing
- DHCP Server
- Configuring a DHCP Server
- Configuring Advanced Options
- Configuring DHCP Option Objects
- Configuring DHCP Option Groups
- Configuring a Trusted DHCP Relay Agent Address Group (IPv4 Only)
- Enabling Trusted DHCP Relay Agents
- Configuring IPv4 DHCP Servers for Dynamic Ranges
- Configuring IPv6 DHCP Servers for Dynamic Ranges
- Configuring IPv4 DHCP Static Ranges
- Configuring IPv6 DHCP Static Ranges
- Configuring DHCP Generic Options for DHCP Lease Scopes
- DHCP and IPv6
- Multicast
- Network Monitor
- AWS Configuration
- SonicWall Support
L2 Bridge Path Determination
Packets received by the appliance 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 subinterface, 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:
-
If present, the most specific non-default route to the destination is chosen. This would cover, for example:
- A packet arriving on X3 (non-L2 Bridge LAN) destined for host
15.1.1.100
subnet, where a route to the15.1.1.0/24
subnet exists through192.168.0.254
through the X0 (Secondary Bridge Interface, LAN) interface. The packet would be forwarded through X0 to the destination MAC address of192.168.0.254
, with the destination IP address15.1.1.100
. - A packet arriving on X4 (Primary Bridge Interface, LAN) destined for host
10.0.1.100
, where a route to the10.0.1.0/24
exists through192.168.10.50
through the X5 (DMZ) interface. The packet would be forwarded through X5 to the destination MAC address of192.168.10.50
, with the destination IP address10.0.1.100
.
- A packet arriving on X3 (non-L2 Bridge LAN) destined for host
-
If no specific route to the destination exists, an ARP cache lookup is performed for the destination IP address. A match indicates the appropriate destination interface. This would cover, for example:
- 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 through X2 to the known destination MAC and IP address of192.168.0.100
, as derived from the ARP cache. - 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 through X5 to the known destination MAC and IP address of10.0.1.10
, as derived from the ARP cache.
- A packet arriving on X3 (non-L2 Bridge LAN) destined for host
-
If no ARP entry is found:
- If the packet arrives on a Bridge-Pair interface, it is sent to the Bridge-Partner interface.
- If the packet arrives from some other path, the appliance sends an ARP request out both interfaces of the Bridge-Pair to determine on which segment the destination IP resides.
In this last case, as the destination is unknown until after an ARP response is received, the destination zone also remains unknown until that time. This precludes the appliance from being able to apply the appropriate Access Rule until after path determination is completed. Upon completion, the correct Access Rule is applied to subsequent related traffic.
With regard to address translation (NAT) of traffic arriving on an L2 Bridge-Pair interface, if it is determined to be bound for:
- The Bridge-Partner interface, no IP translation (NAT) is performed.
-
A different path, appropriate NAT policies applies; if the path is:
- Another connected (local) interface, there is likely no translation. That is, it is effectively routed as a result of hitting the last-resort Any > Original NAT Policy.
- Determined to be through the WAN, then the default Auto-added [interface] outbound NAT Policy for X1 WAN applies, and the packet’s source is translated for delivery to the Internet. This is common in the case of Mixed-Mode topologies as described in Internal Security.
Was This Article Helpful?
Help us to improve our support portal