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

    Using Open VPN service on XG-7100, prevent LAN clients connecting

    Scheduled Pinned Locked Moved Firewalling
    48 Posts 5 Posters 6.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.
    • S
      shapelytraffic @JKnott
      last edited by

      @JKnott you must have worked with any other kind of firewall that provides a VPN client (ex: SonicWall). In my experience, you don't have to roll your sleeves up to prevent LAN traffic from initiating the VPN. - you can't go in through the out door.

      What I'm not understanding is why there isn't a prefab to do this?

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

        I mean, if you go back to the first comments, it's clear that there was a misunderstanding. One which was not admitted to.

        JKnottJ 1 Reply Last reply Reply Quote 0
        • JKnottJ
          JKnott @shapelytraffic
          last edited by

          @shapelytraffic

          Is that SonicWall just a firewall? Or firewall/router? Entirely different devices. The purpose of a router is to route packets from one network to another. PfSense does that, but also has filtering so that it can be used as a firewall. Since the LAN and WAN are different networks, pfSense routes the packets. It makes no difference what the address is, if it's on the WAN interface, it gets routed in that direction, just as would a packet for the ISPs gateway. Then there's the added factor in that the WAN address is one of at least two valid addresses for the pfSense box. You're asking for something extra to block that VPN connection and that is a rule on the LAN interface. Also, think of other things that you might want to do. For example, in testing, you may want to use a specific interface, to ensure routing is working. So, from the LAN, you could ping the WAN address to verify it works. Or you could tell it to ping from a specific interface out onto the LAN. If you ping from the WAN, the replies have to be able to come back. Again, you have to configure what you want with the rules. That's what they're there for.

          PfSense running on Qotom mini PC
          i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
          UniFi AC-Lite access point

          I haven't lost my mind. It's around here...somewhere...

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

            This post is deleted!
            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              There is usually no reason to block clients connecting a VPN from an internal interface. If that have access to the VPN then it's not a security issue anyway. At worst it might cause routing issues for clients who accidentally connect to the VPN when they are on the internal subnet.
              If you don't want to ever happen for some reason you can make a floating reject rule with destination WAN address and port the VPN port and apply that to all the interfaces you want it on.

              Steve

              S 1 Reply Last reply Reply Quote 1
              • S
                shapelytraffic @stephenw10
                last edited by

                @stephenw10 thanks for an easy answer. :D

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

                  This post is deleted!
                  1 Reply Last reply Reply Quote 0
                  • P
                    Pelispedia Banned
                    last edited by

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