Traceroute not working from LAN to any Internet destination
-
... and check "Quick" ( Apply the action immediately on match. ) for this rule.
-
That worked, thank you!
-
Does creation of that rule not introduce a new security risk by allowing any ICMP traffic inbound from the internet? That does not seem like an acceptable workaround to me.
-
Well depends how you gauge the risk, responding to pings is not high risk IMO.
But, yeah, I would not expect to have to allow that. Setting that to OUT only will likely also workaround the problem.
It's also not set as 'quick' which I would have expected....
Steve
-
There are 3-4 ICMP subtypes that should be open per various recommendations and security implications. The last time I checked it was "if one of those 4 get's an attacker inside - you have other problems then ICMP being used."
A good quick lookup is http://shouldiblockicmp.com/
For IPv4(legacy) there should be: Type 8/C0 (request), Type 3/C4 (fragreq), Type 11/C0 (timex). This can be reached with ICMP subtype selections: "Echo request", "Destination unreachable" and "Time exceeded" in a IPv4 ICMP rule. We're running that for years in a big datacenter environment - never had problems with it but much more debug capabilities and less problems with other networks upstream.
-
@stephenw10 said in Traceroute not working from LAN to any Internet destination:
Well depends how you gauge the risk, responding to pings is not high risk IMO.
But, yeah, I would not expect to have to allow that. Setting that to OUT only will likely also workaround the problem.
It's also not set as 'quick' which I would have expected....
Steve
I just run to the same issue running codel on 2.4.5
And the fix does the job, using direction out and quickWhat do you mean by >It's also not set as 'quick' which I would have expected.... ?
-
If you don't set the rule as 'quick' traffic matched by it will go on to be parsed by any other rules. Since it has to respond without matching the CoDel Limiter I expect it to require 'quick' there to prevent it being parsed the Limiter rule below it.
https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.html#quick
Steve
-
Yes, of course :)
It doesn't work without quick. Confirmed -
Hi, I have the floating rule and quick but Im getting the same problems. Am I missing something in my rules?!
traceroute www.ntua.gr traceroute to www.ntua.gr (147.102.224.101), 64 hops max, 52 byte packets 1 XX (X) 4.054 ms 1.243 ms 1.275 ms 2 www.ntua.gr (147.102.224.101) 8.807 ms 9.811 ms 10.076 ms 3 www.ntua.gr (147.102.224.101) 15.286 ms 9.946 ms 9.692 ms 4 * * * 5 www.ntua.gr (147.102.224.101) 14.548 ms 13.996 ms 13.006 ms 6 www.ntua.gr (147.102.224.101) 13.220 ms 15.703 ms 13.044 ms 7 * www.ntua.gr (147.102.224.101) 45.182 ms 43.441 ms 8 www.ntua.gr (147.102.224.101) 44.675 ms 44.498 ms 47.619 ms -
Don't specify an interface
and try moving it up a bit. The vpn egress seems to match traffic. -
@netblues the egress is there to stop things going via WAN when the VPN client is down. Shouldnt be first?
Updated the rules like this. still the same.
The other weird thing is that the two codel rules are matching very little compared to what the general "LAN" rule matches on the other tab.. hmmm
-
@daemonix Well, temporarily disable it and see if it matters. Floating rules are powerful but do have side effects.
-
@netblues no fun.. even without it traceroute isnt working.
What else it might be?
-
It just hit me...
traceroute on recent linux uses tcp...
try:traceroute -I ntua.gr -
Edited to remove the auto-link.
Linux uses UDP by default, yeah.
-
@stephenw10 -M method, --module=name
Use specified method for traceroute operations. Default traditional udp method has name default, icmp (-I) and tcp (-T) have names icmp and tcp respectively.
So its udp
at the same time. mtr is using icmp. I don't thing there is any workaround for udp traceroute and fq-codel -
This fixed my traceroute issue, but I do have two questions:
- Should ICMP type be set to all? Seems like there are other types of ICMP that are valuable to pass through?
- Is this is a pfSense bug? I don't recall needing this rule before, but perhaps it was because my system was not under load or I did not have limiters enabled?
-
https://redmine.pfsense.org/issues/9263
