Transparent Mode Policy Does Not Block Same-VLAN Traffic
An SRX340 is deployed in transparent mode between an access switch and a core router. ge-0/0/1.0 and ge-0/0/2.0 are both in bridge domain bd-vlan100, VLAN 100, and both are assigned to security zone l2-users. Host A (10.0.100.10) and host B (10.0.100.20) are on the same VLAN and use 10.0.100.1 on the core router as their default gateway. A security policy from l2-users to l2-users matches source host-A, destination host-B, application any, and denies. Despite this, a continuous SCP transfer from A to B still completes. show security flow session source-prefix 10.0.100.10 destination-prefix 10.0.100.20 returns no sessions. show bridge mac-table shows both MAC addresses learned in bd-vlan100. No firewall filters are applied to the bridge interfaces.
1. Why does the deny policy fail to stop the SCP transfer? Explain what path the frames take and what the absence of a flow session proves.
Read the worked answer
The policy is not wrong; it is simply not on the path. Both interfaces are in the same bridge domain, bd-vlan100, and both hosts are in the same VLAN. The SRX learns both MAC addresses in that bridge domain and switches the frames at Layer 2 between ge-0/0/1.0 and ge-0/0/2.0. Those frames are not routed and are not passed through the security flow engine, so a zone-to-zone security policy is never evaluated. The absence of a session for 10.0.100.10 to 10.0.100.20 is the proof: if the traffic had reached the policy engine, a session attempt or deny would be visible. The MAC table showing both hosts in the same bridge domain confirms the Layer 2 forwarding path.
This is a common transparent-mode judgement point. Security policies apply to traffic that the SRX must flow-process, such as inter-zone traffic or traffic that is routed. Same-VLAN switched traffic stays within the bridge and bypasses policy.
2. The requirement is to block A-to-B traffic while keeping the rest of VLAN 100 transparent. What design change would actually enforce the policy, and what would you verify after the change?
Read the worked answer
You must remove the direct Layer 2 path between the two hosts. One workable design is to place host B in a different VLAN and bridge domain, assign that bridge domain to a different zone, and route between the two bridge domains through an IRB so the SRX can apply a zone-to-zone policy. If both hosts remain in the same zone, you also need an intra-zone policy, because Junos denies intra-zone traffic by default once the traffic is routed. Another option is a Layer 2 firewall filter applied to the bridge interface that matches the relevant source and destination addresses or MAC addresses and discards the traffic; that keeps the transparent design but moves enforcement out of the security policy engine.
After the change, verify that A-to-B traffic now produces a flow session and a policy hit on the deny rule. Check show security flow session source-prefix 10.0.100.10/32 destination-prefix 10.0.100.20/32 and show security policies hit-count. Also confirm that other VLAN 100 hosts still switch normally and that their default gateway path is unchanged. Do not assume that creating a second bridge domain alone enforces policy; without routing or a filter, the SRX may still bridge or may simply have no path.