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

    Different firewall rules for different OpenVPN servers (on single pfSense)

    Scheduled Pinned Locked Moved Firewalling
    16 Posts 7 Posters 7.6k 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.
    • M
      moikerz
      last edited by

      Got it, thanks Viragomann. I missed the "no other settings to be made here" part.

      Out of interest, you mention that it shouldn't be necessary for me to require different interfaces - I'm open to a different approach, if you could elaborate..?

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

        You can just put the rules on the OpenVPN group tab using the appropriate tunnel networks and remote networks as the source addresses.

        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
        • M
          moikerz
          last edited by

          Ah, that makes sense - mostly. But I'm not understanding the purpose of the tunnel vs remote networks.

          My site-to-site has a tunnel net and a remote net defined.

          My site-to-client only has a tunnel net defined.

          Am I correct in thinking that if I want to define a firewall rule, that I should use Source = remote-net for the site-to-site link, and Source = tunnel-net for the site-to-client link?

          1 Reply Last reply Reply Quote 0
          • V
            viragomann
            last edited by

            Yes, that's correct.

            The source in the rules has to be that IP (range) which the firewall sees when packet come in.
            On the remote access server, clients get an IP of the tunnel network. So incoming packets has a source address in the tunnel network.
            On a site-to-site, the packets come in with a source address from the remote LAN (without doing NAT). The tunnel network is only a transfer network here.

            1 Reply Last reply Reply Quote 0
            • M
              moikerz
              last edited by

              Perfect, exactly what I was thinking.

              I think I'll avoid separate interfaces, and just identify by the IP range, as it seems fairly clean for only a couple of OpenVPN instances.

              1 Reply Last reply Reply Quote 0
              • H
                helo
                last edited by

                I don't mean to revive an old thread, but there is a very good security reason to have the VPN instances on their own firewall interface. From a security perspective, you want each VPN instance to have a DROP ALL rule for anything you don't expect that specific interface to have. By sharing a single interface, there are rules for VPN-A that you don't want applied to VPN-B connections. For the most part there is minimal risk because any packets that get through this way would have no route back, however, carefully crafted packets by a skilled attacker could still do significant damage.

                tl;dr If your goal is security, all instances should have their own interface and only allow what is needed and drop the rest.

                1 Reply Last reply Reply Quote 0
                • bingo600B
                  bingo600
                  last edited by

                  @helo:

                  I don't mean to revive an old thread, but there is a very good security reason to have the VPN instances on their own firewall interface. From a security perspective, you want each VPN instance to have a DROP ALL rule for anything you don't expect that specific interface to have.

                  But it seems like most of the OVPN Gurus here, says : Create the IF if needed , but DO NOT put any rules on/in it.

                  I do agree with your statement above, but it would only be feasible IF it doesnt FSCK up the way OVPN is intended to function on pfsense.

                  I'm a OVPN newbie my self, and would like to know if it is possible to put (more specific) rules on the logical tunne interface.
                  Or if that would mess with the already defined OpenVPN interface group rules.

                  /Bingo

                  If you find my answer useful - Please give the post a šŸ‘ - "thumbs up"

                  pfSense+ 23.05.1 (ZFS)

                  QOTOM-Q355G4 Quad Lan.
                  CPUĀ  : Core i5 5250U, Ram : 8GB Kingston DDR3LV 1600
                  LANĀ  : 4 x Intel 211, DiskĀ  : 240G SAMSUNG MZ7L3240HCHQ SSD

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

                    The OpenVPN tab is really just an interface group for all OpenVPN instances. Rules there are processed before the rules on any specific assigned interface tab (all interface group rules are processed before dedicated interface rules).

                    Actually, the advice I generally give is if you use assigned interfaces, don't put any rules on the OpenVPN group tab and exclusively use the assigned interface tabs. There are probably a number of people who don't know what they are doing, and should have probably hired someone to set up their network,Ā  who have both an OpenVPN server defined (technically a LAN) and a connection to a VPN provider (technically a WAN) with pass any any any on the OpenVPN tab.

                    One can also rely somewhat on OpenVPN itself to not process traffic inbound from a connection with a source address that is not either the connection's tunnel address or any defined remote networks. Of course that is not the same as firewalling. That is probably only effective in server mode, though, thinking about it.

                    If your threat model does not trust your OpenVPN connections, then the ability to assign interfaces to each instance exists, with a default deny any rule on each of them.

                    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
                    • GilG
                      Gil Rebel Alliance
                      last edited by

                      I have created interfaces for each openvpn service on my central server for firewalling.
                      I have 6 separate services running.
                      One is a tap and as such is part of a bridge to the LAN, do the firewalls apply the same?
                      I also have an OpenVPN connection from an OPENWRT, this is a little tricky when you don't want clients to client connectivity. I assume I need to create rules for this, as the 'checkbox' does not work for this scenario

                      11 cheers for binary

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

                        The firewall rules on your bridge will be governed by these

                        net.link.bridge.pfil_member: 1
                        net.link.bridge.pfil_bridge: 0

                        sysctls like all bridges. To be honest I do not know how an interface group rule operates on a bridge but I would anticipate it being the same as any other interface.

                        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
                        • GilG
                          Gil Rebel Alliance
                          last edited by

                          Okay, thanks for the tip. I will have a look at how this changes my firewall behaviour.

                          11 cheers for binary

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