Cannot Connect to the Web Gui Externally



  • Hello,

    I'm using OpenVPN to connect to my pfSense box. This works fine as I can see in the logs that I do make a connection. I'm also able to ping using my mobile phone to my internal network and I'm also able to connect to my DMZ network using an app "RD Client". The problem I do have is I'm unable to connect to the pfSense Web Gui and this is shown in my firewall logs where it's being blocked.

    I'm not sure how to resolve this issue as I do not understand where the ovpns1 interface comes from. If someone can help me that would be great.

    Regards,



  • So all traffic coming into pfsense thru your openvpn connection enters pfsense on the ovpns1 interface.  You need to explicitly allow incoming connections from this interface – by default all incoming traffic will be blocked (as you're seeing).

    So either add this specific interface under Interfaces > Assign (recommended) or simply add the rules to allow the connection under the OpenVPN tab under Firewall > Rules.  Either way, you need to add rules somewhere to allow this traffic to come in thru the vpn tunnel.



  • Hello and Thank you for your response.

    I tried your suggestions but unfortunately I'm still unable to connect the to pfSense Box but able to my Web/Mail server.

    I created a new interface and added a open rule under the interface. I also went to the OpenVPN tab and notice that a auto rule already existed.



  • I'm working on incomplete information here, but here's my best guess…

    You're policy routing all traffic coming in thru that webgui interface back thru the webgui gateway.  So the only way you can access the webgui on that interface is by accessing it via the tunnel IP address.  So check the assigned ip for the webgui interface -- then try to access the webgui thru that IP only as it's the only one you're going to be able to reach due to your policy routing rule.

    Based on the screenshots, my best guess is that your vpn server is using 192.168.4.0/24 as the tunnel network?  If so, I'm guessing the vpn server has ip 192.168.4.1 so you should be able to hit the webgui via 192.168.4.1.  If not, check Status > Interfaces to see what IP the vpn interface has been assigned.  Alternatively, removing the gateway and setting it back to default on that rule should allow you to hit it via 192.168.2.1 as well.  Note that changing the gateway to default and keeping that any/any pass rule gives all connections on the vpn full access to all networks available on the router, which maybe you were trying to avoid?



  • @kiekar:

    I also went to the OpenVPN tab and notice that a auto rule already existed.

    Just noticed this now… remove all the rules from this tab.  If you're going to create the specific interfaces for each tunnel (which I highly recommend) then just remove all the rules from that OpenVPN tunnel and pretend that tab doesn't exist.  That's how I prefer to do it -- create rules per interface (tunnel).



  • just remove all the rules from that OpenVPN tunnel and pretend

    I did what you suggested and this seems to have help where the firewall log no longer shows blocked but when I point to the the default gateway using my mobile phone with the browser address of e.g. 192.168.2.1 or 10.10.0.1, the pfSense Web configurator won't load. I  am also no longer able to connect using the RD client App to my Web Server.




  • if you still have the any/any pass rule on the webgui interface and the gateway is now default and it's not connecting then you'll need to step back and troubleshoot things from the beginning.

    1. Can you ping the pfsense host from the vpn client?
    2. Can you ping lan hosts behind pfsense from the vpn client?
    3. Can you ping the client from pfsense host?
    4. Can you ping the client from a host behind pfsense?

    If any of those is "no" then you need to troubleshoot the vpn connection.  If all are "yes" and you still can't load the webgui or rdp then you'll need to use the packet sniffer and start tracing packets as they enter pfsense and try to figure out what's happening.

    afaict, the traffic is being allowed and so I'm not really sure why it's not working at this point.  Maybe a routing table issue on the client?  But that seems unlikely as that last screenshot seems to show an incoming connection from the client being allowed.



  • Again Thank You for your input.

    I haven't had a chance to do any further ping tests and to use a packet sniffer which I'm not familiar with packet tracing but I visited a family member today where I used their network and a surprise I was able to get the WebGui Configurator loaded on the browser with my mobile phone and also was able to login my Web Server using the RD App.

    However when trying to use my mobile phone data plan network the connection was again not possible either by using the browser to load the WebGui nor the RD App.

    Is it possibly the phone that's giving me grief with a configuration issue or my mobile phone provider?



  • You're adding more variables to the equation and there were already too many unknowns. :)

    If your phone connects as expected on external wifi, but not on the LTE network then it would seem to point to an issue with your mobile carrier, but you'd have to do a lot of troubleshooting to confirm that assumption.  I'd start with ping tests while connected to LTE and if you can't ping, do a traceroute from the phone to see what's going on.  Is it possible your mobile provider is blocking OpenVPN connections?  Unlikely, but maybe – again too many variables & unknowns, not enough facts.

    But wifi works and LTE doesn't is at least something to work with.  Do the ping & traceroute tests when connected to LTE and work from there.  Seems like a phone config problem.  Does your LTE provider do CGNAT?  I don't think that should cause an issue, but maybe?  Have you tried connecting with another device?

    Having connected successfully to both the webgui and your rdp host behind pfsense using wifi, I think it's safe to say the openvpn server is properly configured and operational.  The rest, I'm afraid, is going to be up to you to troubleshoot.