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

    Restricting WebGui Access To One Interface

    Scheduled Pinned Locked Moved General pfSense Questions
    20 Posts 5 Posters 5.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.
    • ?
      Guest
      last edited by

      …even on a "normal" OPT1 net I don't want anybody to be able to access the webGUI, including via the WAN IP. Now I have to fiddle some firewall rules for that, hmm...

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Well you could argue that you have allowed access to it because by default no traffic is allowed.  ;)
        I pointed this out here because I was caught out by it. It would be nice if you could include the system alias 'wan_address' in your own custom aliases. I use a custom 'local subnets' to isolate interfaces I consider high risk and that would make it much easier.
        You could use a floating rule and a custom port perhaps. There are many ways to prevent this as long as you are aware of it, which I wasn't.

        Steve

        1 Reply Last reply Reply Quote 0
        • ?
          Guest
          last edited by

          I have a dyndns for the WAN address, which I use for site-to-site VPN allow-rule on WAN, which I could use for a block rule for OPT1, no?

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Reject from source OPT1 Net dest WAN address …  Sure.  (I'm partial to reject for this instead of block.  Plays nicer with clients.)

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Hmm, very good point I never thought of that.  ::) Since you can include other urls in an alias I don't see why that wouldn't work.
              But yes for a simple block rule you can just use 'wan address'.

              Steve

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                DDNS hostnames for security rules would make me nervous.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Ah, very true. If ddns fails for whatever reason the webgui would be exposed.

                  Steve

                  1 Reply Last reply Reply Quote 0
                  • ?
                    Guest
                    last edited by

                    …something like this:

                    ??

                    btw: as we are here together, some drinks arround, is anybody willing to share the secret how to force the internet traffic of a single clinet (say 10.0.0.30 out of 10.0.0.0/24) through an openVPN tunnel and the WAN of the other end of the tunnel? Any ideas :-)

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      Looks good to me.

                      (Regarding the VPN, if you're gold watch the latest hangout with jimp about openvpn.  I haven't set it up in test mode yet but there's all kinds of cool stuff in there.  Your question was specifically addressed, IIRC.

                      Talking about it more should probably be its own thread.)

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • keyserK
                        keyser Rebel Alliance
                        last edited by

                        Whooa, this really caught me out too. I didn't realize this could be an issue.
                        I just tested, and my OPT1 does have access to the web gui using the WAN address.

                        I'm also using the local_networks alias and a NOT rule to grant internet access to OPT1 users.

                        One thing i don't understand however. Since the Webgui is listening on WAN, howcome i'm fx. Allowed to let my HAproxy listen on the WAN interface as well? Should't that create a port conflict (80 and 443)? I'm not doing that, i just seem to remember testing that and it worked.

                        Also, is there any way this could be used against me if i have NAT translation rules listening on WAN 80 and 443 to redirect to OPT1 servers?

                        Love the no fuss of using the official appliances :-)

                        1 Reply Last reply Reply Quote 0
                        • ?
                          Guest
                          last edited by

                          Just for the sake of completeness: I don't need to block something on ipv6 to stop opt1 from accessing the webGUI? I don't use it, i turned it off in pfSense, but….

                          Is it possible to "spoof" my WAN IP to an IP of the local net of a remote pfSense and access the webGUI via the WAN interface?

                          1 Reply Last reply Reply Quote 0
                          • DerelictD
                            Derelict LAYER 8 Netgate
                            last edited by

                            @keyser:

                            Whooa, this really caught me out too. I didn't realize this could be an issue.

                            Yeah. My guest network rules don't cover this either.

                            Chattanooga, Tennessee, USA
                            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                            Do Not Chat For Help! NO_WAN_EGRESS(TM)

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              @chemlud:

                              Is it possible to "spoof" my WAN IP to an IP of the local net of a remote pfSense and access the webGUI via the WAN interface?

                              Hmm. Not quite sure what you mean by this.  :-\ Can you clarify it?

                              Steve

                              1 Reply Last reply Reply Quote 0
                              • ?
                                Guest
                                last edited by

                                Thankx for asking! Forget about it, just a strange idea after not enough coffee this morning… We're all safe, I guess :-D

                                1 Reply Last reply Reply Quote 0
                                • I Irk 0 referenced this topic on
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.