MTR is waiting for reply, how to fix it?

[benoitc]

I get the following answer when querying 1.1.1.1 from my machine:

MacBook-Pro-de-Benoit-8.local (10.0.1.33) -> 1.1.1.1 (1.1.1.1)                                                                       2024-09-12T11:55:00+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                                     Packets               Pings
 Host                                                                                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 10.0.1.1                                                                                                        0.0%   602    0.2   0.3   0.2   3.7   0.2
 2. (waiting for reply)
 3. (waiting for reply)
 4. (waiting for reply)
 5. (waiting for reply)
 6. one.one.one.one                                                                                                 0.0%   601    2.0   2.4   1.8  83.9   5.3

Where it correctly works on the firewall. I have tested many combination of the PF configuration including the following one but the issue persists:

table <lan> persist file "/etc/pf/lan.tbl"
IP_OUT = "<EDITED>"

ext_if = "vlan200"

# Macros
set block-policy drop
set skip on lo0  # Skip filtering on localhost
set skip on lo1

#scrub in all
# Options
scrub in all fragment reassemble  # Normalize and reassemble fragmented packets


# nat
nat inet from <lan> to !<lan> -> $IP_OUT

# Explicitly block unroutable addresses
antispoof quick for ($ext_if)


# Allow all ICMP (IPv4)
pass in on $ext_if proto icmp from any to any
pass out on $ext_if proto icmp from any to any

# Allow all ICMP6 (IPv6)
pass in on $ext_if proto icmp6 from any to any
pass out on $ext_if proto icmp6 from any to any

# Enable state tracking
pass in quick on $ext_if proto { tcp, udp } from any to any keep state
pass out quick on $ext_if proto { tcp, udp } from any to any keep state

# Pass untracked (new) packets
pass in on { vlan10, vlan20, vlan30, vlan31, vlan110, vlan120 } proto { tcp, udp  } from any to any no state
pass out on { vlan10, vlan20, vlan30, vlan31, vlan110, vlan120 } proto { tcp, udp } from any to any no state

# Drop invalid packets
block drop in quick on $ext_if proto { tcp, udp } all

Any idea what could be the issue. On this machine I have also unbound which ip is passed to machines on the lan as DNS using kea. Any idea is welcom

 

[SirDice]

You should look at the settings on the intermediate routers between this host and the destination.

 

[benoitc]

when I ping from the host where PF is installed I have no iissue. It's only on the machines on the lan behind the firewall host that the problems apprear. It seems to be a problem zith ICMP ECHO. using the -T and -u option work.

That said I have also updated the machine before the host (its next hop) I will check this one too. Good idea

 

[SirDice]

when I ping from the host where PF is installed

You do know how mtr(8) works right? ping(1) only shows the response from the destination, and the destination isn't the problem, that one shows up on the mtr(8) output too. It's the intermediate 'hops' aka routers in between, not the source, nor the destination.

 

[VladiBG]

In provider network the MPLS routers can show they hops using "mpls ip propagate-ttl" but it's not recommended as this will disclose the internal CGNAT network of the ISP.
When the ISP doesn't use MPLS and they want to hide the routers in between they drop some IGMP types. That's why you never see the full picture of the bgp from the end device.

 

[benoitc]

SirDice i know how it works and that's why it doesn't make sense for me. Why mtr would work on the machine on top (the firewall) and not behind. All ICMP is allowed. Using mtr.tools I have no issue to trace until the firewall. TCP and UDP traceroute/mtr work , so it doesn't seem to be an issue with the nexthop? What should I check? In noticed this appeared after the upgrade to latest 14.1 release.