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

    [SOLVED] How to disable web interface on OVPN client interface

    Scheduled Pinned Locked Moved Firewalling
    11 Posts 2 Posters 4.1k 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.
    • G
      graymattr
      last edited by

      Hi folks,

      I've recently set up a client OVPN on my pfsense router.  It's working great, well, a little too great, as the web UI is reachable on the OVPN address.  I've followed the steps here:  https://doc.pfsense.org/index.php/Restrict_access_to_management_interface, but I cant seem to get the web UI to only be reachable from LAN addresses.  Attached is a picture of my current LAN firewall rules.  It seems to be correctly preventing me from reaching the pfsense UI from my WAN IP, but not from the OVPN Client IP…

      I'm fairly sure I'm missing something obvious, but I think I've been staring at this for too long to see it.  :)  Any help is very much appreciated.

      Cheers!
      ![Screen Shot 2016-02-20 at 1.15.28 PM.png](/public/imported_attachments/1/Screen Shot 2016-02-20 at 1.15.28 PM.png)
      ![Screen Shot 2016-02-20 at 1.15.28 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-02-20 at 1.15.28 PM.png_thumb)

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        Shouldn't your block rule be on the OpenVPN interface as well as the LAN interface?

        1 Reply Last reply Reply Quote 0
        • G
          graymattr
          last edited by

          Ahh yes, I totally forget to include that.  Apologies.  Here's the rule I have on the OpenVPN interface.

          EDIT:  The OpenVPN interface is for the server, the one shown is the client.  Just realized that might be confusing.

          ![Screen Shot 2016-02-20 at 2.01.25 PM.png](/public/imported_attachments/1/Screen Shot 2016-02-20 at 2.01.25 PM.png)
          ![Screen Shot 2016-02-20 at 2.01.25 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2016-02-20 at 2.01.25 PM.png_thumb)

          1 Reply Last reply Reply Quote 0
          • KOMK
            KOM
            last edited by

            I'm still unclear.  Your OpenVPN interface is to allow pfSense to connect to some external VPN service, and the SONICVPN interface lets your external clients connect to your pfSense?  Did you clear all states before running your tests?

            1 Reply Last reply Reply Quote 0
            • G
              graymattr
              last edited by

              Sorry, no, it's the other way around.  Sonicvpn is the client (facing outward), OpenVPN is the server (for remoting in).

              What do you mean by clear all stats?  I set the rules, reload them, and then test from an external network (via browser and nmap).  Is there another step I am missing?

              Cheers

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by

                Sonicvpn is the client (facing outward), OpenVPN is the server (for remoting in).

                And who is able to reach your WebGUI, your OpenVPN remote users?  If so, the rule should be on the OpenVPN interface, not the Sonic.

                What do you mean by clear all stats?

                Existing states don't get torn down with a firewall rule change.  Go to Diagnostics - States and clear/reset them (or filter for specific states and just clear those), then try your test again.

                1 Reply Last reply Reply Quote 0
                • G
                  graymattr
                  last edited by

                  The GUI is reachable on the client (Sonic) IP address (which is where the rule I posted is).  Thanks for the tip about states, I didn't realize that and I'll make sure I clear/reset those on firewall changes.  Maybe that's the issue…

                  EDIT:  Cleared all states, no change.  I'll keep fiddling my rules unless anyone has any other ideas.  The good news is that these rules are preventing GUI access on my WAN (non VPN'd) IP.  Halfway there.

                  1 Reply Last reply Reply Quote 0
                  • G
                    graymattr
                    last edited by

                    Would it make more sense/work if I set this up as a floating rule?  I was thinking I could allow on the LAN interfact from my 192.168.0.0/24 network as a top rule, and then reject any from LAN/WAN/SONICVPN.

                    Am I understanding floating rules that they are matched before interface rules, and in order?  Thanks so much!

                    1 Reply Last reply Reply Quote 0
                    • KOMK
                      KOM
                      last edited by

                      Floating rules are typically used for traffic shaping.

                      1 Reply Last reply Reply Quote 0
                      • G
                        graymattr
                        last edited by

                        Ahh, ok.  I'll stick with the per interface variety.  I'm developing a bruise from all of the banging my head on this one.  :)

                        1 Reply Last reply Reply Quote 0
                        • G
                          graymattr
                          last edited by

                          I found it.  I had a rule on the OpenVPN interface (that was labeled "Rule via Wizard" or similar, so I didn't pay much attention to it) that was passing *.  I might have broken my OpenVPN Server config temporarily, but I've secured the web GUI from the VPN client VIP, which is want I was trying to do.  I can re-add server rules that are less permissive over time.

                          Thanks so much to KOM for the help.  Sorry for being a bonehead.  :)

                          Hope this helps someone else.

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