How to block ICMP/Ping on WAN IP Address and Overlay IP Address.
Contents
![]() |
Prerequisites
- The branch is provisioned using Config Template
- This document is not restricted to specific Versa certified software and hardware versions.
Use Case:
This article describes, how to use a specific IP address from a pool while using DIA. Many network administrators feel that ICMP is a security risk and should therefore always be blocked at the firewall. By default, versa allows ICMP request on its WAN interface and Overlay IP Address.
- The public IP Address in the FlexVNF is 11.11.3.29/24, which is provided by service provider.
- This document explains how to block ICMP request from public network and Overlay
IP Address.
Configurations.
Lookup a Zone with name “host”.
‘host’ is predefined zone. This zone related to all the Host bound traffics.
A host-zone is a pre-defined domain. A zone can be associated with one or more interfaces, networks, routing instances, and organizations. But for host-zone, no interfaces, networks, routing instances, and organizations required.

2. Configure a QOS-policies.
3/4. Configure a QOS-Policy to deny ICMP to Destination: Host

5. Include the Services: ICMP

6. Action: Block

======================
VOS handles two distinct categories of traffic differently:
1. Transit traffic, which passes through the appliance (for example, LAN to WAN, or site to site). This traffic is governed by the NGFW / Access Policy and the rest of the standard security pipeline.
2. Host-bound traffic, which is destined to the appliance itself. Examples include ping to the WAN or overlay IP, SSH to the device, and control-plane protocols such as BGP, IKE, and BFD.
An ICMP echo request sent to the appliance's WAN or overlay IP falls into the second category. It does not transit the device, it terminates on it.
Why the NGFW does not block it
The NGFW pipeline in VOS is built around stateful session processing on transit flows. Each transit flow gets a session, application identification, and an Access Policy lookup.
Host-bound traffic does not follow this pipeline. Packets destined to the appliance's own IP are delivered directly to the local stack and never reach the Access Policy lookup. As a result, an NGFW rule matching ICMP toward the host zone is not evaluated for this traffic and has no effect on inbound ping to the WAN or overlay IP.
(There is a related "host-bound" match capability in NGFW, but it applies only to traffic originated by the appliance, not traffic destined to it. It does not help here.)
Why the QoS policy does block it
The stateless QoS engine is the one enforcement hook that runs on the host-bound path:
- VOS marks host-bound packets with destination zone host (a predefined system zone).
- Before delivering the packet to the local stack for ICMP processing, the data plane performs a stateless QoS lookup based on the 5-tuple, source zone, destination zone, and service.
- A QoS rule that matches (destination zone = host, service = ICMP) with action drop discards the packet at this point.
This makes QoS the correct and supported method for filtering inbound traffic such as ICMP echo requests aimed at the WAN or overlay IP.
This is the same approach documented in the Versa Knowledge Base article:
How to block ICMP/Ping on WAN IP address and Overlay IP Address.
- The rule does not affect transit ICMP. LAN-to-WAN and site-to-site ping continue to be governed by your Access Policy.
- The rule does not affect IPsec, IKE, BGP, or BFD, because those use different services.
Blocking ping to the WAN or overlay IP on VOS is handled on a different path than transit firewalling. NGFW governs traffic passing through the appliance, while QoS with destination zone host governs traffic destined for the appliance. Using QoS for this is the intended, supported mechanism for blocking inbound pings to the device's own IP addresses.

