pfSense English Support > NAT

Upgrade from 2.3.3 to 2.3.4 broke IPv4 nat rules.

(1/3) > >>

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.


--- Code: ---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

--- End code ---

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..

Navigation

[0] Message Index

[#] Next page

Go to full version