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

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.

stephenw10

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

I have changed the names now. To opt0-opt9. It works this part also with the rules.

Hmm, interesting. So that is now creating the correct rules? Because the default names would be opt1-opt10. There is no opt0 by default.

The IPv6 IPs on each subnet should work as long as the PD has been pulled on WAN when the ruleset is built. You still see 'no source address' in the v6 rules?

Steve

Tobi

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

o that is now creating the correct rules?

Yes. I changed all rules to lanX Network and all is fine.

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

You still see 'no source address' in the v6 rules?

No, this part works now perfect. I think the rules will work even after a change of IPv6 prefix.

What doesn't work/can't work is that the prefix is automatically changed for single ip addresses (DNS/ NTP as example).
I had considered moving my DNS (running on Linux host) to pfSense before but there seems to be no way (at least I didn't find anything) to migrate the existing bind9 configuration with zones to pfsense.

johnpoz

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

e.g. DNS automatically

So you want to change what exactly for dns.. You got some device on your network via IPv6, and it gets its whatever IP address via ISP delegating some prefix to you, you then track this and setup say index 0 prefix of this delegated /56 to your lan..

Now you got some that gets an IP out of that /64 prefix - and you want to register this IP in some public dns?

What are you going to serve up from this box, doesn't seem like a good idea even if you could dynamically update its IP that could change at any time..

Tobi

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

Now you got some that gets an IP out of that /64 prefix - and you want to register this IP in some public dns?
What are you going to serve up from this box, doesn't seem like a good idea even if you could dynamically update its IP that could change at any time..

Sorry - my bad english :)

I will register this IP's in my own local running DNS.. This work but only If I change pfSense config after prefix has changed.
The only thing I allow from outside is openvpn to my pfsense nothing else.

johnpoz

@tobi to be honest client registering its IP should be on the client to do that.. And if you were doing that, unbound prob not the correct choice because its not really meant to be an authoritative NS..

SteveITS

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

migrate the existing bind9 configuration with zones to pfsense

There is a BIND package for pfSense. I have never used it.