Disable webGUI on WAN without blocking port 443 for OpenVPN



  • I'm using an OpenVPN server on WAN port 443 to get around a firewall on the client side, however, I didn't realize that OpenVPN was sharing the port with webGUI. I really don't want the webGUI to be accessible on the WAN interface. How do I disable the webGUI on WAN interface without blocking port 443 via firewall rule?



  • @fw

    You will have to remap the GUI to a different port (such as 1443). Under System -> Advanced. Change the TCP port to 1443, check the webGui redirect checkbox (disable redirect).

    This will move the GUI to port 1443. To connect to pfSense, https://xxxxxxxx:1443

    RHLinux



  • @fw

    The GUI is normally not reachable from the WAN side. Did you test from there or the LAN side?


  • LAYER 8 Global Moderator

    You can not run 2 services on the same port on the same IP anyway. So not sure how you think this would happen? if you want to run openvpn on 443, then you would need to change your gui https port.



  • @johnpoz You can actually. See here:
    https://docs.netgate.com/pfsense/en/latest/vpn/openvpn/sharing-a-port-between-openvpn-and-a-web-server.html

    Now that I think about it though, port sharing is not turned on by default, and the way that I figured out that webGUI was enabled on WAN was I had openVPN working on port 443, and then server temporarily (which was running and working correctly on port 443), at which point I noticed that port 443 was still open, even though I disabled the VPN service, and when I connected with a web browser on https, I got the webGUI.

    So I guess that means that as long as openVPN is up and running on port 443, it will probably block access to webGUI on WAN (I think). That seems very insecure way to do it though. It would be annoying to have to move webGUI to a non-standard port just because I don't have any other way to block it on WAN without blocking VPN. I don't understand why webGUI is enabled on all interfaces/IPs and there is no way to prevent that?



  • @JKnott I tested from the WAN side. I tethered my laptop through my phone with wifi disabled and was able to confirm that the webGUI came on https on WAN.



  • @fw

    Then you must have specifically enabled access via the WAN. I just tried from the WAN side and wasn't able to connect. I also did a port scan with www.grc.com and both port 80 & 443 are stealth.

    Here's some info on enabling WAN access.



  • @JKnott The only thing I did was add a firewall rule on WAN to allow TCP packets on port 443. This firewall rule is needed for VPN, but also allows access to webGUI.



  • @fw

    Did it allow access without that rule?



  • @JKnott No.



  • @fw

    Perhaps you can use port 80 for the GUI. I know that means plain HTTP, but at least it won't be exposed to the Internet. Another possibility is if the client has a fixed address, then add that address to the rule.



  • I just realized that I could probably set webGUI to listen on port 1443, and then do port forwarding from port 443 to 127.0.0.1:1443 on specific interfaces only. It looks like port forwarding is configurable per interface. I think that would do exactly what I want.



  • This post is deleted!

  • LAYER 8 Global Moderator

    Yeah lets go over this yet again... it is not possible to listen on the same port on the same IP at the same time... How exactly would that work??

    Sure you can port share, I do that myself actually but sure and the F not for the gui, but for a haproxy that sends traffic to the backend for other stuff. And a port share is still not services listening on the same port on the same IP at the same time.

    I would highly suggest if you want to use 443 for anything, be it openvpn, haproxy, port forward that you change your webui to use something else 8443 is typical for https to run on when you don't want to run on 443.

    If you try and run 2 different services on the same IP on the same port - you create a race condition, there can be only one.. And depending on who wins the race you would have that one, or quite possible you could end up with nothing.. You do not want race conditions.

    Configure your webgui port to be listen on something else!

    One reason I could think of not setting what interface webgui would listen on vs all of them - is promise you users would F it up!!! And we would be bombed with can not get to my web gui threads ;) hehehe



  • @johnpoz

    I think the idea is he doesn't want to access the GUI via the WAN port, but creating the rule to allow the VPN on port 443 opens access to the GUI too. Other than moving the GUI to a different port number, as he mentioned, I don't see any way to block access to it.


  • LAYER 8 Global Moderator

    If you have a service listen on port X on your wan IP... And then you allow access to that port - then yeah no freaking shit you be able to access it - DUH!!!

    But here is the thing - you can not run 2 services on 443 on 1 IP... So there is never a scenario where this would be an issue! Ever!!

    Change your freaking port of gui if your going to run something else on 443 - its that freaking simple!

    If I set up a race condition by setting 2 services to use the same port, and then I get lucky and the one I am trying to use works at the time... And then I turn off that service and the other service works - yeah no shit you can access it if the port is open.

    The root of the problem is you think its ok to try and run more than one service on the same IP on the same port - which is borked!!! It not going to work how you think its going to work.. You can not do it!!



  • @fw said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    I just realized that I could probably set webGUI to listen on port 1443, and then do port forwarding from port 443 to 127.0.0.1:1443 on specific interfaces only.

    Or perhaps forward 443 from the WAN interface to 1195.



  • @johnpoz Why should I have to change the webGUI port on my LAN interface just bc there is some other service running on that port on an unrelated interface (WAN)? That's pretty stupid that pfsense webGUI works like that.



  • @fw

    The problem is that all traffic that enters the box passes through 0.0.0.0 and then gets sorted according to address. As far as I know, there is no way to limit what interface something comes from, other than the firewall rules, which aren't up to this task. As I mentioned, you can try forwarding WAN port 443 to 1195, instead of changing the port the GUI uses. Perhaps the solution is for pfSense to support the concept of a management interface, which has nothing to do with passing traffic.



  • @johnpoz said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    If you try and run 2 different services on the same IP on the same port - you create a race condition, there can be only one.. And depending on who wins the race you would have that one, or quite possible you could end up with nothing.. You do not want race conditions.

    I'm not trying to run 2 different services on the same IP on the same port. I'm trying to run 2 different services on different IPs on the same port (i.e. one on LAN IP and one on WAN IP). I don't understand why pfsense doesn't allow that.


  • LAYER 8 Global Moderator

    @fw said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    I don't understand why pfsense doesn't allow that.

    Because there is not currently a way to just bind the webgui to the lan IP... It has been asked about for YEARS! Here is a thread from last year
    https://forum.netgate.com/post/826148

    So since you can not do that - change the port! Its that that simple if you want to run something else on 443.



  • I got the port forwarding working, but the setup was a little different than I expected. I set the webGUI port to 1443. I thought that if I wanted to access the webGUI on port 443 on the LAN IP while connected on my VPN, I would setup a NAT to forward port 443 to 1443 on the LAN interface. However, that doesn't work. What I had to do instead, was forward 443 to 1443 on the openVPN interface instead of the LAN interface, even though I'm actually accessing the LAN IP, not the VPN IP. I guess that sort of makes sense. Just confused me a little. I guess I'll have to add separate port forwards for each interface that I want to use to access the webGUI from.



  • @fw said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    I guess I'll have to add separate port forwards for each interface that I want to use to access the webGUI from.

    Why not forward the VPN, on 443, to 1195 instead? That would definitely go on the WAN interface and you wouldn't have to worry about anything on the WAN side.



  • @JKnott said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    Why not forward the VPN, on 443, to 1195 instead? That would definitely go on the WAN interface and you wouldn't have to worry about anything on the WAN side.

    That's true. I might try that. One advantage to doing it the other way though is that I'm less likely to mess it up in the future. It's highly unlikely that I would accidentally allow 1443 on WAN firewall rules, whereas I could see myself messing with the port forwarding and accidentally disabling that particular port forward. Disabling the port forward if it was on WAN would expose webGUI to WAN, whereas disabling a port forward on LAN would be safe.


  • LAYER 8 Global Moderator

    What I do is have 8443 as my webgui, I do have vpn on 443 because I use it every day from work (have to go through a proxy at work that only allows 443).. I then have share port setup, and forward specific fqdn to port on haproxy that gets sent to backend.

    Works perfectly.. No issues accessing vpn, nor website...

    port-share 127.0.0.1 9443
    

    Then HA proxy listens on that port, and sends to backend.. Its even doing the ssl offload because the backend system doesn't really support ssl (requests for my plex users running ombi)



  • @fw

    Its because you added a firewall rule on the WAN interface to listen on 443 and go to destination firewall(self). This is typical because openVPN runs as a service on the firewall as does the GUI... hence the firewall(self) part is a common point.

    Since firewall(self) also runs the GUI on port 443 you will have the issue you describe.

    I suggest that you do port forwarding.... leave OpenVPN on 1194 and forward from the WAN to firewall(self) port 1194. This would be the easiest and you can still keep the GUI on 443. This would also allow you to run OpenVPN on other ports also... for example you can port forward from the WAN 443 and 1194 or any other port to OpenVPN on 1194.

    RHLinux


  • LAYER 8 Global Moderator

    @RHLinux said in Disable webGUI on WAN without blocking port 443 for OpenVPN:

    leave OpenVPN on 1194 and forward from the WAN to firewall(self) port 1194.

    You would have to make sure that openvpn is using tcp on this port..

    Just change the gui port, it takes all of a couple of seconds to do, its a 1 time thing.



  • @johnpoz

    Well I assumed he was using TCP due to the fact that he was using 443 and getting the web GUI. It is just a switch of the OpenVPN from UDP to TCP which he has already done...

    RHLinux


  • LAYER 8 Global Moderator

    Default port is 1194 and UDP.. While I agree he is using tcp, when you call out forwarding to 1194 - best to make sure you mention that in this scenario it will need to be TCP and not the default UDP port is all I was wanting to point out ;)


Log in to reply