Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Cannot Connect to the Web Gui Externally

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 2 Posters 2.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      kiekar
      last edited by

      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,

      1 Reply Last reply Reply Quote 0
      • S
        Slugger
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • K
          kiekar
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • S
            Slugger
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • S
              Slugger
              last edited by

              @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).

              1 Reply Last reply Reply Quote 0
              • K
                kiekar
                last edited by

                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.

                webguivpn.jpg_thumb
                webguivpn.jpg

                1 Reply Last reply Reply Quote 0
                • S
                  Slugger
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • K
                    kiekar
                    last edited by

                    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?

                    1 Reply Last reply Reply Quote 0
                    • S
                      Slugger
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.