UniFi Router WAN Ping Reply

By default a UniFi gateway silently drops pings arriving on its WAN interface, which is fine until you need remote monitoring, a supplier's uptime check, or simply a way to prove the line is up. Here is how to allow ICMP echo on the WAN — on Network 10, on Network 9, and on the older rules interface.

Which gateways this applies to

Every current UniFi gateway and cloud gateway handles this the same way, including the UXG-Lite, UXG-Max, UXG-Pro and UXG-Enterprise; the UCG-Ultra, UCG-Max and UCG-Fiber; the UDM-Pro, UDM-SE and UDM-Pro Max; the Dream Router, Dream Wall and the Enterprise Fortress Gateway. The menu paths differ by Network version rather than by model.

What changed in Network 10

Not the firewall logic. The built-in zones are the same six — External, Internal, Gateway, VPN, Hotspot and DMZ — and a ping arriving at your WAN address is still traffic from External to Gateway. Inbound traffic from External is blocked unless it is a reply to something you sent, so it still takes an explicit allow policy.

What moved is the menu. On Network 10 the firewall sits under the Policy Engine, alongside application filtering, policy-based routing, QoS, switch ACLs and content filtering. If that sounds familiar, it is: Network 9.3 also put zones under the Policy Engine, 9.4 promoted them to top-level Settings items, and 10 gathered them back in. Learn the destination — the zone matrix and the policy table — rather than the path.

Two Network 10 additions are worth knowing about when a rule appears not to work. The policy table shows per-policy hit counts (added in 10.5, June 2026), so you can see whether your allow policy is being matched instead of guessing. And changes can be applied through Test & Confirm, which rolls them back if you do not confirm — so a policy that quietly vanished was probably never confirmed.

Method 1 — Network 10.x

1. Open the policy editor

   Go to Settings → Policy Engine → Policy Table and choose Create Policy. Better still, open the zone matrix and click the cell where the External row meets the Gateway column — a policy created from there arrives with the zones already set. Wording shifts between releases, so if your build labels it differently, look for the zone matrix.

2. Set source and destination zones

   Source zone: External. Destination zone: Gateway. This is the part that catches people out — you are not allowing traffic through the router to an internal device, you are allowing traffic to the router itself, which is what the Gateway zone represents.

3. Set the action and protocol

   Action Allow. Under restrictions set IP Version to IPv4 and Protocol to ICMP. For ICMP Type Name, choose Echo Request — or Any if you want to keep it simple and are not concerned about other ICMP types. You do not need a second policy for the reply: the Gateway zone is allowed to send traffic out to External by default.

4. Name it and place it

   Give it something you will recognise in six months — "Allow WAN ping" beats "rule 14". Custom policies sit above the built-in ones by default, but not above your other custom policies, so check the table order and move it above anything broader covering External to Gateway. Built-in policies carry a lock icon: they cannot be edited, only overruled.

5. Confirm the change, then test from outside

   If your console applies the change through Test & Confirm, confirm it — an unconfirmed change reverts on its own. Then ping the WAN IP from a connection that is not yours, or use an online ping tool, and check the policy's hit count to see the traffic landing on it. Testing from inside your own network will not prove anything, since that traffic never crosses the External zone.

Method 2 — Network 9.x

Same firewall, same zones, same field values as method 1 — only the route through the menu differs. Use the path that matches your version, then set the policy up exactly as described above.

• Network 9.4 — Settings → Zones → Create Policy, or Settings → Policy Table → Create New Policy.
• Network 9.3 — Settings → Policy Engine → Zones → Create Policy.
• Either version — source zone External, destination zone Gateway, action Allow, IP Version IPv4, Protocol ICMP, ICMP Type Name Echo Request.

Per-policy hit counts arrived with Network 10.5, so on 9.x your only real confirmation is whether the ping succeeds from outside.

Method 3 — Traffic & Firewall Rules (Network 8.x and earlier)

1. Open the advanced rules view

   Go to Settings → Security → Traffic & Firewall Rules, then select Advanced at the top right. You can optionally filter to the Internet In interface.

2. Create the entry

   Click Create Entry and set the type to Internet Local. It sounds wrong, and it is correct: Internet In covers traffic passing through the gateway to your LAN, while Internet Local covers traffic addressed to the gateway itself — which is exactly what a ping to your WAN IP is.

3. Name it and set the action

   Name it "ICMP Allow Ping WAN" or similar. Action: Accept. Tick Before Predefined so the rule is evaluated ahead of the built-in rules that would otherwise drop the traffic.

4. Set the protocol

   Set IPv4 Protocol to ICMP — the list is long and scrollable, so keep going if you cannot see it. Then set the IPv4 ICMP Type Name (see the note below on which value to use).

5. Leave the rest alone

   Do not tick Match Opposite. Leave Source and Destination as the default of Any, unless you are restricting to specific monitoring addresses. Click Add Rule at the bottom.

If it still doesn't respond

If the ping works from the outside world but not from your desk, the rule is fine — your test isn't.