error(s) loading the rules after upgrade to 2.4.4-1

[pranav]

After upgrading my pfSense to 2.4.4-1, i got panic as all my LAN traffic was blocked and notification reads following.

There were error(s) loading the rules: /tmp/rules.debug:46: syntax error - The line in question reads [46]: scrub on $LAN all fragment reassemble
@ 2018-12-23 03:12:11

I went to alias and removed alias named LAN for 192.168.10.0/32. Although I had plan to use it in my firewall rule, this is something I had not used in definition of any rules. That got me up and running. After that I re-added it and it was still working.

I have no idea why a simple upgrade would cause so much problem.

Now I realized that my rule for plex stopped working.
Can someone advice on what can I upload to get assistance?

[Konstanti]

@pranav Hey
Show the output of the command
grep LAN /tmp/rules.debug
from the cli

[pranav]

Thank you @konstanti for guiding me.

Here is output of command.

LAN = "{ em0 }"
table <LAN> {   192.168.10.0/32 }
LAN = "<LAN>"
scrub on $LAN all    fragment reassemble
antispoof log for $LAN tracker 1000002620
# allow access to DHCP server on LAN
pass in  quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 tracker 1000002641 label "allow access to DHCP server"
pass in  quick on $LAN proto udp from any port = 68 to 192.168.10.1 port = 67 tracker 1000002642 label "allow access to DHCP server"
pass out  quick on $LAN proto udp from 192.168.10.1 port = 67 to any port = 68 tracker 1000002643 label "allow access to DHCP server"
# allow access to DHCPv6 server on LAN
pass  quick on $LAN inet6 proto udp from fe80::/10 to fe80::/10 port = 546 tracker 1000002651 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 546 tracker 1000002652 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from fe80::/10 to ff02::/16 port = 547 tracker 1000002653 label "allow access to DHCPv6 server"
pass  quick on $LAN inet6 proto udp from ff02::/16 to fe80::/10 port = 547 tracker 1000002654 label "allow access to DHCPv6 server"
pass  in  quick  on $LAN inet proto tcp  from any to any tracker 1542612729 flags S/SA keep state  label "USER_RULE"
pass  in  quick  on $LAN inet from 192.168.10.0/24 to any tracker 0100000101 keep state  label "USER_RULE: Default allow LAN IPv4 to any rule"
# at the break! label "USER_RULE: Default allow LAN IPv6 to any rule"

I did cat /tmp/rules.debug and learn that LAN is name of interface em0.
When I am using same name as alias for network 192.168.10.0/32 , I am essentially confusing firewall.

I realized my mistake and removed alias to correct issue.

once again, thank you for your reply as it put me on right path.

[johnpoz]

@pranav said in error(s) loading the rules after upgrade to 2.4.4-1:

LAN for 192.168.10.0/32

In what sense would you be using that alias.. Its host specific mask /32 its not a network...

Its a REALLY odd host address .0 You would have be using something bigger than /24 to be able to get a .0 as host address. So from your output looks like your using 192.168.10.0/24 so .0 would not be an actual host address you would use. And pfsense already has a built in LAN Net alias that would cover all of that /24 -- so your .0/32 doesn't make a lot of sense. Did you mean it to be a /24 in your alias - there is already a built in one so not sure why you would need to create one?

[pranav]

Here are my 3 interface.

WAN 1000baseT <full-duplex> MyPublicIP
LAN 1000baseT <full-duplex> 192.168.10.1
OPT1 1000baseT <full-duplex> 192.168.50.1

Like everyone else, I had created simple setup initially and configured only two interface i.e. WAN and LAN.

Later to create rules I created network alias (not host alias) named "LAN" for 192.168.10.0/32 network which caused above syntax error. I intend to use /24 but sytem automatically had filled in /32 as I typed above address. It was also an overlook on my part at that time.

When I executed "cat /tmp/rules.debug" and noticed following entry.

#System aliases

loopback = "{ lo0 }"
WAN = "{ em1 }"
LAN = "{ em0 }"
OPT1 = "{ em2 }"
OpenVPN = "{ openvpn }"

Learning from this incident: I learn that name given to interface becomes system alias . Hence it should not be used while creating "User Aliases".

[jimp]

It shouldn't have let you make an alias named LAN, since it conflicts with the interface name.

Was that an alias you made a while ago? Or something recent?

[johnpoz]

Yeah it doesn't let you do that

[pranav]

It still allows use of system name LAN as user alias. (See screenshot below)

[jimp]

If you rename that alias to something else, does it let you make a new alias named LAN? Or save changes to it?

Also it may be that your interface internally named lan is not using LAN as its descriptive name, but in that case it wouldn't normally conflict.

[pranav]

@jimp ,

Actualy it's LAN in upper case at both places and system absolutely takes it.
To prove it, here is output screenshot of /tmp/rules.debug where you can see "LAN" is listed in system aliases with value "{ em0 }" and under user alias also we have it listed there.

You are right about expected behavior that it should not allow me. However, in reality UI does allow me to create user alias of same name used for system alias (interface name).

[jimp]

I'm trying to figure out how it was allowed, however. I can't reproduce it here. It kicks back the alias and won't let me save it when it has that name.

So for me, I cannot:

• Create a new alias using the same name as an existing interface
• Rename an alias to the same name as an existing interface
• Rename an interface to the same name as an existing alias

I even tried using a mix of upper/lowercase to see if it would sneak by, but it was always caught and rejected.

[pranav]

Here is my version/build info.

2.4.4-RELEASE-p1 (amd64)
built on Mon Nov 26 11:40:26 EST 2018
FreeBSD 11.2-RELEASE-p4
The system is on the latest version.
Version information updated at Thu Dec 27 15:43:31 UTC 2018

Given this is VM on ESX, I can export it and send it to you. Let me know if that helps you better understand how this could be occurring.

[jimp]

Seeing it that state won't help as it won't explain how you managed to get it into that state, when all signs point to the input validation correctly rejecting what you are attempting when anyone else does it.

Remove the alias and try to add it back again, see if you receive an error or if it still lets you create it.

[pranav]

I removed alias to resolve following error.

"There were error(s) loading the rules: /tmp/rules.debug:45: syntax error - The line in question reads [45]: scrub on $LAN all fragment reassemble"

when you expressed that I should get error from input validation, i tried to add it back like you said and i was able to add it successfully and re-produce error.

In short, input validation you are referring to is not functioning as expected.

I am able to remove and re-add it successfully.

[jimp]

What does the config.xml section for your LAN interface look like?

[pranav]

@jimp

GUI shows all interface name in upper case including "LAN".

whereas, config.xml reads all name in lower case. This is another issue with GUI.

So, I tried to create another alias named "lan" in lower case and I got input validation error such as "Cannot use a reserved keyword as an alias name: lan"

So, answer to earlier question, how I got to this point is.

Any interface name given in upper case is shown as it is. However, due to bug interface names are stored in lower case in config.xml

This highlights fact that GUI is reading config info from some intermediate place other then config.xml.

Due to this when i upgraded from version 2.4.4 to 2.4.4-RELEASE-1, it absorbed everything from old config.xml including buggy GUI that kept showing uppercase interface name and errored config.xml which could not load all previously configured rules.

By removing user alias "LAN" I could address loading of all rules.

GUI is not reading from config.xml is still an issue and requires detail investigation and attention of expert such as yourself.

[jimp]

Seeing the GUI doesn't tell much, though, I need to see the exact block of config.xml for the <lan>...</lan> interface or at least the <descr> value, but preferably the whole block. You can mask/remove the IP address if you need to.

Looking at the alias page and interfaces page it already does a case insensitive match on the description vs alias name, however. I see one place that doesn't, where it checks for the reserved words, but even with that I still can't make it happen. I set the LAN interface to a description of lan and I still can't make an alias named lan or LAN.

[pranav]

Attached here are two blocks.

1. interfaces block from config.xml
2. aliases block from config.xml

1_1545944429878_interfaces_block_from_config.xml 0_1545944429878_aliases_block_from_config.xml

[jimp]

Your LAN interface has no <descr> tag which would explain why it is not checking it as expected. So it probably is that reserved keyword part that isn't matching as expected.

If you edit and save your LAN interface it should populate that tag and then it would kick that back.

I'll try to reproduce it here that way.

[jimp]

Yep, that did it. Issue here: https://redmine.pfsense.org/issues/9231

Fix pushed, will show up on Redmine shortly.