DotW: Send ICMP Unreachable

In this week's Discussion of the Week, user 'PanIst' had a question about what the purpose is of the "Send ICMP Unreachable" checkbox that appeared in the policy action tab in PAN-OS 7.0.

To highlight the purpose of this feature, I'll show the functionality of a couple new actions available in PAN-OS 7.0. These newly added actions allow for more control over the response provided by the Palo Alto Networks firewall to a session that hits a "negative" action security policy.

The "Drop" action will silently discard all packets once it determines a session is unwanted, this will leave the client in the dark about what happened to the session and could lead to some user frustration as the client may keep loading for a good time before timing out. This is the default action applied to all implied policies, and was the only option available prior to PAN-OS 7.0 to block traffic.

As you can see in the packet capture output below, the client sends out packets (ping and web-browsing), which in my example the configurations are dropped. ICMP never gets a response, and web-browsing is dropped as soon as App-ID detects it is genuine web traffic. The web browser is unaware it was blocked and keeps resending its last packet, keeping the user waiting.

The "Deny" and "Reset" actions can send a reset packet to the client (and if desired the server). An error message can be displayed, or the session can be terminated graciously, informing the user about the disconnect. However, this action can only be applied to TCP sessions.

In the packet capture output below, the HTTP session is ended with a reset packet and the browser will display an error message informing the user the website is unreachable.

To accommodate UDP or ICMP sessions, a ICMP Unreachable message (ICMP type 3 code 13) can be sent to inform the client a session is not allowed, which can greatly improve the user experience.

Typically, this type of "active" rejection of traffic will only be applied to well known traffic originating from the internal user network or subnets, (this is where certain chatty protocols reside and can be beneficial for user experience or prevent continuous retries from an application).

For traffic originating from an untrusted network, it is always recommended to obscure and delay as much as possible thus "drop" is the recommended (and default) action.

To view the discussion, reference the following link: Send ICMP Unreachable panos7

All comments or suggestions are encouraged.

Thanks for reading,

Tom Piens