pfSense not propagating "system aliases" (lanX net/ lanX address)

Tobi

@johnpoz Thank you.
Do you have any idea where/how I can get the diag info that @stephenw10 is asking for?

johnpoz

@tobi not sure what he is asking for.. Sure he will chime in on specifics soon enough.. Just give him some time - it is the weekend ;)

SteveITS

@tobi I think he means
https://docs.netgate.com/pfsense/en/latest/recipes/diagnostic-data.html

johnpoz

@steveits yup - that would most likely be it for sure..

Tobi

@steveits said in pfSense not propagating "system aliases" (lanX net/ lanX address):

I think he means

Yes it makes sense. However, I will wait for his answer, because in the whole diag I think there is too much data that does not belong in a public forum.
Maybe he mean "only" the Firewall-*.txt files

johnpoz

@tobi you can for sure that file just to @stephenw10

stephenw10

Yes, exactly that. If you can gather the status output file from that page you can upload it to me here: https://nc.netgate.com/nextcloud/s/bTgFR9wa8MAcGij

Steve

Tobi

@stephenw10 Thank you Steve, I have uploaded the file.
I am already excited whether you can find something there.

In the FW rules there is 1 with the error - search for "Windows 138". Lan0 Interface

stephenw10

Hmm, did you manually edit the config before importing it at some point?

The internal interface names are not the expected defaults. Just wondering if something is internally still referencing the default names since wan is the only interface that would match.

Steve

johnpoz

@stephenw10 said in pfSense not propagating "system aliases" (lanX net/ lanX address):

did you manually edit the config before importing it at some point?

I think he did, because look few posts back he imported that config from a different machine that had less interfaces.

Tobi

@stephenw10 said in pfSense not propagating "system aliases" (lanX net/ lanX address):

Hmm, did you manually edit the config before importing it at some point?

Yes. The old box had only 2 physical interfaces. The new one i mean 8. So I edited some names and changed the relation "LAN0 - igb1" or so. With the old box I had also adapted the names

stephenw10

Mmm, and that shouldn't matter. However that does seem to be the issue. I just replicated it here in 22.01:

# source address is empty.  label "USER_RULE: Test"

		<lan1>
			<descr><![CDATA[lan1]]></descr>
			<if>vtnet2</if>
			<enable></enable>
			<spoofmac></spoofmac>
			<ipaddr>192.168.2.10</ipaddr>
			<subnet>24</subnet>
		</lan1>

		<rule>
			<id></id>
			<tracker>1658609912</tracker>
			<type>pass</type>
			<interface>lan1</interface>
			<ipprotocol>inet</ipprotocol>
			<tag></tag>
			<tagged></tagged>
			<max></max>
			<max-src-nodes></max-src-nodes>
			<max-src-conn></max-src-conn>
			<max-src-states></max-src-states>
			<statetimeout></statetimeout>
			<statetype><![CDATA[keep state]]></statetype>
			<os></os>
			<protocol>tcp</protocol>
			<source>
				<network>lan1</network>
			</source>
			<destination>
				<any></any>
			</destination>
			<descr><![CDATA[Test]]></descr>
		</rule>

That rule works fine if the interface is using the default (expected) internal name, opt1.

The interesting thing is that the 'lan1' subnet is still pulled in correctly for other things such as auto outbound NAT rules.

stephenw10

Mmm, this is interesting. I've never seen anyone hit that before but I would consider editing the internal interface names like invalid. At least currently.
I'll open a bug for it just to note the behaviour. There is no change in 22.05. It may well be marked 'not a bug' though.

https://redmine.pfsense.org/issues/13376

Steve

Patch

@stephenw10 said in pfSense not propagating "system aliases" (lanX net/ lanX address):

That rule works fine if the interface is using the default (expected) internal name, opt1

I thought internally only standard names like wan, Lan, opt1, opt2 etc were used despite the ability to change the displayed name.

As such likely solution options would be:

Edit the configuration to only use standard names
Reset to default and enter the configuration manually via the GUI (which will force standard naming.
A combination of 1 & 2 such as starting 2. then using that as a reference to do 1.

Tobi

@stephenw10 Steve, thanks for your analysis. I am now not quite sure if I have understood everything correctly. Do you suggest that I try to make lan0 an opt0, lan9 an opt?
What also confuses me - in this post the @johnpoz shows that it has changed the names as well (at least I think so) and there it works (@johnpoz said in Is it possible to change an alias dynamically?:

example here is my lan rule
(Or did you only change the description?)

And sorry fot the stupid question - what are the default names? opt1...optX ?

johnpoz

@tobi I changed the description of the interfaces, not the actual interface name.

All done via gui, no manual editing, etc.

Did you actually change in the config file, yeah that could cause some issues.. Good catch Steve.

Tobi

I am still waiting to see if it is accepted as a BUG. If not I can still change the names back

stephenw10

I would change them back anyway since although it looks like everything else is working there may well be other things that are broken by that change. It will not have been tested. Perhaps ever!

Steve

stephenw10

@patch said in pfSense not propagating "system aliases" (lanX net/ lanX address):

I thought internally only standard names like wan, Lan, opt1, opt2 etc were used despite the ability to change the displayed name.

They are. Unless you manually change them by editing the config.

Tobi

I have changed the names now. To opt0-opt9. It works this part also with the rules.
Unfortunately it doesn't help me, because if the IPv6 prefix changes I have to adjust the configuration manually every time. There seems to be no possibility to change the IP addresses of e.g. DNS automatically. My DNS does not run on pfSense
I found an old feature request , nothing seems to happen.