NSX Tier-0 Gateway drops ICMP reply traffic when using a 0.0.0.0/0 static route through a virtual firewall

Products

• VMware NSX

Issue/Introduction

When you configure a static 0.0.0.0/0 route to force traffic through a third party virtual firewall on an NSX segment attached to a Tier-0 Gateway, ICMP reply traffic is lost when pinging an external IP address.

Symptoms include:

• ICMP echo requests egress successfully, but the reply is dropped at the NSX Edges.

• Modifying the static route to use 0.0.0.0/1 and 128.0.0.0/1 allows the ICMP echo reply to be successfully received.

• Reviewing pktcap-uw --trace output verifies the drop occurs on the Tier-0 Distributed Router (DR) with the reason VdrRxTerminal -> PktFree.

• The net-vdr --stats output explicitly confirms an extreme number of drops (e.g., RPF Failure Drops: 10101010).

Environment

 

• VMware NSX

• Tier-0 Gateway / Distributed Router (DR)

 

Cause

Strict Unicast Reverse Path Forwarding (URPF) is dropping return traffic on the Tier-0 Distributed Router (DR) due to asymmetric routing conditions introduced by the user-defined 0.0.0.0/0 static route.

In the 0.0.0.0/0 scenario, the DR routing table does not install the user-defined static route pointing to the virtual firewall. It relies on the system-generated default route pointing to the Edge Service Routers (SR) via the transit network. When the return packet arrives on the firewall's Logical Interface (LIF), the DR routing table's return path points to the SR transit LIF. Strict URPF flags it as asymmetric/spoofed and drops it.

Resolution

To resolve this issue, you must disable Strict URPF mode on the segment in use by the firewall and connected to the Tier 0 gateway.

1. Navigate to Networking > Segments in the NSX UI.

2. Edit the segment used by the virtual firewall.

3. Change the URPF Mode from Strict to None.

4. Save the configuration.

Additional Information

 

• Why /1 routes circumvent the issue: By default, NSX applies Strict URPF on router interfaces to prevent IP spoofing, which requires the route back to the source IP to use the exact interface on which the packet was received. Changing the URPF mode to None disables this check. When using 0.0.0.0/1 and 128.0.0.0/1, the issue is circumvented because /1 is a more specific prefix than the system-generated /0 default route. These routes successfully install directly into the DR routing table pointing to the firewall's internal IP. When the DR performs the URPF check, it matches the 0.0.0.0/1 route pointing back out the exact same LIF the packet arrived on, allowing Strict URPF to pass.

• Subscribe to this knowledge article to get updates on this issue.