- Products
- Network Security
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
- Advanced Threat Protection
Capture ATPMulti-engine advanced threat detection
Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
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 Security
Email SecurityProtect against today’s advanced email threats
- Cloud Security
Cloud App SecurityVisibility and security for Cloud Apps
Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
Capture ClientStop advanced threats and rollback the damage caused by malware
Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
- Products
- Network Security
- 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
- Advanced Threat Protection
- Capture ATPMulti-engine advanced threat detection
- Capture Security applianceAdvanced Threat Protection for modern threat landscape
- Access Security
- 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 Security
- Email SecurityProtect against today’s advanced email threats
- Cloud Security
- Cloud App SecurityVisibility and security for Cloud Apps
- Cloud Firewall (NSv)Next-generation firewall capabilities in the cloud
- Endpoint Security
- Capture ClientStop advanced threats and rollback the damage caused by malware
- Content Filtering ClientControl access to unwanted and unsecure web content
- Product Widgets
- Product Menu Right Image
- Network Security
- Solutions
- Solutions Widgets
- Solutions Image Widgets
- Solutions Widgets
- Partners
- Partner Widgets
- Partners Image Widgets
- Partner Widgets
- Support
- Support Widget
- Support Image Widgets
- Support Widget
L2 bridge IP Packet Path and L2 Bridge Path determination
05/14/2020 
2 People found this article helpful
91,511 Views
Description
SonicOS includes L2 (Layer 2) Bridged Mode, a method of unobtrusively integrating a Security Appliance into any Ethernet network. L2 Bridged Mode is ostensibly like SonicOS’s Transparent Mode in that it enables a 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.
Resolution
L2 Bridge IP packet flow:
The following sequence of events describes the flow in L2 Bridge IP packet flow:
- 802.1Q encapsulated frame enters an L2 Bridge interface (this first step, Step 2, and Step 12 apply only to 802.1Q VLAN traffic).
- The 802.1Q VLAN ID is checked against the VLAN ID white/blacklist. If the VLAN ID is:
a) Disallowed, the packet is dropped and logged.
b) 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. - 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 Access Rules.
- SYN Flood checking is performed.
- A destination route lookup is performed to the destination zone, so that the appropriate 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.
- A NAT lookup is performed and applied, as needed:
a) In general, the destination for packets entering an L2 Bridge is the Bridge-Partner interface (that is, the other side of the bridge). In these cases, no translation is performed.
b) In cases where the L2 Bridge Management Address is the gateway, as is sometimes the case in Mixed-Mode topologies, then NAT is applied as needed (for more details, see L2 Bridge Path Determination section). - 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 an 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 is dropped and logged. If the packet is allowed, it continues. - A connection cache entry is made for the packet and required NAT translations (if any) are performed.
- 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 is dropped and logged. If the packet is allowed, it continues.
- Deep packet inspection, including GAV, IPS, Anti-Spyware, CFS and email-filtering is performed. If the packet is disallowed, it is dropped and logged. If the packet is allowed, it continues. Client notification is performed as configured.
- 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 is sent through the appropriate path.
- If the packet is not destined for the VPN/WAN/Connected interface, the stored VLAN tag is restored, and the packet (again bearing the original VLAN tag) is sent out the Bridge-Partner interface.
L2 Bridge Path Determination:
Packets received by the Security 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 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:
- 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 through the X0 (Secondary Bridge Interface, LAN) interface. The packet would be forwarded through 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 through the X5 (DMZ) interface. The packet would be forwarded through X5 to the destination MAC address of 192.168.10.50, with the destination IP address 10.0.1.100. - 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 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 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 through X5 to the known destination MAC and IP address of 10.0.1.10, as derived from the ARP cache.
- 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 Security 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 Security 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:
a) 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.
b) 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.
YES
NO