ICMP Redirect - Why is it occurring and how to disable?
-
Hey All -
I am curious why my pings appear to be a bit different than usual after installation of PFSense. I have a basic network (1 gateway - LAN: 192.168.0.254 (PFSense), a 24 port PoE switch and 4 wireless access points that are also connected to the switch. Everything is on the same private network.
Attempting to ping any other local LAN device while connected via one of the access points results in what I believe is an ICMP redirect:
ping 192.168.0.252
PING 192.168.0.252 (192.168.0.252): 56 data bytes
36 bytes from PFSENSE (192.168.0.254): Redirect Host(New addr: 192.168.0.252)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 c0 0054 e34c 0 0000 40 01 140e 192.168.0.66 192.168.0.25264 bytes from 192.168.0.252: icmp_seq=0 ttl=64 time=3.118 ms
36 bytes from PFSENSE (192.168.0.254): Redirect Host(New addr: 192.168.0.252)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 c0 0054 b243 0 0000 40 01 4517 192.168.0.66 192.168.0.25264 bytes from 192.168.0.252: icmp_seq=1 ttl=64 time=3.161 ms
^CHowever, hardwired connections do not have this redirect when pinging. The access points get their LAN IP from DHCP (via PFSense) so it seems odd to me that WiFi connected devices experience this ICMP redirect only. Any ideas?
On a side note, I've also noticed trace routes are slightly different. LAN devices connected via ethernet do not show the PFSense hop however WiFi connected devices do show the 192.168.0.254 (PFSense) hop in the trace route.
Thanks
-
What kind of access points are these, and how are they configured?
-
client isolation on accesspoints ?
-
-
what do wired clients show as their first hop, or you saying they don't just get an answer?
C:>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfSense.local.lan [192.168.9.253]
2 10 ms 8 ms 9 ms 96.120.24.113
3 14 ms 10 ms 13 ms te-0-5-0-8-sur04.mtprospect.il.chicago.comcast.net [68.85.180.133]
4 13 ms 10 ms 12 ms te-3-11-0-0-ar01.area4.il.chicago.comcast.net [69.139.202.129]
5 12 ms 12 ms 12 ms be-33491-cr02.350ecermak.il.ibone.comcast.net [68.86.91.165]IF pfsense is the first hop, then it should show up as such..
-
what do wired clients show as their first hop, or you saying they don't just get an answer?
C:>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfSense.local.lan [192.168.9.253]
2 10 ms 8 ms 9 ms 96.120.24.113
3 14 ms 10 ms 13 ms te-0-5-0-8-sur04.mtprospect.il.chicago.comcast.net [68.85.180.133]
4 13 ms 10 ms 12 ms te-3-11-0-0-ar01.area4.il.chicago.comcast.net [69.139.202.129]
5 12 ms 12 ms 12 ms be-33491-cr02.350ecermak.il.ibone.comcast.net [68.86.91.165]IF pfsense is the first hop, then it should show up as such..
They do not see the PFSense hop - on an internal trace route. On a WiFi connected device also tracing an internal IP the PFsense hop does appear however.
-
What kind of access points are these, and how are they configured?
These are the Aruba IAP-225 access points - so far, it appears to be something occurring as a result of IPv6 - I turned off IPv6 in PF Sense on the LAN and WAN, released and renewed all clients and rebooted all access points and so far…things are working as normal.
Going to experiment a bit more later this evening to see if thats truly the source of the problem.
-
ipv6 would have nothing to do with an ipv4 traceroute.
Are you saying your trace was coming back as ipv6?
As to not seeing first hop, lets ask this again are you saying your first hop was showing pubic IP?? Not pfsense? Or did it come back without an answer
1 * * *
2 isp gatewayor what it
1 isp gateway.
