Track Internet disconnections, provider outages with historical data, and automated speed testing.
For Windows, Linux, ARM64, ARMa7. Learn more by visiting www.outagesio.com
Notice: If you created an account on app.outagesio.com, simply use the same credentials to log in here.
Which ports to open on firewall to allow Agent to communicate?
-
Hi I have installed an Outages.Io agent on a company server.
The ICMP rules have been enabled on windows firewall but I am still not getting confirmation of a successful heartbeat with the Outages.Io servers based on what I can see in the product dashboard.
I am assuming it's due to our company firewall.
Does anyone know which ports to open/the external IP Outages.Io is trying to reach so I can open/whitelist?
Thanks,
J
-
Hi,
Can you share the agent ID please so I can take a look.
The Windows installer sets up an any/any rule if I recall but it only uses ports 80, 443 and ICMP. Our agent uses the most common ports that most ISPs will never block but that said, some still block ICMP.
While we use some custom ICMP methods for some of the tests, ICMP is still needed. -
-
O OutagesIO_Support marked this topic as a question on
-
Hi SBK,
Thanks for your response.
Our agent is returning the "Heartbeat/Status" and the "PING" results after restarting last night, but we still have the banner preventing us from licensing the agent and can't see any data under: "Breakdown of Internet problems" or "When Internet was down"
Thanks :)
-
The any/any incoming rule should allow ICMP too. Can you check that to be sure it's any/any.
-
@SBK said in Which ports to open on firewall to allow Agent to communicate?:
This is because your agent is not sending hops and this is due to blocked ICMP, which is weird since Pings are coming in
Yeah, my thoughts exactly. ICMP is open (any/any) on windows firewall on the server the agent is installed on. I am in the process of making sure ICMP is allowed on our organisational firewall. Looking at manufacturer docs it appears that in most cases the ICMP message service responses (ICMP_ECHO, ICMP_TIMESTAMP etc.) are dropped unless there is a policy that specifically allows them.
-
Yes, on consumer stuff, most times, ICMP is enabled but on business firewalls, typically, ICMP is disabled.
-
We have allowed ICMP on all outbound connections and have observed response packets being given the same treatment upon return.
Here's a tracert to google's dns from the same server as the OutagesIo Agent is installed on VIA our company firewall on 10.7.1.1.
1 1 ms <1 ms <1 ms firewall.bascom.local [10.7.1.1]
2 3 ms 1 ms 2 ms 156.67.241.1
3 6 ms 5 ms 5 ms 172.30.2.62
4 6 ms 5 ms 5 ms 172.30.1.226
5 6 ms 4 ms 5 ms 172.30.1.102
6 6 ms 5 ms 5 ms 172.30.1.100
7 5 ms 5 ms 5 ms 172.30.2.20
8 5 ms 4 ms 6 ms 142.250.162.12
9 6 ms 6 ms 6 ms 74.125.253.31
10 7 ms 7 ms 6 ms 216.239.63.219
11 5 ms 6 ms 5 ms dns.google [8.8.8.8]Can you provide the externa IP of one of your reporting servers so I can test in the same way please?
Thank you :)
-
Here's one to "Outages.io" but I don't know if that is the correct FQDN
Tracing route to outages.io [66.85.131.181]
over a maximum of 30 hops:1 1 ms <1 ms <1 ms firewall.bascom.local [10.7.1.1]
2 3 ms 2 ms 1 ms 156.67.241.1
3 7 ms 7 ms 6 ms 172.30.2.62
4 7 ms 7 ms 7 ms 172.30.1.229
5 8 ms 7 ms 8 ms 172.30.1.246
6 * * * Request timed out.
7 10 ms 10 ms 10 ms 172.30.1.54
8 7 ms 6 ms 9 ms 172.30.2.43
9 7 ms 9 ms 7 ms 195.66.244.191
10 131 ms 130 ms 131 ms ae16.cs1.man1.uk.eth.zayo.com [64.125.21.158]
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out. -
You can test against tpw.outagesio.com, most other things may not have ICMP replies enabled.
-
Thanks!
Tracing route to tpw.outagesio.com [66.85.130.3]
over a maximum of 30 hops:1 1 ms <1 ms <1 ms firewall.bascom.local [10.7.1.1]
2 3 ms 2 ms 3 ms 156.67.241.1
3 8 ms 9 ms 7 ms 172.30.2.62
4 8 ms 8 ms 8 ms 172.30.1.229
5 8 ms 7 ms 6 ms 172.30.1.246
6 * 6 ms 7 ms 172.30.1.253
7 11 ms 10 ms 11 ms 172.30.1.54
8 9 ms 7 ms 7 ms 172.30.2.43
9 8 ms 11 ms 7 ms 195.66.244.191
10 * 131 ms 131 ms ae16.cs1.man1.uk.eth.zayo.com [64.125.21.158]
11 * * * Request timed out.
12 * * * Request timed out.
13 * * 133 ms ae23.cs3.iad93.us.eth.zayo.com [64.125.28.189]
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 132 ms 131 ms 131 ms ae21.mpr3.phx2.us.zip.zayo.com [64.125.25.255]
18 130 ms 131 ms 131 ms 208.185.171.102.IPYX-149806-001-ZYO.zip.zayo.com [208.185.171.102]
19 131 ms 130 ms 131 ms eth.14.2.cr1.phx0.phoenixnap.com [108.170.0.21]
20 * * * Request timed out.
21 131 ms 131 ms 131 ms 66.85.130.3
22 131 ms 134 ms 132 ms 66.85.130.3Trace complete.
Is this what you would expect an Agent installed client to receive in this case?
-
Looks normal. Lots of ICMP blocking/limiting along the way it looks like.
So at this point, we have to assume that something on the host that the agent is running on is still blocking something.
Is there something running on the host that is a security manager or something or virus checker, something along those lines?
If you have another Windows host, you could install another agent, again, be sure you are admin when installing so that the firewall rule can be created then see if the dashboard shows that the agent is ready to be licensed.
Then please share the agent ID so we can look too.
-
Hi There,
So I've created as few more agents and attempted to install on various servers of various builds, Raspberry Pi, Ubuntu, etc. I also created an agent (ID: 131152) (LAN IP 10.10.1.90) on an windows server 2012 SFTP server and this one appears to be working!
I see the banner at the top of the prestaging dash stating
"Your agent is set up correctly, and ready for upgrade to all features.
Enjoy the free basic reports in the meantime."I'm going to leave it running for a bit to make sure we get the pretty pie chart with the hops.
AV firewall config should be unchanged from where the last windows agent was installed and nothing else has changed on the corporate firewall. I'm assuming that since this is a server we use to accept data transfers from external clients that it would have more network protection, not less. Will post the tracert now.
Tracing route to 66.85.130.3 over a maximum of 30 hops
1 1 ms <1 ms <1 ms 10.10.1.1
2 6 ms 7 ms 14 ms 83.98.55.73
3 4 ms 4 ms 4 ms ae20-10.lon-north-core.network.aspirets.com [83.
98.55.140]
4 4 ms 4 ms 4 ms et0-0-48.lon-west-core1.network.aspirets.com [5.
22.136.157]
5 4 ms 5 ms 5 ms 5-22-136-159.host.as51043.net [5.22.136.159]
6 5 ms 4 ms 4 ms ldn-b3-link.ip.twelve99.net [62.115.37.168]
7 5 ms 5 ms 6 ms ldn-bb2-link.ip.twelve99.net [62.115.122.180]
8 * * * Request timed out.
9 79 ms 79 ms 78 ms ash-bb2-link.ip.twelve99.net [62.115.136.201]
10 89 ms 90 ms 90 ms atl-b24-link.ip.twelve99.net [62.115.125.128]
11 110 ms 116 ms 110 ms dls-bb2-link.ip.twelve99.net [62.115.116.212]
12 129 ms 129 ms 129 ms phx-b6-link.ip.twelve99.net [62.115.125.55]
13 129 ms 130 ms 130 ms 80.239.194.110
14 129 ms 129 ms 128 ms eth.14.2.cr2.phx0.phoenixnap.com [108.170.0.37]15 129 ms 138 ms 129 ms 10.220.25.20
16 128 ms 131 ms 128 ms 66.85.130.3
17 129 ms 129 ms 129 ms 66.85.130.3Trace complete.
