Should I Unblock ICMP on the WAN?
-
Sorry if this is a dumb question but I was wondering if since everything is blocked by default on the WAN, should I create a WAN firewall rule to allow ICMP to pass?
If so what options should be chosen for the rule, such as ICMP Subtypes, Source and destination?
-
I generally allow ICMP from WAN. You only need to allow ICMP Echo request, I believe.
-
Depending on your setup blocking incoming ICMP may not make sense, for example if you already have ports open for incoming HTTP(S) traffic to your servers blocking ICMP buys you absolutely nothing and can in fact hamper the usability of your services for some users. If you have no ports open to the internet then you might block ICMP as well to make you effectively "stealth up".
-
I pass ICMP on all my WANs. I do not care about "stealth."
-
should I create a WAN firewall rule to allow ICMP to pass?
Thats really up to you. Not allowing means you will be more hidden as your device won't reply to online scanners. If this is a home setup than I would just leave it as is unless you have a reason. For me, I create Aliases with our ALCs that allow ICMP and remote access and don't leave anything open to the public unless it is required. Its not a security risk if you want to let it reply so you can ping it from anywhere. If you don't have a reason to ping it from unknown sources than I would keep it blocked but doesn't really hurt if you do.
If so what options should be chosen for the rule, such as ICMP Subtypes, Source and destination?
If your wanting your firewall to reply from anyone than:
Protocol: ICMP
TYPE: Echo Request
Source: Any
Destination: This Firewall
and choose if you want to log this.
-
@KOM:
I generally allow ICMP from WAN. You only need to allow ICMP Echo request, I believe.
Also, the unreachable ones, too big, timeouts etc.
-
well if youre planning to use ipv6 over ipv4, icmp over wan is mandatory.
else, mostly you dont need it.
-
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).
-
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.
-
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
-
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.
