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

johnpoz

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

The configuration on the new box I had then taken over from the old.

So you loaded the xml from the old into the new?

Tobi

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

So you loaded the xml from the old into the new?

In first part yes. Later I changed many things - because the new one has more interfaces.

johnpoz

@tobi hmmm - issue could be related to that method??

Would be good test to do a clean install, does it work.. Then restore you backup config.. But as you mentioned your not to that stage yet.

But I am not sure where to go next with this, other then clean install, and then restore of config to see if creates the problem.

Maybe @stephenw10 has some stuff to check? I am at a loss to what could cause this.. But I am not completely sure on all the things involved on how it parses out the variables in the rules for address and net.

But clearly its working as far as interfaces, or your work around of your own aliases with the cidr network in them wouldn't be working either

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