Bug #12853
closedNetwork Address Translation - Pure NAT pfsense freeze after reboot
0%
Description
In the menu "System / Advanced / Firewall & NAT" (as shown in the image attached), if I apply the following changes to the "Network Address Translation":
- change with "Pure NAT" the section "NAT Reflection mode for port forwards";
- enable: "Enable NAT Reflection for 1:1 NAT"
- enable: "Enable automatic outbound NAT for Reflection"
All is working until the first reboot, then the machine cyclically freezes and it's not possible to ping, to access the web or to access the SSH Shell.
We temporally resolved the issue putting "Disable" in "NAT Reflection mode for port forwards" and changing to "Enable (pure NAT)" in every single NAT of the "Firewall / NAT / Port Forward / Edit" sections.
Files
Updated by Antonio Pesce almost 3 years ago
Michele D'Alessio wrote:
In the menu "System / Advanced / Firewall & NAT" (as shown in the image attached), if I apply the following changes to the "Network Address Translation":
- change with "Pure NAT" the section "NAT Reflection mode for port forwards";
- enable: "Enable NAT Reflection for 1:1 NAT"
- enable: "Enable automatic outbound NAT for Reflection"All is working until the first reboot, then the machine cyclically freezes and it's not possible to ping, to access the web or to access the SSH Shell.
We temporally resolved the issue putting "Disable" in "NAT Reflection mode for port forwards" and changing to "Enable (pure NAT)" in every single NAT of the "Firewall / NAT / Port Forward / Edit" sections.
We have the same problem, our pfSense (which is a VM on ESXi 7.0.2) is not rebooting, but the machine just freeze itself for some minutes (1-2).
With the "trick" proposed (Disabling Reflection) it works like a charm.
Updated by Jim Pingle almost 3 years ago
- Status changed from New to Feedback
That option alone does not cause a problem, there may be something in your ruleset contributing but as stated there isn't enough information to reproduce the problem.
Pure NAT reflection only adds pf rules to handle NAT. There isn't anything inherently problematic with that. If there are a lot of port forwards this could result in a large number of pf rules, which may make the firewall trigger #12827 .
At a minimum we'll need to see the NAT configuration from the systems in question, or at least some approximate info about the setup, such as the total number of port forwards, interfaces, and so on.
Compare the number of lines in the generated ruleset in /tmp/rules.debug with and without Pure NAT reflection enabled.
Updated by Michele D'Alessio almost 3 years ago
Jim Pingle wrote in #note-2:
That option alone does not cause a problem, there may be something in your ruleset contributing but as stated there isn't enough information to reproduce the problem.
Pure NAT reflection only adds pf rules to handle NAT. There isn't anything inherently problematic with that. If there are a lot of port forwards this could result in a large number of pf rules, which may make the firewall trigger #12827 .
At a minimum we'll need to see the NAT configuration from the systems in question, or at least some approximate info about the setup, such as the total number of port forwards, interfaces, and so on.
Compare the number of lines in the generated ruleset in /tmp/rules.debug with and without Pure NAT reflection enabled.
There are 168 NAT and the "Outbount NAT Mode" is set to "Manual Outbound NAT", tonight I'll try to compare the number of lines in the generated ruleset with and without Pure NAT reflection enabled, but if I enable the Pure NAT setting globally and I reboot the machine, I'll have only 50 seconds every 2/3 minutes, to disable the option because the Firewall will freeze.
Updated by Antonio Pesce almost 3 years ago
Jim Pingle wrote in #note-2:
That option alone does not cause a problem, there may be something in your ruleset contributing but as stated there isn't enough information to reproduce the problem.
Pure NAT reflection only adds pf rules to handle NAT. There isn't anything inherently problematic with that. If there are a lot of port forwards this could result in a large number of pf rules, which may make the firewall trigger #12827 .
At a minimum we'll need to see the NAT configuration from the systems in question, or at least some approximate info about the setup, such as the total number of port forwards, interfaces, and so on.
Compare the number of lines in the generated ruleset in /tmp/rules.debug with and without Pure NAT reflection enabled.
In our case we got
- pfSense Master VM on ESXi 7.0.2 with 16G of RAM, 32 vCPUs, 120 HDD diskspace - pfSense Backup Barebone PC with Intel J1900, 8G of RAM, 120 HDD diskspace.
- 9 Interfaces (including WAN and SYNC for HA)
- 12 Port Forwarding pointing to our internal systems.
- Manual outbound rule set.
- 378 lines of rules.debug without PureNAT and 435 lines with PureNAT.
Updated by Jim Pingle almost 2 years ago
- Status changed from Feedback to Closed
Doesn't seem to happen to anyone else and might have been related to other solved issues in PF with loading rules/memory leaks.
If someone can reproduce this on 23.01 or 2.7.0 snapshots, we can always reopen it if we get more information and a clear way to reproduce it.