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

[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.