Project

General

Profile

Actions

Correction #12469

closed

Automatic outbound NAT rules are applied to the WG interface

Added by Brendon Baumgartner about 1 month ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
WireGuard
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Actions #1

Updated by Jim Pingle about 1 month ago

  • Project changed from pfSense to pfSense Packages
  • Category changed from WireGuard to WireGuard
  • Release Notes deleted (Default)
Actions #2

Updated by Christian McDonald about 1 month ago

  • Assignee set to Christian McDonald
Actions #3

Updated by Christian McDonald about 1 month ago

Outbound NAT rules are not applied on unassigned tunnel interfaces. pfSense has no way of knowing these interfaces exist because they are created and managed external to the built-in pfSense tooling. For assigned tunnel interfaces, the inverse is true...pfSense has no way of knowing that these assigned interfaces are WireGuard tunnels and should be excluded from outbound NAT. The workaround for assigned interfaces would be to create 'Do not NAT' rules when in hybrid mode OR use manual outbound NAT.

Actions #4

Updated by Brendon Baumgartner about 1 month ago

Thanks. It would probably be useful to put a note about this in the docs for the s2s instructions.

Actions #5

Updated by Christian McDonald about 1 month ago

  • Tracker changed from Bug to Correction
  • Project changed from pfSense Packages to pfSense Docs
  • Category changed from WireGuard to WireGuard
  • Status changed from New to Waiting on Merge
Actions #6

Updated by Jim Pingle about 1 month ago

  • Status changed from Waiting on Merge to Pull Request Review
Actions #7

Updated by Jim Pingle about 1 month ago

  • Status changed from Pull Request Review to Closed

Merged and deployed.

Actions #8

Updated by Brett Keller about 1 month ago

Christian McDonald wrote in #note-3:

For assigned tunnel interfaces, the inverse is true...pfSense has no way of knowing that these assigned interfaces are WireGuard tunnels and should be excluded from outbound NAT. The workaround for assigned interfaces would be to create 'Do not NAT' rules when in hybrid mode OR use manual outbound NAT.

Instead of creating "Do not NAT" rules to preempt and counteract the automatic outbound NAT rules, it is actually possible to prevent the outbound NAT rules from being created for the assigned WireGuard interface without having to globally disable automatic outbound NAT rules.

I ran into this exact problem yesterday while setting up my first WG site-to-site tunnel, and I spent a good long while banging my head to figure out why I was getting unwanted outbound NAT rules for free. I kept looking for some sort of setting on the interface that would opt it out of automatic outbound NAT, but nothing stood out as being relevant. I only realized much later that this is exactly what the "IPv4 Upstream gateway" setting does. Setting an upstream gateway includes the interface in automatic outbound NAT rule generation, and selecting "none" opts out. I changed this to "none" for my assigned WG interface, and I'm now happily passing unNATted traffic over the tunnel.

Because "IPv4 Upstream gateway" makes no mention of NAT in its help text, I repeatedly passed by this setting. I've submitted a pull request to update the help text and make it explicit that this setting affects automatic outbound NAT rule generation:
https://github.com/pfsense/pfsense/pull/4541

Actions #9

Updated by Brett Keller about 1 month ago

Brett Keller wrote in #note-8:

Setting an upstream gateway includes the interface in automatic outbound NAT rule generation, and selecting "none" opts out. I changed this to "none" for my assigned WG interface, and I'm now happily passing unNATted traffic over the tunnel.

I have to amend my previous statement. While changing "IPv4 Upstream gateway" to "none" does indeed remove the assigned WireGuard interface from automatic outbound NAT rule generation, it also removes reply-to from the interface's firewall rules, which definitely breaks things by leaking reply packets to the WAN interface. I ended up switching back to selecting an upstream gateway and using the "Do not NAT" rule strategy instead, as Christian McDonald recommended.

I've updated my pull request to reflect that this setting affects both reply-to and automatic outbound NAT.

Actions

Also available in: Atom PDF