Traceroutes appears to be broken?
-
I can't tell if this was a change of the ISP or due to the Beta version of the firewall, but for some reason, traceroutes will have complete packetloss until it reaches the destination server. Here is an example using the mtr package.
Running mtr -w -c 10 -i 1 208.91.112.220:
Start: 2025-02-18T08:44:22-0500
HOST: pfSense.geekhouse.home Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
4.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- 208.91.112.220 0.0% 10 23.2 24.7 20.2 35.3 4.9 -
@gisuck said in Traceroutes appears to be broken?:
mtr -w -c 10 -i 1 208.91.112.220
mtris not on my 25.03-BETA, installed yourself? -
@patient0 It's mtr-nox11 in Package Manager. It'll create an mtr link under Diagnostics.
-
@patient0 I'm also noticing this problem on all the windows client on my network just using the standard tracert command.
-
@gisuck you're right, forgot about it :/ ... thanks for pointing me to it.
Maybe a firewall rule issue. If I installed the package and disable
pf, it works when runningmtr -n 1.1.1.1 -
Only MTR or regular traceroute too?
Same result with udp and icmp?
Do you have any sort of traffic shaping? Outbound CoDel limiters?
-
@stephenw10 from what I can tell, using the mtr package on pfsense and on my windows clients, trace routes do not work. Ping can reach it's destination just fine. Problem exists on both IPv4 and IPv6.
While I did have CoDel installed, I had it disabled and decided to keep it that way since I couldn't account for Speedboost technology from my ISP where my subscription will burst at a higher speed than subscribed for a short period of time.
I still had the rules installed. I just removed those now and still have the problem.
-
@stephenw10 for me
traceroute -P udp -n 1.1.1.1does work buttraceroute -P icmp -n 1.1.1.1does not.No CoDel or any limiters.
Adding a ICMP allow any rule on WAN does make it work (for testing only of course)
Addition: Doesn't work on 2.7.2 CE either without any additional rules. Is it supposed to work? That would also mean that per default the WAN can be pinged from the world, does that make sense?
-
Ok seeing that here. Digging...
-
Works fine in 2.7.2 for me. Unless that traffic is going through 25.03.
-
@stephenw10 said in Traceroutes appears to be broken?:
Works fine in 2.7.2 for me. Unless that traffic is going through 25.03.
Hehehe, you got a point. The 2.7.2 CE is behind the 25.03 :)
-
So, just to be clear, this does appear to be a problem within 25.03? Just wondering if it was my ISP doing something weird. I thought this worked fine in 24.11, but it's been awhile since I required to do a traceroute to something.
-
@gisuck yes it seems to be an issue with 25.03. Works on my prod 24.11 and on a 2.7.2.
The 2.7.2 first was behind the 25.03 and therefore I got the impression it didn't work. But after stephenw10's comment I moved it (behind a VyOS router) and it does work too.
-
Yup it is. Fix is incoming.
As a test it should work normally in the current public beta is you set 'Firewall State Policy' to Floating States. If it doesn't then you might be hitting something else. Like ISP shenanigans!
-
@stephenw10 said in Traceroutes appears to be broken?:
set 'Firewall State Policy' to Floating States
Works excellent if 'Firewall State Policy' is set to 'Floating States'.
Something OT: In the ''Firewall State Policy', in the explanatory paragraph for 'Interface Bound States' are two tiny typo:
" ... If a packet attempts to takes an path through ..."
should be
" ... If a packet attempts to take a path through ..." -
This post is deleted!