Description

This article provides a solution to a configuration scenario where traffic policing through the tunnel is not working.

Symptoms

Topology:

LAN1 ---- (10G)(reth0)SRX(reth1)(10G)--------IPsec---------(1G)FW(1G) ---- LAN2

Traffic blackholes as the FW side interfaces are 1G and SRX side is 10G. The requirement is to limit the traffic on the SRX side.

Note: This is an example setup or requirement; the idea is policing traffic for IPsec.
 

Configuration Used on SRX:

set interfaces reth1 unit 0 family inet filter input ON-DEMAND
set firewall family inet filter ON-DEMAND term 400m from destination-address 2.2.2.2/26
set firewall family inet filter ON-DEMAND term 400m then policer police400m
set firewall family inet filter ON-DEMAND term 400m then count ON-DEMAND_Count
set firewall family inet filter ON-DEMAND term last then accept
set firewall policer police400m if-exceeding bandwidth-limit 400m
set firewall policer police400m if-exceeding burst-size-limit 15000
set firewall policer police400m then discard

Where, "destination-address" is the subnet on the other side of the VPN.

The count shows that the policer is not working:

srx> show firewall filter ON-DEMAND
Filter: ON-DEMAND
Counters:
Name                                                      Bytes              Packets
ON-DEMAND_Count                                               0                    0
Policers:
Name                                                      Bytes              Packets
police400m-400m                                                                    0

Solution

The possible solution is to create a firewall filter to police traffic on the SRX.

A question commonly asked is which interface to police the traffic:

  • On the st interface  OR
  • On the exit interface of the SRX OR
  • On the ingress interface of the SRX. 

The answer is to configure the policing on the ingress interface, which is reth0 in this topology.

Run the following command to check that the policer is working.

srx> show firewall filter ON-DEMAND

Filter: ON-DEMAND
Counters:
Name                                                Bytes Packets
ON-DEMAND_Count                                1262565939 917764