Correction #12469
closedAutomatic outbound NAT rules are applied to the WG interface
Added by Brendon Baumgartner about 3 years ago. Updated almost 3 years ago.
0%
Description
These is back in the current wireguard package.
https://forum.netgate.com/topic/165344/wireguard-site-to-site-vpn/4?_=1634581750628
old issue https://redmine.pfsense.org/issues/11289
Updated by Jim Pingle about 3 years ago
- Project changed from pfSense to pfSense Packages
- Category changed from WireGuard to WireGuard
- Release Notes deleted (
Default)
Updated by Christian McDonald about 3 years ago
- Assignee set to Christian McDonald
Updated by Christian McDonald about 3 years 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.
Updated by Brendon Baumgartner about 3 years ago
Thanks. It would probably be useful to put a note about this in the docs for the s2s instructions.
Updated by Christian McDonald about 3 years 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
Thanks for the feedback.
https://gitlab.netgate.com/docs/pfSense-docs/-/merge_requests/25
Updated by Jim Pingle about 3 years ago
- Status changed from Waiting on Merge to Pull Request Review
Updated by Jim Pingle about 3 years ago
- Status changed from Pull Request Review to Closed
Merged and deployed.
Updated by Brett Keller about 3 years 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
Updated by Brett Keller about 3 years 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.
Updated by Viktor Gurov almost 3 years ago
- Status changed from Closed to Feedback
Updated by Danilo Zrenjanin almost 3 years ago
- Status changed from Feedback to Resolved
Tested against:
2.6.0-BETA (amd64) built on Sat Dec 25 06:19:11 UTC 2021 FreeBSD 12.3-STABLE
Help text looks OK to me. It contains all relevant info and links to understand what is going on when adding a gateway to the interface.
I am marking this ticket resolved.