"let out anything from firewall host itself" failing? (after 2.4.3 to 2.4.3_1 upgrade)
-
I upgraded one 2.4.3 instance to 2.4.3_1.
I'm seeing this on filter reloads and I'm short on ideas of what to check for to identify the reason and fix it.
There were error(s) loading the rules: /tmp/rules.debug:164: syntax error - The line in question reads [164]: pass out route-to ( vmx0 w.x.y.z ) from to !/ tracker 1000004862 keep state allow-opts label "let out anything from firewall host itself"
In the message, the w.x.y.z IP is indeed my WAN gateway IP and vmx0 is indeed the WAN nic.
Note this specific instance is used for IPv6 only, there is merely an IP v4 on the WAN side to ease reaching it for admin.
I can indeed reach the box for admin on its IPv4 address, and I don't see any defect with the IPv6 the box must filter. It just is that the above rule error keeps popping up on every filter reload.
-
There are system patches available for this issue.
The patch commit IDs are:
63b2c4c878655746f903565dec3f34b3d410153f
c9159949e06cc91f6931bf2326672df7cad706f4
If you want to test them you can install them using the System Patches packageInstall the System Patches package in System > Package Manager, Available Packages. It will be at System > Patches when you are done.
Add a new patch
Enter a description
Enter 63b2c4c878655746f903565dec3f34b3d410153f as the Commit ID
Set the path strip count to 1
Set Base Directory to /
Check Ignore Whitespace.
SaveThat should retrieve the patch.
Then Fetch it then test it. It should say it CAN be applied cleanly and CANNOT be reverted (those test results will flip after it is applied).
Then you can apply it.
Repeat for the other patch(es).
Please let us know if that clears it up and if you see any adverse effects.You can simply revert the patches if they cause issues.
-
Thanks, I will probably have a look to these patches the next time the virtual device gets low trafic (usually on the very early hours on Sunday), in case a reboot or states dropping would be needed.
Surely I had a stable configuration with 2.4.3, dismissed the 2.4.3_1 update for some time because there was no real need to get it installed quickly, and finally had a short window of availability for updates this early morning: I installed it without understanding I might have to be ready to experiment with patches to get it right after update. :( Especially since I had no issue while updating one SG-4860 and on SG-2440 earlier in the week. I was far from expecting something different on this virtual machine.
Next time, I'll be more careful to let weeks pass by before updating. ;)
But again thanks, for the quick identification of the problem and the pointer to the appropriate patches. :)
-
@derelict said in "let out anything from firewall host itself" failing? (after 2.4.3 to 2.4.3_1 upgrade):
There are system patches available for this issue.
The patch commit IDs are:
63b2c4c878655746f903565dec3f34b3d410153f
c9159949e06cc91f6931bf2326672df7cad706f4
If you want to test them you can install them using the System Patches packageI could fetch, test, apply both these patches. After applying 63b2c4c878655746f903565dec3f34b3d410153f I could Filter Reload without any more errors. I nonetheless blindly fetched, tested and applied the second one, as you instructed. Filter Reload still functional, I'll now test a bit more all features I rely on for this instance and see if all is OK.
Question: once some patches have been installed, what to expect or what to do when an update (let's say some 2.4.3_2 or 2.4.4) will be available? Blindly let update occur, which will wipe out previously applied patches, or should I carefully first revert patches before upgrading in the future?
-
If you are installing a patch that is included in the next version (as is the case for both of these and 2.4.4) simply don't check the Auto Apply checkbox. After the update you will have the option to apply the patch again (which should not be able to be applied cleanly and fail anyway) or delete the patch.