This thing is driving me crazy, pretty much ready throw the towel and switch to a geek firewall, at least I get control...
But before I do that, maybe the community can help.
Short version
My access point cannot ping a remote network (blocked with ICMP packets with invalid ICMP type/code.)
My own computer can (computer is on the same network as access point)
Long version
The configuration is a bit complex.
10.0.1.0/24 : My home LAN
10.1.0.0/16 : My LAB network
10.2.0.0/24 : a private network that links LAN and LAB together. As LAB is hidden behind another firewall, I had to throw an intermediate network in the mix
When I ping 10.1.0.107 from the LAN, here is what happens :
default gw is Sophos, its routing table indicates 10.1.0.0/16 gw is 10.2.0.2, it has its own alias as 10.2.0.1 local so forwards the packet.
Packet is received by the remote firwall (pfsense) that naturally routes it without MASQ to the LAB network.
Echo reply comes through, but for some reason, when the ping originated from the AP (10.0.1.116) it is rejected as "ICMP packets with invalid ICMP type/code." in rule 0, if it comes from my laptop, no issue at all.
Even worst : if from the AP I ping another host, *right next* to the one that fails, it works also.
It happens only with some hosts, and this is the firewall blocking echo reply as I see it in the logs.
Thoughts?
Even better, that's what the packet looks like in Sophos :
No MAC headers visible ??
Ethernet Header
Source MAC Address:
Destination MAC Address:
Ethernet Type IPv4 (0x800)
IPv4 Header
Source IP Address:10.1.0.107
Destination IP Address:10.0.1.32
Protocol: ICMP
Header:20 Bytes
Type of Service: 0
Total Length: 84 Bytes
Identification:23926
Fragment Offset:0
Time to Live: 63
Checksum: 2216
ICMP Header:
Type: 0
Code: 0
Echo ID: 10805
Echo Sequence: 3116
Gateway: 0
Fragmentation MTU: 0
Checksum: 23810
Here is some more insights, very interesting behavior.
This is right after a reboot of the device where I ping from :
BZ.v3.9.3# arp
? (10.0.1.108) at <incomplete> on br0
? (10.0.1.143) at dc:a9:04:8b:b4:c8 [ether] on br0
? (10.0.1.1) at 00:0e:c4:d0:9b:e1 [ether] on br0
BZ.v3.9.3# ping unifi.infrastructure.lab.tynsoe.org
PING unifi.infrastructure.lab.tynsoe.org (10.1.0.136): 56 data bytes
64 bytes from 10.1.0.136: seq=0 ttl=62 time=0.861 ms
64 bytes from 10.1.0.136: seq=1 ttl=62 time=0.960 ms
64 bytes from 10.1.0.136: seq=2 ttl=62 time=1.057 ms
64 bytes from 10.1.0.136: seq=3 ttl=62 time=0.699 ms
^C
--- unifi.infrastructure.lab.tynsoe.org ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.699/0.894/1.057 ms
BZ.v3.9.3# arp
? (10.0.1.108) at <incomplete> on br0
? (10.2.0.2) at 00:0c:29:85:fd:5b [ether] on br0
? (10.0.1.143) at dc:a9:04:8b:b4:c8 [ether] on br0
? (10.0.1.1) at 00:0e:c4:d0:9b:e1 [ether] on br0
BZ.v3.9.3# ping unifi.infrastructure.lab.tynsoe.org
PING unifi.infrastructure.lab.tynsoe.org (10.1.0.136): 56 data bytes
^C
--- unifi.infrastructure.lab.tynsoe.org ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Err, what?
The first ping goes through, but once I interrupt it, it has an additional ARP entry for 10.2.0.2, which should never be published, Sophos probably sent a ICMP redirect for some reason.
Once that ARP entry is there, I can't ping anymore as you can see.
I'm using 10.2.0.x only to isolate that 10.1.x.x network, Sophos can't have a leg on that one as it is completely behind another pfsense firewall, I'm just using 10.2.x.x as a funnel.
How can I make Sophos just route the packets as it should, and not announce ICMP redirects?
It seems that, Sophos having to route a packet on the same physical interface even though these are different aliases, sends a ICMP redirect.
Sophos doesn't support routing between aliases and I didn't know that. Problem solved I guess!