This article explains why packets are bypassed when SRX devices work in transparent-bridge mode between a PPPoE server and client.
Customers will find that the security policy or other security functions do not work for traffic passing through SRX devices that are configured in transparent-bridge mode (as shown below), even though the related security policy has been configured.
PPPoE_Server----SRX----PPPoE_Client
When an SRX device is configured in transparent-bridge mode as follows:
set protocols l2-learning global-mode transparent-bridge
The following setting is required to allow PPPoE negotiation traffic; otherwise PPPoE negotiation will fail.
set security flow ethernet-switching bypass-non-ip-unicast
With the above configuration, it is seen that all traffic between a PPPoE server and client bypasses the security policy and other security functions.
This is expected behavior because SRX devices consider all packets with PPPoE encapsulation as non-ip-unicast packets and bypass security features while passing them.
root@pppoeclient# run ping 210.149.34.82 PING 210.149.34.82 (210.149.34.82): 56 data bytes 64 bytes from 210.149.34.82: icmp_seq=0 ttl=64 time=2.418 ms 64 bytes from 210.149.34.82: icmp_seq=1 ttl=64 time=2.313 ms 64 bytes from 210.149.34.82: icmp_seq=2 ttl=64 time=2.358 ms 64 bytes from 210.149.34.82: icmp_seq=3 ttl=64 time=2.486 ms root# run show security flow session protocol icmp Total sessions: 0 08:37:59.203371 Out Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16 Device Media Type Extension TLV #3, length 1, value: PPPoE (56) Logical Interface Encapsulation Extension TLV #6, length 1, value: PPPoE (63) Device Interface Index Extension TLV #1, length 2, value: 32768 Logical Interface Index Extension TLV #4, length 4, value: 71 -----original packet----- 3c:61:04:98:0b:c0 > 28:8a:1c:43:4f:40, ethertype PPPoE S (0x8864), length 30: PPPoE [ses 1]LCP (0xc021), length 10: LCP, Echo-Request (0x09), id 151, length 10 ...