Upgrade from 2.3.3 to 2.3.4 broke IPv4 nat rules.

rudger_wolvram

This hit me again, this time on just a basic reboot. I had some ipv4 rules fail to reload and I lost IPv4 connectivity again since it never got to the IPv4 outbound NAT rules.


There were error(s) loading the rules: /tmp/rules.debug:76: rule expands to no valid combination - The line in question reads [76]: no nat on igb0 proto udp from igb0 to 192.168.1.50 port 50000:65535
@ 2017-06-24 22:21:20
There were error(s) loading the rules: /tmp/rules.debug:76: rule expands to no valid combination - The line in question reads [76]: no nat on igb0 proto udp from igb0 to 192.168.1.50 port 50000:65535
@ 2017-06-24 22:21:22
There were error(s) loading the rules: /tmp/rules.debug:76: rule expands to no valid combination - The line in question reads [76]: no nat on igb0 proto udp from igb0 to 192.168.1.50 port 50000:65535
@ 2017-06-24 22:21:28
There were error(s) loading the rules: /tmp/rules.debug:76: rule expands to no valid combination - The line in question reads [76]: no nat on igb0 proto udp from igb0 to 192.168.1.50 port 50000:65535
@ 2017-06-24 22:21:29

I tried my post's above "fix" I found of changing one setting on the LAN interface, then changing it back. Save -> Apply, and everything came back up. No other troubleshooting attempted, it worked on the first attempt.

So pfSense forum goers, do we think this is a bug or something that's just wonky with my setup and hardware? i.e. should I submit a bug report about it? Hate to clutter their work if it's something weird with my setup only because I've not seen any replies saying they have seen this issue as well.

rudger_wolvram

So this is happening on every reboot now. I found this out because something funky is going on with the second XBox losing Live party chat. It works, then never works again, reboot, fix NAT rule failures and get IPv4 back, party chat works for 1, maybe 2 sessions, then dies again. That's a separate problem.

Since there hasn't been any replies to this saying they are having the same issue my next step is to save the config and rebuild the box. See what happens and what not.

chpalmer

Rebuild and compare your config.xml later and see if anything is different.

Start easy. Just go with default settings and do one thing at a time to see if it comes back. I.E. dual WAN first.. Im not sure why you would even have to touch your NAT settings..

xternal

Hey, I am getting the same issue

php-fpm 54740 /rc.filter_configure_sync: New alert found: There were error(s) loading the rules: no IP address found for 2a03:f4c8801:80:204::/46 - The line in question reads [0]:

craps NAT out every reboot. I tried your fix and it worked.
Did you ever get to the bottom of it?

bronzeblood

Im having the same issue, Seems like a bug to me. I don't restart pfsense often but every time i do i have the exact same problem.

rudger_wolvram

@bronzeblood:

Im having the same issue, Seems like a bug to me. I don't restart pfsense often but every time i do i have the exact same problem.

Are you on 2.3.4_1 or just 2.3.4? I've not upgraded yet and haven't had a chance to rebuild from scratch to test. I've also not upgraded yet to 2.3.4_1 yet either.
Also, does changing a setting on your LAN interface then changing it back and saving correct everything?

ischilling

I can confirm this bug is also in 2.4.1 - even though I hoped it is fixed, it isn't.

Even worse, I found that prior to 2.4.1 this bug did just prevent NAT from working - with 2.4.1 it does also stop any Internet traffic from LAN to WAN unless you delete the rules in question or do the here described trick … :x

mlanner

I reported the same, or similar, behavior here: https://forum.pfsense.org/index.php?topic=138457.0

I have not yet tried the proposed temporary fix. This definitely seems like a bug to me. I've looked on the pfSense bug tracker (https://redmine.pfsense.org/projects/pfsense/issues?set_filter=1&tracker_id=1) if anything like this has been reported, but I have yet to find a corresponding entry.

mlanner

@ischilling

I think what you experienced is actually that the "States Table" had to be reloaded/flushed. I had the same problem as you describe after upgrading to 2.4.1, but after reloading states after one single change to the firewall, everything started working again. My assumption is that that change triggered a reload of the states table, which subsequently resolved me not having Internet access.

rudger_wolvram

<breaks out="" dead="" horse="" beatin'="" stick="">Oh wait, nevermind.
So, I finally found time to upgrade from 2.3.4 to 2.4.0.
This upgrade seems to have fixed the rule issue I originally posted about. I upgraded and didn't have to do any wonky LAN setting changes to get IPv4 working again.
So I'm going to chalk this up to weirdness in 2.3.4 since 2.4.0 doesn't seem to have this issue and since everyone should probably update to 2.4.x I'm guessing this will get no more traction as it's now out of date. Upgrades /woot.

Now, to figure out why my dashboard says 2.4.2. is available but the update says I'm up to date at 2.4.0.</breaks>