The customer has a loopback interface being set as the termination point for GRE tunnel and expects to use the GRE tunnel only for outbound purpose. In order to block the inbound traffic for the GRE tunnel, customer applied a firewall filter term to reject protocol traffic on input direction. It was observed that the GRE traffic, including decapsulated data, like ping requests, was not being blocked as expected and continue to traverse the tunnel without being halted by the firewall filter.

firewall filter configuration:

{master:0}[edit]

root@router# show firewall family inet filter lo-protection term block-GRE

from {

   protocol gre;

}

then {

   count gre-traffic;

   reject;

}

Clarifying the GRE Traffic Handling:

On JUNOS platforms, the handling of GRE traffic involves a critical understanding that the security boundary for GRE tunnels is not the loopback interface but rather the GR interface. This is the interface where GRE packets are primarily received, and it is linked to the Packet Forwarding Engine (PFE), not the Routing Engine (RE) that manages the loopback interface. The loopback interface serves vital roles, particularly in enhancing network reachability and resilience by separating the GRE tunnel endpoint from physical interfaces. Nonetheless, it's essential to recognize that the GRE tunnel's actual termination occurs at the GR interface level within the PFE. Consequently, by the time the traffic is directed to the loopback interface, it has already been decapsulated from its GRE format.

For optimal control and security, particularly when intending to restrict the GRE tunnel to outbound traffic only, the advisable approach is to implement an input filter directly on the GR tunnel interface. This strategy ensures that inbound traffic is effectively blocked at the point where it is decapsulated, aligning with the user's security expectations.