Bug #8518
closed
Rule Error On Upgrade 2.4.3 -> 2.4.3-p1
100%
Description
After upgrading to 2.4.3-p1, I got a rule error that stopped some rules from loading and causing issues with the firewall.
There were error(s) loading the rules: /tmp/rules.debug:371: syntax error - The line in question reads [371]: pass out route-to ( vmx0 xx.xx.xx.xx ) from to !/ tracker 1000027964 keep state allow-opts label "let out anything from firewall host itself"; @ 2018-05-14 21:10:22
After doing some digging and help in #pfsense it showed that the ip was missing between ! and /.
The only way I was able to resolve the issue was delete both (v4/v6) default gateways and re-add them for the error to go away.
If you need anymore information, please let me know.
Files
Updated by Jim Pingle almost 6 years ago
- Assignee set to Jim Pingle
- Target version set to 2.4.4
Looks related to #8408 but I can't reproduce it here yet.
Please provide some information about your configuration, including:
- How many VIPs, what type (CARP, IP Alias, etc), and if they are IPv4 or IPv6
- How many gateways, and if they are IPv4/IPv6, and what type (static, dynamic, etc)
If you could provide the VIP and gateway sections of your config.xml that would also help, you can redact any IP addresses or identifying information.
Updated by Jim Pingle almost 6 years ago
Attached is a patch which adds a safety belt to ensure that line can't possibly be blank. But it isn't fixing the problem it's only patching a symptom so I don't want to commit it on its own yet. I need to see configuration samples to get closer to the root cause since I'm still unable to reproduce this locally.
Updated by Eric Machabert almost 6 years ago
- File confsnippet.txt confsnippet.txt added
here is the same content I PM'd to you on the forum.
Thank you.
Updated by Ken Sim almost 6 years ago
- File vip-gw-conf.txt vip-gw-conf.txt added
3 IPv4 ProxyARP VIP's
3 IPv4 IP Alias VIP's
6 IPv4 Static Gateway's
1 IPv6 Static Gateway's
When I try and add an IPv6 IP Alias VIP the error seems to appear.
I have included a snip of the requested config.
Edit: When I had done the upgrade I had 1 IPv6 IP Alias VIP's in the configuration, but during trying to troubleshoot I had removed it. The error was still present after deleting the IPv6 VIP, and that's when I deleted the 2 default gateways and the error went away.
Updated by Jim Pingle almost 6 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset c9159949e06cc91f6931bf2326672df7cad706f4.
Updated by Adam Thompson almost 6 years ago
Jim, do you still need/want (100% reproducible) test cases for this? I can send the running config from a customer experiencing this problem if desired.
Updated by Jim Pingle almost 6 years ago
Only if the commits on this ticket do not solve the problem, notably c9159949
Updated by Ken Sim almost 6 years ago
I applied the patch and it has resolved the issue for me.
Updated by Adam Thompson almost 6 years ago
Jim Pingle wrote:
Only if the commits on this ticket do not solve the problem, notably c9159949
OK. I'll keep the config file on hand for now. I'm not in a position to build from source, so I'll have to wait and see if ... umm... 2.4.3_p2 ? fixes the problem. If a patch (that can be used with System->Patches) exists, I can try that later this week or next week.
^^ saying that because 8518.diff does not seem to have a 1:1 correspondence with commit c9159949.
Thanks,
-Adam
Updated by znerol znerol almost 6 years ago
I'm affected as well. This is on a HA cluster with a couple of VIPs (mostly IPv4 and IPv6 CARPs and some IP aliases). After the upgrade we lost IPv4 connectivity (IPv6 was still working fine).
I've applied both 63b2c4c8 and c9159949 (found in master). Rules are loading now without error.
The problem I'm seeing now is that the secondary node assumed the MASTER role for all VIPs for some reason. The primary node assumed BACKUP for all VIPs.
Note: I do not see any vrrp traffic from the primary node when @tcpdump@ing - not sure whether this is expected or not though.
It might be relevant that the WAN interfaces are configured using a private IPv4 range. The public IPv4 is configured as a CARP-VIP and the IPv4 default route acts as a "non-local" gateway.
Updated by Jim Pingle almost 6 years ago
- Status changed from Feedback to Resolved
- Affected Architecture All added
- Affected Architecture deleted (
)
The CARP status issue could not be related to this, so it's not relevant. This bug only affected that one firewall rule. CARP traffic skips firewall rules, so it never would have been affected by this. Start a fresh forum thread for help with that other problem.
Updated by Adam Thompson almost 6 years ago
Still hitting this bug with no working solution in 2.4.3_p1, but it's fixed in 2.4.4.a.20180705.0739 , at least on the one firewall I just upgraded without remembering this bug.
(To be specific: applying 8518.diff through System->Patches does not fix the problem on 2.4.3_p1.)
I can live with this situation, for now - I just have to remember not to update any firewalls to 2.4.3_p1.
FWIW, so far it has affected every firewall, except one, that I've upgraded to 2.4.3_p1. (That one unaffected unit a) is an SG-2440 not a VM, and b) doesn't have a WAN IPv6 address, only a tunnel.)
Oddly, one affected firewall is still somehow both showing the syntax error and passing NAT'd traffic successfully. No idea how, and I'm not fiddling with it to find out, since there's production customer systems behind it. I can pull (read-only) info/data/diags off that box if it's helpful.
Updated by Jim Pingle almost 6 years ago
The solution is in the commits on this issue, not that diff. It has been fixed on 2.4.4, but unless we make another 2.4.3-pX release that won't affect anything on 2.4.3-p1. 2.4.4 will be released before too long, so I don't see another 2.4.3-pX release happening.
Apply commits c9159949e06cc91f6931bf2326672df7cad706f4 and 63b2c4c878655746f903565dec3f34b3d410153f using the system patches package to work around it on 2.4.3-p1.
Updated by Steffen Wagner over 5 years ago
the above commands fixed it for me as well. An official patch for p1 would be good!
Updated by Jesse Alexander over 5 years ago
Steffen Wagner wrote:
the above commands fixed it for me as well. An official patch for p1 would be good!
Can you please share with me the commands? Most of what I know, which is little at best, about pfsense is via the GUI and apparently there isn't a patch to apply.
Never mind, I found I could just put the commits into the patch URL and it found them. :)
Updated by vishant kamboj over 5 years ago
am not able to set target rules in squidguard proxy filter. once we add rule after apply then we check these rules its automatically change to default
pfsense version 2.4.4
please help
Updated by Ken Sim over 5 years ago
vishant kamboj wrote:
am not able to set target rules in squidguard proxy filter. once we add rule after apply then we check these rules its automatically change to default
pfsense version 2.4.4
please help
This issue was in 2.4.3-p1 it was resolved in 2.4.4. You have posted in the wrong place, this is for pfSense base, there is a section for packages. Please resubmit the issue under a new issue created by you if you are able re-produce the issue, you might also want to try checking out the forums to see if anyone has this issue.
Updated by Jim Pingle over 5 years ago
It looks like they are hitting #8945 -- but yes, it has nothing to do with this bug. Rather than opening a new issue, start a forum thread and someone can help you confirm if your problem is a part of a ticket that already exists.