Add a new network interface leads to pfsense rearrange all network interfaces
-
Hi,
I have found that when you add a new network interface this leads pfsense to rearranged all network interfaces.
Is there a way to fix / stuck / map the current configuration of the network interfaces and when adding a new one, pfsense not rearranging current mapping? -
I'm guessing you're running in VMware ESX and added NICs to the VM? That's a VMware problem, it's the host that changes the order they're presented to the guest in that case, nothing the guest can do about that.
-
Is it really unreasonable to ask that pfSense look at a MAC address to determine which interface is which? If the MAC assigned to a NIC changes… well it might be just a hardware change, but if two MACs switch places, it's probably a safe bet that the user would prefer that the NICs remain on their old networks with their old configurations. Or at least pop up a warning after a change is detected so that the user knows to go verify what has changed and how.
There's ALWAYS something that can be done. "Not my problem" is kind of a cop-out. Might not be your fault, but software can fix an awful lot of hardware oddities, and this is one case where it could. -
We've discussed it at length before. There are many potential complications in making assumptions like that, some of them with an end result of breaking things that are fine now. There are also scenarios like MAC spoofing where you can't obtain the NIC's hardware MAC from the OS. It's something we may consider changing in the future, it's just something that poses a lot of potential risk to address one edge case problem in VMware.
-
I would say that the problem is deeper than that.
The root cause (in my eyes) is the binding to an interface instead of just using IP ranges as base for all routing/FW/whatever ;)
The benefits of using ip ranges is that you become independent of things like nic ordering. As long as the nic has the same IP it will work
-
There are no IPs assigned to any NIC until your config does so. It's impossible to identify NICs by IPs, because they can't have IPs until after they're identified.
-
@cmb:
There are no IPs assigned to any NIC until your config does so. It's impossible to identify NICs by IPs, because they can't have IPs until after they're identified.
Thanks for making my point. If you work on IP level you don't need to identify the nic at all in the firewall. All you need to care about are Ip nets.
Therefore the firewall and FW config becomes independent of changes at os level
Now if the interface order changes and the OS fails to assign the right IP to the right IF you change that with IFconfig.
You won't have to touch a single line of FW config, eliminating the risk for severe misstakes -
@cmb:
There are no IPs assigned to any NIC until your config does so. It's impossible to identify NICs by IPs, because they can't have IPs until after they're identified.
Thanks for making my point. If you work on IP level you don't need to identify the nic at all in the firewall. All you need to care about are Ip nets.
Therefore the firewall and FW config becomes independent of changes at os level
Now if the interface order changes and the OS fails to assign the right IP to the right IF you change that with IFconfig.
You won't have to touch a single line of FW config, eliminating the risk for severe misstakesI'm not making your point, I'm pointing out that what you're describing is completely impossible. The IPs can't be configured until your interfaces are assigned, so it's not possible to do any interface assignment by IP. All of the configuration of IPs, firewall, NAT, and everything else in the system is by interface identifier - wan/lan/optX - not to any physical/virtual NIC.
I think what you're getting at is how things are already done and have always been done. There is no assignment of any firewall or service config to the underlying physical/virtual NIC, only to its assignment (wan/lan/optX). What we're talking about here is how you associate a physical/virtual NIC (igb0 or what have you) to its assignment (wan/lan/optX).
-
I think we need a beer and a whiteboard to sort that one out :)
It works (it's how the TMG works internally for example)unfortunally the firewall rules today are hardcoded on the interface names, not the virtual names as i see it.
If I do pfctl i dont se opt, I dont se wan. I see hn1, hn2 and hn3, IE the true physical names.
Thats one thing I would like to change so that virtual names was used instead.
Instead of having to regenerate X number of lines of rules an interface change only needs to change the aliases. -
The ruleset is generated from config.xml, where the rules are strictly associated with wan/lan/opt. The back end writes out the ruleset automatically replacing wan/lan with hn0/hn1/etc. based on what your assignment is. Other than WAN -> hn0, LAN->hn1, etc. there is no mention of hnX in the config.