Upgrade 2.4.3 to 2.4.3_1 error in firewall rules
-
I am looking also to debug this as I am affected.
-
According to this bug report, there is a work around: https://redmine.pfsense.org/issues/8518
Delete and re-add the default gateways.
-
I confirm the fact I had to delete an IPV6 Default Gateway (on the interface causing the wrong rule) to get the system back to normal behaviour. This interface also have an IPV4 gateway that is NOT a default gateway.
After recreating the default IPV6 gateway, problem did not occur anymore.
The wrong rule was created by line 3623 of filter.inc
-
Erratum.
Problem still here.
investigating -
I tried deleting and re-adding the default IPv4 and IPv6 gateways, the CARP VIP's and editing the '/tmp/rules.debug'.
While all these work they only work for a short while as any changes cause pfSense to add the rule back in again.
I have now rolled back the effected pfSense boxes to 2.4.2 which does not have this issue.
-
I understand what happening, I have an interface using IPV4 + IPV6 in a cluster configuration.
I have a CARP VIP for IPV4 and IPV6It looks like the code parsing the VIPs misunderstand the IPv6 CARP VIP as a ipV4 VIP so it enter the ipv4 loop and because " $gw = get_interface_gateway($ifdescr)" returns the IPV4 GW, then tries to generate the pass out rule on empty values…
I removed my IPV6 CARP on the WAN interface and there is no more problem.
-
checking the diff between 2.4.2 and 2.4.3 P1
before
if (is_ipaddrv4($gw) && is_ipaddrv4($ifcfg['ip'])) {After
if (is_ipaddrv4($gw) && is_ipaddrv4($ifcfg['ip']) && is_subnetv4("{$ifcfg['sa']}/{$ifcfg['sn']}")) { -
Good to see that you have been able to track down the cause of the issue.
I presume that the next release will have a fix for this?
-
All is related to this bug https://redmine.pfsense.org/issues/8408
https://github.com/pfsense/pfsense/pull/3924
looks like not eveything merged to current ?
-
The commit from that PR is in master and RELENG_2_4_3, and is in 2.4.3-p1.
I could reproduce the problem before that commit but not now. What exactly does your configuration look like (config.xml entries, at least) for the affected VIPs and gateway?
I wanted to put some extra safety belts around that rule to make sure it couldn't be blank but following through the code it already appeared to be validated higher up.
-
Since I can't reproduce this still, and I don't have any config samples to work from, try this patch:
https://gist.githubusercontent.com/jim-p/f5fa7cf5fdfc8166f54394262386682f/raw/1ff237a9a52cef67c03db532c80fcc757969e711/8518.diff
That doesn't fix the root cause but it will prevent the broken rules from being placed in the ruleset.
It's still not clear how a blank entry is making into that v4 VIP array in the first place since it explicitly tests for v4 or v6 when making the array. That's why I need to see the config samples so I can get closer to the root of the problem.
-
Hi jimp,
I just send you a PM with my config snippets. I figured you might need them unredaced, so I did not post them here.
Thanks for looking into this!
-
just did the same :-)
-
ok, that did the trick.
Somehow when a PR was merged back from master to RELENG_2_3 it missed part of a commit that led to this happening. The safety belt patch above also helps, so I committed that as well.
I couldn't reproduce it initially because I was trying on 2.4.4 and the commit was OK there (master), but it was wrong on 2.4.3-p1.
This is the real fix:
https://github.com/pfsense/pfsense/commit/c9159949e06cc91f6931bf2326672df7cad706f4This is the safety belt:
https://github.com/pfsense/pfsense/commit/63b2c4c878655746f903565dec3f34b3d410153fYou can apply the first (or both) via the system patches package and that should get things back to normal.
-
Will try this tomorrow !
Thank you!
-
This is the real fix:
https://github.com/pfsense/pfsense/commit/c9159949e06cc91f6931bf2326672df7cad706f4This is the safety belt:
https://github.com/pfsense/pfsense/commit/63b2c4c878655746f903565dec3f34b3d410153fYou can apply the first (or both) via the system patches package and that should get things back to normal.
I've applied this as you described and my system is working again.
Thank you, and the other contributors to this thread, for fixing this so quickly.
Thanks
Tim -
Thanks! I applied the "real" fix only, rules loaded fine after that. I had to reboot the system to get CARP to work again without problems, though. Without a reboot the secondary still showed "Master" for some IPs (IPv4 and also IPv6, WAN and LAN). I could not find a pattern in this.
-
I confirm the real fix seems to does the trick. :D ;)
Thank you Jim.
-
What is the process for upgrading to 2.4.4 in the future? Will I need to revert the patch and then issue the upgrade or will I simply just upgrade to the next release as usual?
Do most people wait a while to upgrade usually? I'm kind of nervous now to do upgrades given this bug which basically broke NAT.
I will say though that I should have noticed the bug on the backup prior to upgrading the master, lessons learned.
-
What is the process for upgrading to 2.4.4 in the future? Will I need to revert the patch and then issue the upgrade or will I simply just upgrade to the next release as usual?
Do most people wait a while to upgrade usually? I'm kind of nervous now to do upgrades given this bug which basically broke NAT.
This bug was never present in 2.4.4, only 2.4.3-p1. You can upgrade as usual. The patch won't reapply itself automatically unless you went out of your way to set it that way, and since the patch won't apply on 2.4.4 anyhow it wouldn't matter if you did.
