Upgrade from 2.3.3 to 2.3.4 broke IPv4 nat rules.

rudger_wolvram

Well, I say that, but it actually only broke 1 rule, now, all the rest of the nat rules are not loading, including the outbound. Bad part is, I don't know how many will break once this one rule is fixed.
Luckily, I've set up IPv6 and pfSense.org has taken the leap and put all their stuff on IPv6 as well so I can at least reach the forums.

Error:
/rc.filter_configure_sync: New alert found: 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 { tcp udp } from igb0 to 192.168.1.72

I'm using IPv4 gateway groups (2 ISPs) but it seems that until I can fix this error and the rest of the rules load, I'm stuck with IPv6 Only. I tried using just a specific gateway without the groups but no dice their.

This rule itself does not exist, I'm not sure it ever did. igb0 is my LAN interface, I have no reason to create such a silly rule. I did however, upgrade my hardware and the interface ID's changed, but never had any issues with that upgrade. I did have a no nat rule in place once for that particular IP, but not any more. I also found that I can increase the line number of the error by 1 (to 77) if I create a 1:1 nat, so I believe it's there. Even re-creating it exactly as the error has it yields nothing.

I've been digging through files trying to find where it could be coming from. I removed all possible rules from /cf/config/config.xml (I made a backup) and reloaded and rebooted to no avail. I've dug through that particular rc and through filter.inc trying to find the rule file it's pulling in to no avail.

So I guess my real question is, where in the filesystem can I delete that one rule at so the filters can reload properly?

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>