Upgrade from 2.3.3 to 2.3.4 broke IPv4 nat rules.

rudger_wolvram

TL;DR Have IPv6 and IPv4 on LAN interface? Go to your LAN interface, change one setting, change it back, click Save.

Good news, I figur… well, no, I didn't, but I flubbed around until it "fixed itself"

It appears there may be a slight bug, I won't know if it's a bug or a one time thing unless others start having this issue.

What happened: ALL IPv4 NAT rules broke. This was not a configuration error on my part as much as a hiccup in pfSense. Somehow something got crossed on the LAN interface between IPv4 and IPv6 Rules.
Since that one feature was added that blocks the ability where people were able to add IPv6 NATs, I imagine something went haywire in the process of verifying and correcting during an upgrade.

I finally found the rule that was causing the problem, it was a standard IPv4 NAT rule. I deleted it, reloaded, the next rule in the list errored out.
I went through and re-edited and saved every rule to "rebuild" their config. No luck.

Out of sheer dumb luck I find myself looking at the LAN interface for oddities in IPv4 and IPv6 settings. I changed a setting, changed it back and out of habit clicked save. No actual change made.
Once the interface rebuilt itself all rules reloaded properly. I should note that I did not disable RDR on any NAT rule, this could be a compound culprit with the change to block IPv6 NATing in the GUI.

My Setup for reference:

COX ISP and ATT ISP on 2 separate interfaces, no VLANs
Tier 1 and Tier 2 Gateway groups. One for COX failover to ATT and one for ATT failover to COX
The 2 gateway groups are used because I policy route 1 XBox out ATT and everything else, including another XBox, goes out COX. Hence, 2 gateway groups.
IPv6 is set up on the COX interface, it's a direct /64 RA, not a tunnel broker.
LAN is set up with IPv4 Static and IPv6 Tracked Interface.

That tracked interface and a 2.3.3 config could be a place to check on the upgrade path to 2.3.4 as well. I don't know, I'm taking educated stabs based on evidence and potentials. The pfSense Gurus (compliment, not sarcasm) that built it will know better than me.

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>