Should I Unblock ICMP on the WAN?

tagit446

I had initially asked my question after reading this article, "http://www.znep.com/~marcs/mtu/". I found this article while trying to find information on MTU which I am having a problem with.

For more details on the MTU problem I am having, see my other post "https://forum.pfsense.org/index.php?topic=146791.msg797486#msg797486" So far no one has replied to that post.

I am still trying to wrap my head around the above article I linked to but if I understand correctly ICMP is needed for proper MTU discovery.

The article also mentions filtering RFC 1918 addresses could cause similar problems as if ICMP is being filtered. From the article "If you are using such addresses, then ICMP messages (including "can't fragment" errors) will normally be generated using such addresses. Since many networks filter incoming traffic from such reserved addresses, the net result is the same as if all ICMP were being filtered and can cause the same problems."

I am probably misunderstanding but the article seems to suggest enabling ICMP would have no real effect if bogons are being blocked on the pfsense WAN (which they are).

JKnott

I am still trying to wrap my head around the above article I linked to but if I understand correctly ICMP is needed for proper MTU discovery.

Yes that's true and ICMP is also used for other error or status messages.

JKnott

I am probably misunderstanding but the article seems to suggest enabling ICMP would have no real effect if bogons are being blocked on the pfsense WAN (which they are).

My understanding of that is it will only fail, if the ICMP messages originates on a device with an RFC1918 address. How likely is that? If there's an RFC 1918 address that you can reach via the Internet, it's behind NAT, which should translate it back to whatever the public IP is. The only other instance I can think of is when packets are passed through a tunnel or VPN using an RFC 1918 address.

Also, that article mentions disabling do not fragment. Well, that's simply not an option on IPv6, as routers are not allowed to fragment at all, so no do not fragment flag.

Also from that article:

576 X.25 Networks

Way back in the dark ages, that was a common MTU for dial up connections (I used it with SLIP¹ to my first ISP, before switching to another ISP that supported PPP and 1500 MTU). I often wondered if there was some reason other than the efficiency vs data loss trade off over what were often noisy connections. But quite often, dial up was used to access X.25 networks. These were quite common way back then, with services such as Compuserve, The Source and others. My employer, at the time, provided a service called "Telenet" in Canada, which was an X.25 network. We had racks of X.25 "PADs" (Packet Assembler Disassembler) which connected dial in modems to a PR1ME computer

1. SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol

Derelict

Yeah. Block bogons and RFC1918 only affects connections coming into WAN with a SOURCE ADDRESS in those ranges. That should never happen with actual internet traffic and if it does you probably want it blocked anyway which is why that feature exists in the first place.

The only way that might happen is connections from the ISP device itself unless the firewall is inside your private network for whatever reason in which case you want to disable that feature.

if I sent out an echo request most likely I would need an echo reply to pass in, isn't it ?
the question is: how automatically generated outbound NAT can help me with this?

P.S.
or maybe there is a hidden set of rules comes into play
( not visible from our side of the fence... ) ?

NollipfSense

I have been struggling with this ICMP. I know it is harmless traffic, mostly router gossip; however, I cannot stand it tapping on my WAN door ... so I drop them.

Gertjan

@nollipfsense said in Should I Unblock ICMP on the WAN?:

I cannot stand it tapping on my WAN door ... so I drop them.

It's still tapping then, it's still there.
Dropping just means you spend a minimal of CPU cycles on it: "pfSense" doesn't react == send something back - on its arrival.

JKnott

@nollipfsense said in Should I Unblock ICMP on the WAN?:

I have been struggling with this ICMP. I know it is harmless traffic, mostly router gossip; however, I cannot stand it tapping on my WAN door ... so I drop them.

If you're running IPv6, you have to allow some in.

slimypizza

@tagit446
I wrote a heartbeat function on my external hosted site that will ping my pfsense router every few minutes through the WAN. If my router doesn’t respond then I get notified. So I have a rule that only allows ICMP (any) from the block of IP’s that my web host uses to ping me. Otherwise all other ICMP are blocked and I have not noticed any issues. I’m only using IPV4.

AKEGEC

@tagit446 Some ICMP types are dangerous. But some are needed like

3 Destination Unreachable
8 ICMP Echo Request (Ping)
11 Time Exceeded
12 Parameter Problem

But the authors of pfSense book advise you to allow any type ICMP. That is a NO NO!
If you don't need it then just block it.

NollipfSense

@gertjan said in Should I Unblock ICMP on the WAN?:

@nollipfsense said in Should I Unblock ICMP on the WAN?:

I cannot stand it tapping on my WAN door ... so I drop them.

It's still tapping then, it's still there.
Dropping just means you spend a minimal of CPU cycles on it: "pfSense" doesn't react == send something back - on its arrival.

Suricata drops them and don't notify me anymore ... not dropped at the firewall.

NollipfSense

@jknott said in Should I Unblock ICMP on the WAN?:

@nollipfsense said in Should I Unblock ICMP on the WAN?:

I have been struggling with this ICMP. I know it is harmless traffic, mostly router gossip; however, I cannot stand it tapping on my WAN door ... so I drop them.

If you're running IPv6, you have to allow some in.

No, that's the thing ... I need to get over my IPv6 shyness.

JKnott

@nollipfsense

Does your ISP provide it? If not, you can get it via tunnel from he.net.

AKEGEC

@tagit446 forgot to tell, don't forget to enable log for these rules.