ICMP Ping working 25.11?

Dslgeek

After a smooth upgrade to 25.11 I am unable to ping addresses outside of my network(all workstations/servers). This occurs with everything except 1.1.1.1 which is my gateway monitor IP. I have pass rules on my LANS+VLANS that were previously effective (source: lan subnet, destination: any ICMP:any). I am using a 6100 max and everything is working just fine without loss of service. I have a static WAN IP. Pinging 8.8.8.8 returns no response. Here is both a ICMP/UDP traceroute from PfSense .

ICMP to 8.8.8.8
1 209.107.254.185 2.200 ms 2.065 ms 1.912 ms
2 208.124.98.42 2.145 ms 4.018 ms 4.073 ms
3 208.124.112.58 2.937 ms 4.024 ms 4.090 ms
4 64.124.79.149 3.548 ms 3.991 ms 4.203 ms
5 * * *
6 * * *
7 72.14.211.84 8.506 ms 8.407 ms 8.878 ms
8 142.251.64.197 8.736 ms 8.265 ms 8.088 ms
9 142.251.231.249 7.122 ms 6.957 ms 6.884 ms
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *

UDP to 8.8.8.8
1 209.107.254.185 1.672 ms 1.878 ms 2.167 ms
2 208.124.98.42 3.895 ms 4.060 ms 4.023 ms
3 208.124.112.58 3.738 ms 3.991 ms 4.043 ms
4 64.124.79.149 4.417 ms 4.125 ms 3.961 ms
5 * * *
6 * * *
7 72.14.211.84 9.577 ms 8.328 ms 8.242 ms
8 * * *
9 8.8.8.8 7.408 ms 7.090 ms 7.024 ms

Has anyone experienced similar issues?

stephenw10

Hmm, nope not seeing any issues with ping on anything.

Is that from the 6100 directly or from a client behind it?

That traceroute shows it as an issue in the route though. No problem here though several 25.11 boxes:

[25.11-RELEASE][admin@1100-3.stevew.lan]/root: traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets
 1  192.168.126.1 (192.168.126.1)  0.522 ms  0.564 ms  0.433 ms
 2  * * *
 3  * * *
 4  128.hiper04.sheff.dial.plus.net.uk (195.166.143.128)  5.762 ms
    132.hiper04.sheff.dial.plus.net.uk (195.166.143.132)  5.640 ms
    128.hiper04.sheff.dial.plus.net.uk (195.166.143.128)  5.669 ms
 5  194.74.16.179 (194.74.16.179)  35.295 ms
    core4-hu0-0-0-2.colindale.ukcore.bt.net (62.6.204.233)  5.889 ms
    109.159.255.14 (109.159.255.14)  5.703 ms
 6  peer3-et3-1-4.redbus.ukcore.bt.net (194.72.16.186)  17.718 ms
    peer3-et7-0-1.redbus.ukcore.bt.net (194.72.16.74)  6.162 ms
    62.6.200.7 (62.6.200.7)  12.643 ms
 7  195.99.126.247 (195.99.126.247)  5.819 ms *
    142.250.171.140 (142.250.171.140)  6.133 ms
 8  dns.google (8.8.8.8)  4.110 ms  5.054 ms *
[25.11-RELEASE][admin@1100-3.stevew.lan]/root: traceroute -I 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 48 byte packets
 1  192.168.126.1 (192.168.126.1)  0.532 ms  0.452 ms  0.223 ms
 2  172.16.13.252 (172.16.13.252)  4.549 ms  4.547 ms  4.378 ms
 3  * * *
 4  132.hiper04.sheff.dial.plus.net.uk (195.166.143.132)  6.213 ms  5.412 ms  5.669 ms
 5  109.159.255.10 (109.159.255.10)  5.698 ms  5.745 ms  5.913 ms
 6  194.74.16.157 (194.74.16.157)  5.518 ms  5.604 ms  5.404 ms
 7  109.159.253.191 (109.159.253.191)  6.457 ms  8.304 ms  6.933 ms
 8  216.239.49.185 (216.239.49.185)  6.670 ms  6.233 ms  6.565 ms
 9  172.253.66.87 (172.253.66.87)  7.085 ms  6.945 ms  6.670 ms
10  dns.google (8.8.8.8)  5.911 ms  5.793 ms  5.746 ms

8.8.8.8 is an Anycast address though so not an ideal test here as the route will be different for everyone.

Dslgeek

That was from the 6100, but ping was blocked on all devices attached behind the 6100. I'll create an allow all interface rule and see if that works when I'm back in town.

Thanks!

johnpoz

@Dslgeek tracert via icmp is not really not the same thing as just pinging an IP. With a traceroute your going to be alternating the ttl, and hoping to get back a expired in transit message.

So traceroutes can miss hops or not get responses from specific hops in the traces.. And yeah as Steve mentions a ping or trace to a anycast could take all kinds of different paths depending on where your at, your isp peering, etc. etc. You could even see differences via the same isp and connection, etc.

I thought there was a ping issue with multiple windows clients at the same time.. Something about nat I believe and how pfsense tracks the states of icmp..

I thought 25.11 should fix the ping issue from multiple windows clients - but have not actually tested that yet.

stephenw10

Windows uses the same ICMP ID (1) for all pings so if you have two windows clients pinging the same IP it can create a state conflict. Though when I've seen that it's been a port forward accessed by multiple external clients from the same IP.

SteveITS

@johnpoz said in ICMP Ping working 25.11?:

ping issue with multiple windows clients at the same time

Yes, can't ping the same IP but can ping different IPs.

https://forum.netgate.com/topic/197245/can-t-ping-the-same-ip-from-multiple-devices/

There's a mention of 1:1 NAT or static outbound NAT but by the end that doesn't seem to be required per my testing.

stephenw10

Yup on inbound connections there's no port randomisation and the internal target is the same so it tries to create an identical state.