This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ICMP packets with invalid ICMP type/code.

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?



This thread was automatically locked due to age.
  • 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!