Bug #10142
closed
Using LAN interface for WAN leads to weird behaviors
0%
Description
According to the official docs, pfSense has kept the first and the second interface named WAN and LAN respectively, for history (legacy?) reasons.
When we have a multi-wan setup and eventually one of the WAN gateways is assigned to the "LAN" interface, it leads to some weird behaviors, such as:
- DHCP leases page listing the "LAN" as an interface that has DHCP leases, when it does NOT
!Screenshot from 2019-12-31 16-15-22.png!
- System DNS name being resolved as the external IP address, instead of as the internal one
!Screenshot from 2019-12-31 16-35-29.jpg!
- Maybe others that I haven't noticed yet
More specifically, as far as the DNS resolver goes, this is the code that it uses to create the $hostname.$domain DNS entry as well as the /etc/hosts entry. You can see that it will look for an interface named "LAN" and regardless of whether it has a gateway assigned to it, it will be assigned to DNS named $hostname.$domain
IMHO, the interfaces should not be named as such, and ideally, no logic should be dependent on the interface names, because it's not semantic - as one could just attach a gateway to a LAN interface, for instance.
I understand, however, that this is deeply embedded into pfSense's code, as seen here and therefore a change on this area would be more difficult, and probably a breaking one for most users.
A solution that could work and it's probably a compromise between current state and my suggestion would be the ability to rename the interfaces, so that we could move the "LAN" interface to something that it's actually serving as a LAN.
I apologize if this is not the right place for this kind of discussions, but if not I will be grateful if you could point me towards the right direction.
Thanks!
Files
Updated by Jim Pingle almost 5 years ago
- Status changed from New to Rejected
- Target version deleted (
2.4.5) - Affected Version changed from 2.4.5 to All
The leases bit is likely not a bug, there may actually be a lease in the lease database that matches the stated config, even if it was before that interface was repurposed. There is likely still some remnant of that config present in config.xml with the pool addresses as well. It's just showing you what it knows about.
The DNS issue could probably be handled better, and it should be opened as its own issue for the DNS Resolver, but really all it can do is guess there. Even if it just took the first interface without a gateway it could still easily be a wrong guess. You can add your own host overrides if you prefer, since the automatic ones do not work as you expect.
There are certainly more underlying issues here than just that one, but lumping them all together isn't the way to go. They need to be individually identified and treated separately since they are likely of varying levels of complexity in how they must be addressed. And it's too late for 2.4.5 to go digging for things like this.