Firewall Rules to Block PRIVATE IPv4/IPv6 address ingress/egress

KevinRice

This is my attempt and learning path to create tight firewall rules. This is what I've come up with based upon my best information and guessing. Please correct where I'm wrong, make suggestions, etc., and I'll incorporate.

Firewall rules to block private addresses

The usual inbound WAN block private/bogon rules only blocks source addresses (not destinations), but does filter both IPv4 private and IPv6 ULA addresses:

Floating "out" direction rules to block outbound packets on WAN interfaces:

IPv4 private destination
IPv4 private source address (in case NAT missed something, perhaps?)
IPv6 ULA destination address

I quickly discovered the rule rejecting outbound traffic to a RFC 1918 destination address blocked communication with my ISP's DHCP server; therefore, I added a floating Pass rule above the floating Block rules to permit (only) IPv4 UDP packets sent to port 67 (DHCP server) at any private address:

A somewhat questionable NAT rule handles inbound IPv4 packets with private RFC 1918 destination addresses:

This novel use of NAT is needed because NAT translation occurs prior to firewall rules, thus it's not possible in a firewall rule to determine if a packet has already been translated by NAT or if it entered the WAN with a private address to begin with. NAT redirects these packets to a "black hole" APIPA link-local address—I chose 169.254.86.86, which is blocked by default in pfSense.

The NAT rule is paired with this WAN interface rule because I want to log "black holed" packets. NAT rules can't be logged. However, I don't think this rule will ever match because the automatic pfSense rules to block APIPA packets occurs first in the firewall rule order.

DISCUSSION:

None of these types of addresses should enter/exit to the public WAN. Each ingress/egress scenario has my proposed concern and firewall "fix".

IPv4 Private (RFC 1918) Addresses (10/8, 172.16/12, 192.168/16)

WAN ingress with RFC 1918 address as:

destination—not dropped if destination matches an internal network, but a firewall rule would be needed to pass these packets, which is unlikely unless the destination matched a NAT port-forward address. Such packets would appear as if they already passed through NAT (because NAT address translation occurs prior to firewall rules). ISPs may send packets to RFC 1918 destinations to probe equipment, or misconfigured ISP routers may even permit your neighbors to send traffic.

Because NAT is processed first, a firewall rule cannot discern packets that entered the router with a RFC 1918 destination from packets which may have been translated by NAT to a valid local RFC 1918 destination. Therefore, to get in front of NAT, create a top-priority NAT rule matching RFC 1918 destinations and redirect packets to a "black hole" (or non-existent and unrouteable) private address, such as 169.254.86.86. You shouldn't need to create a corresponding firewall rule because the "black hole" address isn't routeable, but such a rule should work to provide an explicit block and for logging purposes. (See also: Scenarios where RFC 1918 addresses should not be blocked on the WAN)

source—Blocked by Block private networks setting. Also blocked by default anti-spoofing rule if source matches an internal network, but not dropped otherwise. If not blocked by these mechanisms, an existing firewall rule or NAT port-forward will pass these packets.

Ensure Block private networks setting is enabled. If this is not possible (See: Scenarios where RFC 1918 addresses should not be blocked on the WAN), a top firewall rule on the WAN should block traffic with a RFC 1918 source address. Alternatively, each NAT rule and firewall "Pass" rule should specify !RFC1918 for the source, denying a match and ensuring the "Default Deny" rule will block these packets.

WAN egress with RFC 1918 address as:

destination—packets will be routed to WAN if not matching an internal network. Potential for RFC 1918 packets to egress to WAN.

A floating firewall rule on WAN egress will block RFC 1918 destinations. An RFC 1918 alias can be created to enable such a rule. (See also: Scenarios where RFC 1918 addresses should not be blocked on the WAN. In such a scenario, you would omit the valid RFC 1918 addresses from any rule.)

source—packets should be translated by NAT to a public address if the source address matches a NAT rule. If there is no NAT rule match, a potential for "rogue" packets to egress to WAN exists.

Similar to blocking RFC 1918 destinations, a floating firewall rule on WAN egress can block packets with RFC 1918 source addresses. (See also: Scenarios where RFC 1918 addresses should not be blocked on the WAN) Additionally: Firewall Pass rules on internal networks should only permit traffic originating from the corresponding network using Source: ___ subnets to prevent rogue sources on each network from sending traffic through the firewall—not just to the WAN, but also other internal networks.

IPv4 APIPA Link-Local (RFC 3927) Addresses (169.254/16)

By default, pfSense blocks APIPA packets. This can be changed by the setting System > Advanced > Firewall & NAT > Advanced Options > Allow APIPA traffic.

Two automatically generated firewall rules block link-local packets on all interfaces (WAN and LAN):

block drop in quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local"
block drop in quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"

Packets on ANY interface with APIPA link-local address:

Ingress to any interface: destination or source—silently dropped by default.
Egress from any interface: destination or source—silently dropped by default. Because link-local packets are blocked from entering any interface, they can never be routed outbound of any interface.

No firewall rule is necessary unless Allow APIPA traffic is enabled.

IPv6 Unique Local Addresses (ULA) (RFC 4193) (fc00::/7)

WAN ingress with ULA address as:

destination—Does pfSense consider the destination address? Will a packet with a valid ULA address be routed to your internal network?

A floating firewall rule on WAN ingress should block RFC 4193 ULA destinations (in the unlikely event a packet matches your internal network.)

source—Blocked by Block private networks setting. Also blocked by default anti-spoofing rule if source matches an internal network, but not dropped otherwise.

Ensure Block private networks setting is enabled on IPv6 WANs.

WAN egress with ULA address as:

destination—packets will be routed to WAN if not matching an internal network. Potential for packets with RFC 4193 destination address to egress to WAN.

Floating firewall rule on WAN egress should block RFC 4193 destinations.

source—I'm really not sure what happens here... Can pfSense route a packet with a ULA source address to a WAN?

Firewall rules on LAN if not using ULA addresses: Block LAN traffic not originating from LAN Network. Otherwise, a floating rule on the WAN to block packets with a ULA source address.

IPv6 Link-Local Unicast RFC 4291 Addresses (LLA) (fe80::/10)

WAN ingress with IPv6 Link-Local address as:

destination—I believe pfSense drops all LLA packets? Can anyone provide proof?
source—Does pfSense consider the source address?

WAN egress with Link-Local address as:

destination—I believe pfSense drops all LLA packets? Can anyone provide proof?
source—Does pfSense consider the source address?

Special cases:

IPv6 ICMP Traffic

Unlike IPv4, certain ICMP traffic is required for IPv6 to operate. PfSense automatically generates rules on all interfaces to pass bare essential ICMP traffic. You don't need to worry about this.

Port 0 (IPv4 & IPv6)

PfSense also generates automatic rules to block TCP/UDP traffic from and to port 0 on all interfaces. This is another situation you don't need to worry about.

DHCP on WAN Interface

If your WAN address is obtained via DHCP, pfSense automatically generates rules to permit packets as follows:

Inbound UDP from any address port 67 to any address port 68.
Outbound UDP from any address port 68 to any address port 67.

A DHCP server can be at any address and is not necessarily the gateway address. ISPs may use RFC 1918 private address space, even if the gateway and your assigned IP are public addresses.

Localhost (127/8)

Blocking this subnet can result in pfSense update issues and a flood of General Log Entries:

kernel	pfr_update_stats: assertion failed.