Scary! If HAproxy stops I get the OPNsense admin pages on the WAN

[magnust]

I have HAproxy as a reverse proxy handling all incoming https + letsencrypt certificate, transferring it to my actual webserver on the DMZ. Works great!

But I don't know if I've set a setting wrong somewhere, if I disable HAproxy temporarily all traffic coming in on my WAN interace are served the OPNsense admin pages instead. Even if it's password protected I really don't feel very comfortable with this. If HAproxy stops due to any reason, crash, misconfiguration... no, I don't feel comfortable with that.

Is there any way to prevent this? 

[fraenki]

But I don't know if I've set a setting wrong somewhere, if I disable HAproxy temporarily all traffic coming in on my WAN interace are served the OPNsense admin pages instead.

That's in fact a misconfiguration. Be aware that the OPNsense WebGUI listens on ALL interfaces by default, but the default firewall rules deny access from the WAN side.

(Note that this behaviour will be changed in the upcoming 18.1 release, see this: https://github.com/opnsense/core/issues/1347)

I assume that you have unintenionally opened the WebGUI on the WAN side... please check:

Do you have NAT port forwards configured?
If so, they presumably redirect HTTP/HTTPS traffic from your WAN IP to HAProxy.
Note that NAT port forwards automatically add firewall rules to allow traffic.

If you have HAProxy configured to listen either on port 80 or port 443 on any frontend, then it competes against the OPNsense WebGUI, because it defaults to port 80/443 too. If HAProxy is stopped, the OPNsense WebGUI will take ports 80/443 again.

*If* you rely on NAT port forwards, then this could be easily fixed by changing your HAProxy frontends to not listen on port 80/443, but instead any other (unused!) TCP port (i.e. 8443/8080). Don't forget to update your NAT port forwards to, so that they redirect traffic on the WAN IP port 80/443 to the *new* HAProxy frontend port(s).


Regards
- Frank

[magnust]

Thank you for the feedback!

I currently don't use NAT. I only have HAproxy frontend listening on 80 and 443 on WAN resending it to a backend/server on the inside.

So you recommend placing NAT in front of HAproxy? I understand that turning HAproxy off in that scenario the NAT would prevent the GUI taking over the WAN ports. Just a teeny weeny bit convoluted IMHO  Out of curiosity, is the GUI still in that case trying to listen on the WAN but now NAT is "winning" just like HAproxy is winning in my current scenario? The GUI really shouldn't bind to the WAN interface by default should it?

Again, really appreciate the help.

[fraenki]

So you recommend placing NAT in front of HAproxy? I understand that turning HAproxy off in that scenario the NAT would prevent the GUI taking over the WAN ports. Just a teeny weeny bit convoluted IMHO  Out of curiosity, is the GUI still in that case trying to listen on the WAN but now NAT is "winning" just like HAproxy is winning in my current scenario?

If you configure HAProxy to use  other ports than 80/443 *and* use NAT port forwards on your WAN interface for ports 80/443... then yes, the OPNsense WebGUI should no longer be accessible from the WAN IP. I haven't tested this, but it should be a valid workaround.

I'm not happy with this either, but it's better than exposing the WebGUI to the internet.

Another option would be to change the OPNsense WebGUI configuration to use a non-standard port instead, for example TCP port 9999. This would mean that you need to access the OPNsense WebGUI through https://opnsense:9999/ – and possibly add some firewall rules to allow it.

The GUI really shouldn't bind to the WAN interface by default should it?

I fully agree with you, but I'm not a core developer. As mentioned earlier there's work being done to change this in OPNsense 18.1: https://github.com/opnsense/core/issues/1347


Regards
- Frank

[magnust]

Another option would be to change the OPNsense WebGUI configuration to use a non-standard port instead, for example TCP port 9999. This would mean that you need to access the OPNsense WebGUI through https://opnsense:9999/ – and possibly add some firewall rules to allow it.

That is a good, less convoluted and simply much better idea! I'll do that!    Thanks!!!