Upgrade 2.4.3 to 2.4.3_1 error in firewall rules
-
Forgot to mention that I also removed/commented out the line and loaded the ruleset by hand. CARP was still broken afterwards, as some of the IPs on the secondary showed to master and the primary also thought it was master.
Too bad we are not able to just revert to the older pfSense version like we could with previous releases. -
These show stopping bugs are happening all too often.
Out of the 20 or so pfSense boxes every other update will brick at lease one or more.
pfSense need to bring back the way to revert to the previous release.
-
This bug also affects me. Strangely, if I activate the backup router by putting the primary into persistent maintenance mode, NAT and all other router services work fine through the backup.
-
After a little digging around on github, it looks like there were changes in src/etc/inc/interfaces.inc recently. I can't be sure, but it looks like what is essentially an empty string is getting validated as an IPv4 network address.
Here's the diff: https://github.com/pfsense/pfsense/compare/master…RELENG_2_4_3
-
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
