"Enable interface" checkmark
-
What does the "Enable interface" check mark do in the interfaces.php page?
I have it unchecked on an interface with a GIF tunnel assigned to it, but the tunnel is still up and packets are routed from and to it. So what's the point of having the check mark?In general what is the difference between a pfSense interface ("LAN", "WAN", etc.) and the raw kernel interfaces (eth0, gif0, tun0, etc.)?
-
It depends on the interface. Usually that means it's disabled and wouldn't be reconfigured on boot and so on, but it also enabled things like firewall rules, daemons that have per-interface settings and so on.
GIF/GRE and similar are different beasts. The settings that bring up the GIF/GRE tunnel are on the GIF/GRE instance settings, not interfaces.php. So while adding an interface lets you setup routes, rules, and whatnot it isn't where the underlying configuration for those happen. It's independent of there, so it's no surprise that it keeps working when the interface is "disabled". In some (Admittedly rare) cases assigning the GIF/GRE isn't even necessary.
-
I since discussed this on Reddit with gonzopancho, and he agrees that this is an architectural problem that should be fixed.
We also disagreed on other stuff. ;D
-
I agree that the checkmark should have the same function regardless of the interface type, be it enabling/disabling the interface completely or just enabling filtering/NAT on the interface. Neither the GUI or the existing documentation give you any hints of different semantics of the checkmark's function depending on the type of interface now.
-
@kpa:
I agree that the checkmark should have the same function regardless of the interface type, be it enabling/disabling the interface completely or just enabling filtering/NAT on the interface. Neither the GUI or the existing documentation give you any hints of different semantics of the checkmark's function depending on the type of interface now.
On Reddit I discussed in more detail other problems of the "pfSense Interfaces" architecture, such as different meanings of "IPvX Configuration Type" depending on the corresponding FreeBSD interface and on the selected field value itself.
Right now pretty much nothing is consistent, it's a bunch of hacks to make common (and less than common to some extent) scenarios work.
I hope they will fix it soon. It is, imho, one of the worst downsides of pfSense in comparison with major commercial solutions (e.g. Cisco).