management IP feature request (628)

[metebalci]

Is there enough interest in this feature (https://redmine.pfsense.org/issues/628) ? It looks simple enough to implement it (maybe with an all or one interface selection). I wonder if I should try to create a pull request.

Mete

[johnpoz]

@metebalci said in management IP feature request (628):

https://redmine.pfsense.org/issues/628

My "guess" would be reason they just listen on all is trying the help users from shooting themselves in the foot and locking themselves out..

Out of the box the only interface these ports would be actually available on would be lan.. Or wan if you only had a wan interface and no other interfaces.

While it might be a nice feature to set a specific IP.. It just makes it more likely for users to shoot themselves.. For what amounts to very little security increase.. With much more coding required to put in place to only listen on specific interfaces.. And then you prob have users complaining why they can't hit the gui on their new vlan IP, etc..

[metebalci]

@johnpoz totally agree with the problem of being locked out. I think I can also rephrase my question as how many people has a similar setup to mine. I have out of band console access to the computer running pfsense so I cannot lock myself out. I also have multiple LAN interfaces. So basically what I want is that the admin gui/ssh listens on a particular LAN interface, as I do the same for all other equipment. If I am not wrong, by default it listens on all, including WAN, interfaces, since nginx and ssh configs are empty for the IP addresses. Yes the default rule does not allow it, or you will create rules anyway but still I find it strange that by default it listens on every interface for management access.

[johnpoz]

@metebalci said in management IP feature request (628):

by default it listens on every interface for management access.

Again my "guess" thinking about the vast userbase of pfsense, and the very large amount of new users with very little understanding to even basic networking to be honest, coming from their plug it in and it works soho routers.

Just look at the vast amount of users that ask about new vlans, and don't have any rules created on them for why they don't work.. If they also had to change something to tell the gui to actually listen on that interface, etc. And create a rule, etc. I can almost promise you it would generate more questions. Then the few users wondering why it listens on all ;)

I look at it as simple coding, with large benefit to most users, and little if any loss of security since even if it listens on wan or any other interfaces you create - its not actually allowed until the user creates.

Another example of keeping users from shooting themselves in the foot is when you enable dhcpd for example hidden rules are created to allow dhcp on the interfaces you enable it on.

So keep mind that not all coding of such an application is always about pure functionality from a specific point of view - but a way to allow for the most users to be able to use it in such a manner with small footprint of shooting themselves in the foot and then complaining this doesn't work or that doesn't work because they didn't fully read the docs, etc..

Your more than welcome to submit a change and request a PR to have your changes implemented if you feel you have a better way to do it, while also preventing the users from complaining about xyz not working, and allowing granular control like your requesting..

[metebalci]

@johnpoz great summary thanks. I will think about it.

[JeGr]

@johnpoz Also I might be mistaken but for a "real" OOB management interface that interface would have to be excluded from the UI and normal routing table so it won't cause asymmetrical routing loops. E.g. if I define igb0 to management only and attach the UI to it only, then that interface (and it's IP and routing table) would have to be separate from the rest of the system so any changes in routing, IP config etc. wouldn't hinder my access to the UI/mgmt port. Sou you'd need a second routing table (not that exotic but definetly something not currently in pfSense) that is mapped specifically to that interface and handles traffic arriving via that interface in another way then any other traffic routing through the system.

That would be quite a change. Of course, you could "open up" configuration of Nginx and SSH to only respond to configurable interfaces (like your LAN, Mgmt VLAN etc.) and you could limit the exposure of those services quite a bit but to be a real management interface like in L2/L3 switches, the interface in question would IMHO have to be excluded from the normal routing engine/table.

Cheers

[metebalci]

@jegr that makes sense but what I was thinking was a simple solution. Actually I am not sure if the L2/L3 devices I saw had something you describe (but I did not see many devices and definitely not high-end ones). What I am using, I have in mind, and I think what works for small networks is that a management workstation is already on the same management LAN (or you can connect a laptop etc. to that LAN), where devices respond. So as long as the L2 network and the (management) interface(s) are UP, it should work.

Yes, it is not very difficult to limit nginx and ssh to specific interfaces/IPs I already tried that (6-7 lines in two files) and other than an issue with IPv6 IP for SSH, it was working fine. Then I upgraded to latest pfSense, I didnt check yet what happened to my changes afterwards.

[mr.rosh]

perhaps an option would be to enable one of the nic/ports as console port. Not sure if this will be feasible and or practically possible. [as some devices do not have vga/console rj45 port], by default.