SonicOS 7 System

Technical Documentation > SonicOS 7 System > Interfaces > Interface Settings IPv4 > Layer 2 Bridged Mode > Comparing L2 Bridged Mode to Transparent Mode > L2 Bridge IP Packet Path

L2 Bridge IP Packet Path

L2 Bridge IP Packet Flow

L2 Bridge IP Packet Flow

The following sequence of events describes the flow in L2 Bridge IP Packet Flow:

  1. 802.1Q encapsulated frame enters an L2 Bridge interface (this first step, Step 2, and Step 12 apply only to 802.1Q VLAN traffic).
  2. The 802.1Q VLAN ID is checked against the VLAN ID white/black list. If the VLAN ID is:
    • Disallowed, the packet is dropped and logged.
    • Allowed, the packet is decapsulated, the VLAN ID is stored, and the inner packet (including the IP header) is passed through the full packet handler.
  3. 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.
  4. SYN Flood checking is performed.
  5. 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.
  6. A NAT lookup is performed and applied, as needed:
    • 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.
    • 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).
  7. Access Rules are applied to the packet. For example, on SonicWall firewalls, 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.

  1. A connection cache entry is made for the packet, and required NAT translations (if any) are performed.
  2. 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.
  3. Deep packet inspection, including Gateway Anti-Virus, Intrusion Prevention, 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.
  4. 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.
  5. 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.

Was This Article Helpful?

Help us to improve our support portal

Yes! Not Really

Techdocs Article Helpful form

  • Hidden
  • Hidden

Techdocs Article NOT Helpful form

  • Still can't find what you're looking for? Try our knowledge base or ask our community for more help.
  • Hidden
  • Hidden