RFC1918 Best Practices: Hardening WAN Egress Alias with APIPA/CGNAT on Static IP Connections?

JonathanLee

Hello fellow Netgate community members,

I am currently hardening a pfSense that has a dedicated Static Public IP assigned directly to the WAN interface.

Following the official Netgate recipe for Preventing RFC 1918 Traffic from Exiting a WAN Interface, I created a dedicated RFC1918 network alias to apply to my outbound WAN block rules. (floating rule)

To make it as comprehensive as possible for catching local information leaks or misbehaving local DHCP configurations, I included the main subnets along with the standard APIPA Link-Local block:

10.0.0.0/8 (Class A Private)
172.16.0.0/12 (Class B Private)
192.168.0.0/16 (Class C Private)
169.254.0.0/16 (Link-Local / APIPA)

My Questions for the Community:
Given that I have a true static IP setup (completely bypassing Carrier-Grade NAT on my side), is there any security benefit to manually injecting the CGNAT range (100.64.0.0/10) directly into this specific alias, or should it be left out to keep the alias strictly clean?

Is it preferred to handle CGNAT/APIPA entirely via the global "Block Bogon Networks" checkbox on the WAN interface settings page rather than nesting non-RFC1918 parameters inside a custom alias?

Would love to hear how other engineers structure this block for clean rule management. Thanks in advance for the advice!

Ref:
https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html

chpalmer

@JonathanLee "Given that I have a true static IP setup (completely bypassing Carrier-Grade NAT on my side), is there any security benefit to manually injecting" any private LAN type address?

No. Other than if you don't want to see the attempts. The WAN is already default block all unless you build a rule to allow something.

I personally would like any such attempts on my WAN side to show up in the "firewall logs". I rarely to never see any unless someone has erroneously (or for ill intent) did/does something dumb.. (like the local fire department did one time a few years ago.. )

marcosm

FYI there's already a built-in alias for those networks. See Firewall > Aliases > All

JonathanLee

@marcosm There is only onees I made in there.... must be something new right?

patient0

@JonathanLee said in RFC1918 Best Practices: Hardening WAN Egress Alias with APIPA/CGNAT on Static IP Connections?:

There is only onees I made in there.... must be something new right?

I think you gotta mention (in every thread) that you're on an ancient pfSense+ version with your 2100 ;).
The built-in alias' are a relatively new thing, yes.

JonathanLee

@patient0

It basically works fine .... I mean just type go to alias right?

johnpoz

@JonathanLee I am not exactly sure when the new built in aliases started, but they do include apipa and cgnat ranges - along with a few others

_reserved4_ 	Network(s) 	IPv4 networks reserved for local use.

0.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12,
192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 192.168.0.0/16, 198.18.0.0/15,
198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32

patient0

@JonathanLee said in RFC1918 Best Practices: Hardening WAN Egress Alias with APIPA/CGNAT on Static IP Connections?:

@patient0
<snip>
It basically works fine .... I mean just type go to alias right?

tinfoilmatt

Pretty sure it was only somewhat recently with the 2.8.x/25.xx releases.