PfSense 2.2 falling over when setting NAT rules
I'm testing 2.2 on Hyper-V (2012 R2) and I've come up against a strange problem I can't solve. pfSense works fine and appears to be perfectly stable for the most part, I've been running it for several days with constant test traffic and no issues.
The problem comes whenever I try to Add or Remove a NAT rule. Several seconds after the rule is applied pfSense stops responding. I can't access it via web or SSH, and any new requests to access the internet from the LAN fail (either by name or IP). However, any existing sessions are unaffected, for example if I have a constant ping running it will continue to be successful, but any new pings will fail, even from the same LAN machine to the same destination.
The console remains responsive, and I can ping from it to other machines (either WAN or LAN).
The only way I can bring it back to life is either a complete reboot, or by disabling or enabling SSH access from the console. The system log shows nothing of interest, so I'm at a loss where to go from here.
I've been running 2.0.3 in the same environment for some time, so these appears to be a 2.2 issue. I would guess something is crashing which gets restarted when I toggle SSH access, but I don't know what. Does anyone have any ideas?
Sounds similar to something someone else was seeing in Hyper-V, but I never could replicate. I think disabling and enabling SSH fixes because it triggers a filter reload, rather than anything to do with SSH itself. Replicate the issue, then go to the console, choose option 8, and run:
Does that on its own fix it? That'll help narrow down the possibilities at least.
Thanks for the prompt reply.
Yes I can confirm that running /etc/rc.filter_configure_sync fixes the issue. So it's a problem with the filters not loading/reloading correctly after the rule update?
Are there any suggestions on how to fix this? Maybe even a work around to run the /etc/rc.filter_configure_sync command automatically when the rules are saved?
It's very difficult to configure my firewall when I have to keep restarting it manually every time.
Any suggestions greatly appreciated.
It's likely a consequence of timing bugs in Hyper-V w/FreeBSD that seem to affect a few people in a bad way. Everyone seems to see the occasional "runtime went backwards" logs in Hyper-V, but for the majority it's only cosmetic. Or possibly an issue reading from the disk. You're the second person to see this, and I didn't get any idea from the other where specifically it may have happened.
What does the output of "pfctl -sn" at the console show after making a change leaving the system non-functional?
Yes I've had the odd "runtime went backwards" message, particularly in my old 2.0.3 build, but it never caused an issue. This version hasn't had that error for a few days now, it certainly doesn't seem to happen when this error occurs.
The output of pfctl -sn is:
no nat proto carp all
nat-anchor "natearly/" all
nat-anchor "natrules/" all
no rdr proto carp all
rdr-anchor "relayd/" all
rdr-anchor "tftp-proxy/" all
rdr-anchor "miniupnpd" all
Thanks for your help.
Strange, not sure how it'd end up with that much of it, but none of the rest. Could you get me access to that system, or any system that can reliably replicate that? PM me and we can arrange specifics.
I am having this issue as well on pfSense 2.2 release, Windows Server 2012 R2 Datacenter edition. I can provide you with access to my system if you wish? Have yet to try the filter reload command provided above, will try it soon though as I am editing rules currently and just finished rebooting the system to regain connection.
/etc/rc.filter_configure_sync ```worked for me as well
Wizard-ICT got in touch offering to get me into his system, I should be able to track things down from that. If I don't hear back from him, I'll get in touch with you rearmedhalo. Thanks!
This should be fixed in 2.2.1. You can gitsync to RELENG_2_2 or apply the patch from the commit in this ticket.
to get the fix.
It was easily replicable on Wizard-ICT's system before, and no longer is replicable, so seems this should be fixed.
I just installed 2.2 on Vmware ESXi 5.5 and i have exactly same problem.
Can i apply the patch for fix?
install the 'system patches' package and you can just copy/paste the commit-id's and apply