Interface names

luckman212

I'd like to know the reason for the 3 apparent "layers" of interface naming on pfSense. Did some searching and only came up with a 5 year old thread and this documentation page which says "For historical and ease-of-use purposes"

Let's look:

lowest level - the "physical" if you will or at least logical interface names. OS-level e.g. igb1, re0, ix3 etc
next layer up - the pfSense-y name e.g. wan, lan, opt2 - used inconsistently throughout the GUI as well as internal code
the "friendly name" e.g. "WAN3-10M-FIBER" etc (whatever you put in the description field)

… now, #3 is optional and not used programmatically anywhere, so we can forget about it
... and #1 obviously can't be removed as it sits at the bottom of the stack

That leaves #2 -- why do we need this? I know there is probably a very good or obvious reason for this. The only thing I can think of really is backup/restore to dissimilar hardware - where you want to reassign the interfaces and they don't have 1=1 matches e.g. on the old system it was igb2 but on the new system it's re2 so you would use instead the "opt2" nomenclature to preserve configs. Is that correct?

phil.davis

That's about right. If rules, port forwards, VPN end points and so on just mention "wan" "lan" opt1"… and "wan" keeps a record of the OS device that it is mapped to, then when that OS device mapping changes (interface assign) there is just 1 place to make the change in the config.

The "interface description" is a bit more of a half-way house. That string gets used both for UI display and is put into the pf rule set (which helps the rule set to be readable/understandable when the firewall admin needs/wants to look in it). Because of that, there are restrictions on the char-set/format/length of the description. With some thought there could easily be a UI "free text" description and a rule set interface "name". But then I guess people who look in the rule set have to understand that name mapping also.

jimp

The separation is the easiest way to allow custom names and changing interface mappings. Keeping the configuration largely abstracted from the OS-level interfaces is a huge gain when having to deal with interface selection in various parts of the GUI.

Imagine having to track down every reference to every name everywhere (base system pages, packages, etc) and update it when someone reassigns an interface. The same problem would happen if it was only tracked by a custom name entered by the user.

So, to summarize:

OS interfaces are mapped to logical interfaces to keep the configuration abstracted, so dealing with hardware or other interface mapping changes is typically trivial
Logical interfaces can be given "friendly" names to make them easily identifiable to users.

luckman212

Thank you both for the helpful replies. Might not be a bad idea to add a note about that to the Developer Style Guide (e.g. Whenever possible, the preferred way to reference interfaces is by using the logical interfaces name eg opt2 yada yada…)