New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Bind Web GUI / SSH to specific interfaces or IPs #1347
Comments
(definitely maybe) |
+1 |
will be done on our way to 18.1, the code preparations have been done for 17.7. |
@fichtner Is this still on the roadmap for 18.1? |
It's not on the roadmap per se, but I still have this in my priority list for 18.1. |
Alright, so we're going to do this:
Thoughts? :) |
@fichtner All I've ever wanted! :D I'm absolutely OK with having no sanity checking and defaulting to a backwards-compatible config. |
Thanks, full speed ahead then. :) For recovery, I'm planning this as people will run into issues for sure. #1966 |
After thinking about this a little longer I have to ask: A reload will only be triggered for DHCP, right? It would be cumbersome if the reload would happen if a VPN tunnel (IPsec, OpenVPN) is reconfigured/reconnected. (A worst-case scenario would be flapping VPN tunnels that would cause constant reloads of the WebGUI and make configuration changes impossible.) |
During "newwanip" reload of a selected interface the service will be restarted. Since we use session CSRF and graceful SSH kill (active sessions are not touched) this should be low impact. core/src/etc/inc/plugins.inc.d/openssh.inc Lines 97 to 99 in 9e20956
|
Hi all, The general code is in place for the web GUI now after a bit of struggle with lighttpd with regard to link local IPv6 being outright rejected, ssl settings block inheritance and other idiosyncrasies. For safe use, I have been pondering how to make this robust and prevent a "lockout" scenario as discussed with @AdSchellevis. A sensible way forward would be: If the web GUI configuration is changed to include or exclude interfaces (minus the case of deleting all interfaces), a timeout of 60 seconds (feel free to say if this is enough or not or too much) will run that will reset the interface configuration if it was not confirmed in an "apply-like" fashion through the GUI. There are a few challenges here, but the system would be safe from lockouts and we could extend this approach to other critical changes like port changes, HTTP(S) toggle, certificate and cipher changes. Thoughts? :) Cheers, |
Note to self:
|
grr github |
Anti-lockout really has both SSH and web GUI as its targets, which is a bit weird here. Maybe we ought to split the options, but for now move it a bit close to SSH. A separate option makes no sense at this point. Maybe this is more of an advanced firewall option?
Reload the client side. If we can't connect back, the second part of this rework will make sure that the system reverts to its former state and this reload will be able to pick it up. While here kill the questionable login autocomplete toggle.
Tested this for SSH on 17.7.11, works perfectly! 👍 WITH SSH interface selection:
WITHOUT SSH interface selection:
|
@fraenki cool! web gui code is in place on -devel as well, only thing missing is the recovery-revert / confirm-after-save to avoid a lockout. |
I think that a timeout of 60 seconds would be too low. I have several boxes where the GUI/PHP parts are a bit sluggish. I'm pretty sure I won't be able to confirm the configuration within 60 seconds :) |
Ok, 3 minutes or 5? The new system polls and redirects when it’s back, will also later alternate between old and new link to kick back in after the global revert timeout so we catch most cases. |
I'd choose 5 minutes. Long enough to be able to issue a confirmation, short enough to not be considered a serious downtime in case of a misconfiguration. |
The initial timeout of 20 seconds is long, but it's safer to wait so that we're not bouncing back to the old web GUI before it goes down. PR: #1347
The recovery has not been implemented for the initial 18.1 as time for testing is nonexistent at this point (today is the code freeze). Instead, a warning has been put into place with 795dd8b following the suggestion of @AdSchellevis when people try to set this value. |
Seems to work.... deferring recovery. |
It would be really nice to have an option to easily configure what interfaces the web GUI and SSH processes listen on.
By default they are active on all IPs on the firewall, this potentially exposes management access to networks that people would maybe not want to, whilst we can obviously solve this with a firewall rule it strikes me as maybe being better to allow folks to specify an interface or IP that these services bind to.
Potentially this saves a lot of firewall rules too in situations with a large number of internal networks where exposing access to the GUI or SSH would not be desirable at all.
The text was updated successfully, but these errors were encountered: