How to Allow Ping (ICMP) Through Your Firewall — Safely
How to enable ICMP (ping) on Sophos, FortiGate, UniFi and DrayTek firewalls — and lock it to specific source IPs so only your monitoring provider can reach it.
If a provider monitors your business internet, they need a way to check the connection is actually up. The simplest, lightest method is a periodic ping — an ICMP echo request to your WAN address. If the firewall answers, the link is alive; if it stops answering, the monitoring system raises an alert before your staff even notice.
The catch: most business firewalls block ping from the internet by default (which is sensible), so monitoring can't see your connection until you allow ICMP. This guide shows how to enable ping on the major firewall brands — and, just as importantly, how to lock it to specific source IP addresses so only your monitoring provider can use it, not the whole internet.
Why restrict ping to specific source IPs?
Opening ping to the entire internet is a small but needless exposure. It confirms to anyone scanning that something is alive at your address, and it's one more service answering traffic it doesn't need to. The principle is least privilege: allow only what's needed, from only who needs it.
So instead of "respond to ping from anywhere", the goal is "respond to ping only from these source addresses" — the handful of monitoring IPs your provider uses. Every firewall below can do this; it's just a matter of where the setting lives.
Before you start, get two things ready:
- The source IPs to allow. Your monitoring provider supplies these — usually a small, fixed block. SIP Connect gives you ours in writing when we turn on monitoring.
- An address object (and group) on the firewall holding those IPs. Most of the brands below want you to reference a named group rather than typing raw addresses into a rule.
Enable ping by firewall brand
Open the section for your firewall. Each one follows the same shape: create a source-IP object for the allowed addresses, then permit ICMP to the WAN only from that object.
Sophos Firewall
Applies to Sophos Firewall (SFOS) on any XGS-series appliance — the desktop XGS 88/108/118/128/138 (and the earlier 87/107/116/126/136) and the 1U/2U rackmount models up to the XGS 5500–8500 — plus the virtual and cloud editions. Older SG appliances running Sophos UTM 9 use a different menu, so check the UTM docs for those.
Sophos separates "does the firewall answer ICMP on this zone" from "who is allowed to". Use the second control so ping isn't open to everyone.
Create an IP Host (or Host Group) under Hosts and Services containing your monitoring source IPs.
Go to Administration → Device Access. Leave the general Ping/Ping6 tick for the WAN zone off — ticking it answers ping from anyone.
Add a Local Service ACL Exception Rule: source host = your monitoring group, destination = the firewall's WAN, service = Ping, action = Accept.
Save and test. Only the listed source IPs can now ping the WAN.
Canonical reference: Sophos Firewall documentation (search "local service ACL exception").
FortiGate (Fortinet)
Applies to any FortiGate running FortiOS — the whole range, from the desktop branch models (40F, 60F, 70G, 90G and similar) up through the campus models (120G, 200G, 400G, 600F, 900G) and larger, plus FortiGate-VM in the cloud. Local-In Policies are configurable in the GUI on recent FortiOS and via CLI on all of them.
On a FortiGate, the interface "Administrative Access → PING" toggle opens ping to everyone on that interface. To restrict by source, pair it with a Local-In Policy.
Create a Firewall Address (and Address Group) for your monitoring source IPs under Policy & Objects → Addresses.
On the WAN interface, enable PING under Administrative Access.
Add a Local-In Policy (Policy & Objects, or via CLI): source = the monitoring address group, destination = the WAN interface, service = PING, action = Accept — and make sure ICMP from everything else is denied.
Test from an allowed address and from an outside one to confirm only the allow-list gets through.
Canonical reference: Fortinet documentation (search "local-in policy").
UniFi (Ubiquiti)
On current UniFi gateways the ping rule lives in the new Traffic & Firewall Rules engine (UniFi Network 8.x). These steps apply to the current gateways — UXG-Lite, UXG-Max, UXG-Pro, UXG-Enterprise, UDM-Pro, UDM-SE, UDM-Pro-Max, UCG-Ultra, UCG-Max and UDW.
Go to Settings (cog) → Security → Traffic & Firewall Rules, then switch to Advanced (top right). You can optionally set the interface to Internet In.
Click Create Entry and set Type to Internet Local. It sounds wrong, but it's correct — "Internet Local" means traffic from the internet to the gateway itself.
Name
it (e.g. ICMP Allow Ping WAN) and set Action to Accept.
Protocol
= ICMP, and tick Before Predefined (ICMP sits further down the scrollable list).
Set IPv4 ICMP Type Name to Echo Reply, and leave Match Opposite unticked.
Restrict the source (recommended).
Leaving Source as Any answers ping from everyone. To answer only your monitoring provider, set Source Type to Port/IP Group, then next to Address Group click New and create a group holding the allowed source IPs. Leave Destination as Any.
Click Add Rule at the bottom, then test remotely.
If it still doesn't respond: an upstream, ISP-supplied modem/router may be blocking ping — put it in bridge mode or full DMZ to the UniFi gateway. If that's already done, double-check your NAT is set up correctly.
Canonical reference: Ubiquiti UniFi help centre.
DrayTek (Vigor)
DrayTek Vigor routers have a global ping-response behaviour plus firewall filter rules. Use a filter rule so only your monitoring IPs are answered.
Create an IP Object (and IP Group) for your monitoring source IPs under Objects Setting → IP Object.
In Firewall → Filter Setup, add a data-filter rule: direction = inbound from WAN, source = your monitoring IP group, protocol = ICMP, action = Pass.
Keep the default rule blocking other inbound ICMP so nothing else is answered, and confirm the router is set to respond to ping for that allowed traffic.
Save and test from an allowed address.
Canonical reference: DrayTek knowledge base (search "firewall filter ICMP").
Test it the right way
After you save the rule, confirm two things — not just one:
- It works from the allowed source. Your monitoring provider (or you, from the allowed IP) should get a reply. If you can't test from that address, ask the provider to confirm they're seeing responses.
- It's still blocked from everywhere else. From an ordinary connection (your phone on mobile data, for example), pinging your WAN should time out. If it replies, your rule is too broad — tighten the source.
The same principle for anything you expose
ICMP is the gentle example, but the rule of thumb carries across everything a firewall exposes to the internet: a remote-access port, a management interface, a SIP signalling endpoint. Wherever you can, scope it to known source addresses instead of leaving it open. It's the difference between a service the right people can reach and a service the whole internet can knock on. The same thinking underpins how we secure SIP trunks and the connections behind them.
From the field
The most common reason this comes up for us is turning on monitored business internet — we ping the service so we know the moment a line drops, often before the customer's first call about it. We hand over a short, fixed list of source IPs to allow, and on the firewalls we manage we set the source-restricted rule ourselves during install.
If you'd rather not touch firewall rules, that's exactly the kind of thing we handle. Call 1300 747 266 or get in touch and we'll sort the monitoring and the rule together — or pair it with internet failover so a dropped line never means dropped calls.
Frequently asked questions
Is it safe to allow ping on my business firewall?
Yes, as long as you restrict it to known source IPs rather than answering the whole internet. Ping itself is harmless; the only concern is needless exposure. A rule that allows ICMP from a small, fixed set of monitoring addresses — and blocks everything else — keeps the benefit without opening anything up.
Why does my provider need to ping my connection?
It's the lightest, lowest-overhead way to monitor uptime. A periodic ping to your WAN tells the monitoring system the link is alive; when replies stop, it raises an alert. That's how a good provider often knows your internet is down before you do — and can act on it.
Can I just allow ICMP from anywhere instead?
You can, but you shouldn't. Answering ping from any source confirms to anyone scanning that you're there and adds exposure for no benefit. Allowing it only from your provider's source IPs gives you the monitoring without the open door.
What happens if the monitoring IP addresses change?
You update the address object on the firewall and the rule keeps working — that's why every brand above uses a named host/group rather than a hard-coded address. A good provider keeps these stable and tells you in advance if they ever change. SIP Connect gives you the current list in writing whenever we set monitoring up.
Related SIP Connect services
More insights
3CX Licensing Explained: Simultaneous Calls, Not Extensions
3CX is licensed by simultaneous calls, not per user — which can save you a lot. Here's how the…
Read article →InsightsBusiness NBN vs Home NBN: Why the Difference Matters
Business NBN and home NBN aren't the same. Static IP, priority support, SLAs and monitoring…
Read article →InsightsHow to Choose a Business Internet Provider in Australia
What to look for in a business internet provider — SLAs, contention, support, static IP and…
Read article →Get a free bill analysis — and stop overpaying
Send us a recent phone or internet bill. We’ll show you exactly where the waste is — our bill reviews have identified savings of up to 65%.