Project

General

Profile

Bug #8518

Rule Error On Upgrade 2.4.3 -> 2.4.3-p1

Added by Ken Sim about 1 year ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Rules/NAT
Target version:
Start date:
05/14/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.3_1
Affected Architecture:
All

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.

8518.diff (1.37 KB) 8518.diff Jim Pingle, 05/16/2018 10:48 AM
confsnippet.txt (1.71 KB) confsnippet.txt Eric Machabert, 05/16/2018 11:17 AM
vip-gw-conf.txt (3.21 KB) vip-gw-conf.txt Ken Sim, 05/16/2018 11:28 AM

Associated revisions

Revision ff52976d (diff)
Added by Jim Pingle about 1 year ago

Do not allow an empty address/mask combination to be used in a VIP rule for outbound host traffic. Ticket #8518

Revision 63b2c4c8 (diff)
Added by Jim Pingle about 1 year ago

Do not allow an empty address/mask combination to be used in a VIP rule for outbound host traffic. Ticket #8518

Revision c9159949 (diff)
Added by Jim Pingle about 1 year ago

VIP mode is set unconditionally now, but this code was left behind on RELENG_2_4_3 and is causing errors in some cases. Fixes #8518

History

#1 Updated by Jim Pingle about 1 year 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.

#2 Updated by Jim Pingle about 1 year 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.

#3 Updated by Eric Machabert about 1 year ago

here is the same content I PM'd to you on the forum.

Thank you.

#4 Updated by Ken Sim about 1 year ago

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.

#5 Updated by Jim Pingle about 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#6 Updated by Adam Thompson about 1 year 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.

#7 Updated by Jim Pingle about 1 year ago

Only if the commits on this ticket do not solve the problem, notably c9159949

#8 Updated by Ken Sim about 1 year ago

I applied the patch and it has resolved the issue for me.

#9 Updated by Adam Thompson about 1 year 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

#10 Updated by Lorenz Schori about 1 year 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.

#11 Updated by Jim Pingle about 1 year ago

  • Status changed from Feedback to Resolved
  • Affected Architecture set to All

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.

#12 Updated by Adam Thompson 11 months 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.

#13 Updated by Jim Pingle 11 months 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.

#14 Updated by Steffen Wagner 10 months ago

the above commands fixed it for me as well. An official patch for p1 would be good!

#15 Updated by Jesse Alexander 9 months 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. :)

#16 Updated by vishant kamboj 8 months 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

#17 Updated by Ken Sim 8 months 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.

#18 Updated by Jim Pingle 8 months 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.

Also available in: Atom PDF