Correction #10683
closed
Feedback on Firewall — Preventing RFC1918 Traffic from Exiting a WAN Interface
0%
Description
Feedback:
This part of the page (https://docs.netgate.com/pfsense/en/latest/firewall/preventing-rfc1918-traffic-from-exiting-a-wan-interface.html#steps-to-block-rfc1918-traffic-from-leaving-the-wan-interface) suggests that, by adding this Firewall Alias and Firewall Floating Rule, RFC1918 (and/or additional ranges) can be blocked from exiting WAN.
However, Floating rules are processed after Outbound NAT rules (cf. https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.html#processing-order). Therefore, if Outbound NAT is active (which is typically the case for residential use), the rule mentioned on the page cannot be used for this purpose.
The book suggests tagging/marking incoming LAN packets, and using that mark when processing the outbound traffic.
An extra caveat would be benificial here, e.g. "Warning: the following rule cannot be used in combination with Outbound NAT on the same outgoing interface(s)". Another solution would be to add marking of packets to also support Outgoing NAT.
Updated by G Mulder almost 4 years ago
Apologies. Just when I was reiterating my thought process on why I opened this feedback issue, I noticed that I swapped source and destination when applying this rule on my firewall. Then, yes, the above issue would be valid.
You may close this issue as invalid.
Updated by Chris Linstruth almost 4 years ago
- Status changed from New to Rejected
You are talking about a completely different issue than that page is describing.
That section describes a method of ensuring that traffic destined for RFC1918 addresses does not egress the WAN interface. This can occur when traffic exists for an RFC1918 destination that does not have a local route. That traffic should never be sent out to the routable internet.
Outbound NAT has nothing to do with this because that translates the source address not the destination address. If your rule is operating on the source address, it was not configured in the outbound direction on WAN blocking destination RFC1918.
Other methods need to be employed to match and block on the source address after NAT. One way is to just NAT for all RFC1918 sources. Another is marking and matching the traffic.
(You responded while I was typing this. Posting anyway.)