Unhandled External Packet Using Speedtests

BradH

We recently enabled auto-block on Unhandled External Packet. One thing that happened when we did this was we could no longer use most speedtests, as they did not show any upload. I turned the auto-block off and screenshot the packet that was getting blocked in the traffic monitor. When the traffic goes out, it uses port 8080, but for some reason the same IP is trying to send a packet back on different ports. In the screenshot it shows port 40100, but these are always random port numbers when we run a speedtest. If it was predictable, I would simply add a policy that didn't auto-block on that port. Is the firewall assigning it a port to talk to and not allowing it in on that port? Really confused on what could be causing this. For some reason the screenshot is showing up very small, but "open image in a new tab" works.

Thank you,
Brad

xxup

Which speed test are you using? If it is oolka, then make sure that you are using www.speedtest.net . There are some fake ones out there. A few years ago, I made a custom packet filter policy with these ports:
843 TCP
8080 TCP
5060 TCP
8080 UDP
33430-33450 UDP

This policy is very old and I believe that oolka have simplified the port usage since that policy was originally written. I believe that only 8080/tcp is needed now.

Then after some trial and effort, I worked out the destination IP addresses of the responding servers. You need to do this for yourself as they vary by the city where you live as a means of removing distance-related latency from the results. These were then added to an alias named Speedtest-servers. The final policy is Any-Trusted (or you can limit it to desktop computers if you have designed your network work that way) -> Speedtest-servers.

I have just done a quick test and these are the log entries that I see.

_2022-06-23 15:57:57 Allow 10.0.10.7 58.96.3.192 webcache/tcp 50820 8080 Trusted-WIRED External-AussieBB Allowed 52 127 (Speed test-00) proc_id="firewall" rc="100" msg_id="3000-0148" route_type="SD-WAN" src_ip_nat="203.0.113.10" tcp_info="offset 8 S 3726634377 win 61690" geo_dst="AUS" src_user="xxxxxx" _

While the above log line was repeated a couple of times, there was no log showing 58.96.3.192 as a source IP address.

xxup

There is more information on port requirements here:
https://support.ookla.com/hc/en-us/articles/360027274852-Which-Ports-Am-I-Required-to-Use-

xxup

I have just cleaned up the speed test policy and these are the only needed ports:
8080 TCP
5060 TCP
8080 UDP (I have not seen any of this traffic)

Bruce_Briggs

@BradH:

I do not recommend using "Auto-block of source IP of unhandled external packets" as there will be many unexpected IP addrs ending up on the Blocked Sites list.

Some examples - HTTPS sites, DNS servers which have very slow responses

HTTPS site example - a HTTPS replay packet for which there is no longer a match in the sessions table:
2022-06-22 08:11:12 Deny 99.84.109.87 xxx.xxx.xxx.xxx 43755/tcp 443 43755 External Firebox Denied 40 235 (Unhandled-External-Packets-00) proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 5 A 2979741724 win 34048" geo_src="USA" geo_dst="USA" Traffic

xxup

Wrong post..

Bruce_Briggs

My post is for BradH, re: his auto-block comment.

james.carson

I would suggest against using the auto-block on unhandled feature unless you have a very specific reason to do so. Anything that matches this rule would have been dropped by the firewall anyways.

For example, the default connation timeout is 2 minutes. A client sends a email to a SMTP server that is busy. It responds with a connection reset 3 minutes later.
Since the connection is out of the connection table, this is a new connection, and since there's no inbound rule for port 25 (SMTP) the IP will now be blocked. The mail client on the PC has already moved on, and the user never sees any type of error.

Unless there's a very specific requirement for the firewall to do this, the feature generally causes more trouble than it's worth. If you have a specific port of concern, a custom rule can be made, and when set to deny, a checkbox will appear to auto-block connections that attempt to use this rule.

BradH

Thank you all for the responses. I suppose having auto-block off is best then. My main concern was just to prevent someone from trying to find a way in. It'd be a lot harder if every time you tried something, you had to wait a day. We typically don't have issues unless google tries to crawl us or something.

Bruce_Briggs

I have a few policies for a number of common ports which are scanned and have "Auto-block sites that try to connect" selected on that policy.

At the moment, I have lots of IP addrs blocked for Telnet and SSH access attempts.