Description

This article explains why packets are bypassed when SRX devices work in transparent-bridge mode between a PPPoE server and client.

 

Symptoms

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

 

Solution

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
...