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

    OpenVPN to PIA: Separating networks

    Scheduled Pinned Locked Moved OpenVPN
    9 Posts 2 Posters 771 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
      Stan
      last edited by

      Using pfSense 2.5.0. I have several subnets, but for simplicity I’ll focus on two: a computers subnet and an audio/visual subnet (e.g., Roku, TVs). My objective is to have traffic from the computers net go through the PIA VPN, but not traffic from the A/V net. I do not need a kill switch rule; if the VPN is down, I want traffic routed through the WAN.
      I created an outbound NAT rule only for the computers network. I have firewall rules on both the OpenVPN and PIA interfaces to, in order, send traffic from the A/V net to the WAN gateway (using the advanced settings) and from the computers net to the PIA gateway. I have rules for my computer net to, in order, send traffic to the PIA gateway and then to the WAN gateway. I’ve modified the “default allow” rule for my A/V net to specifiy the WAN gateway. In each case the “source” is a network.
      Having so many rules on multiple interfaces is probably overkill, but I doubt that they interfere with each other. I’d hope to be able to implement this with rules just on the PIA interface.
      I’ve experimented with the “Don’t pull routing” option in the OpenVPN client definition. With that option enabled, no traffic goes through the VPN. With the option disabled, traffic from all subnets goes through the VPN. It is now enabled and I’m having trouble getting to Amazon Prime video on Roku.
      I’m confused by the fact that I added outbound NAT rules for OpenVPN only for the networks I want to go through the VPN, but when “Don’t pull routing” is disabled, all nets are going there.
      I’ve tried using host IPs as sources in the rules in addition to networks, but that doesn’t work either.
      Any suggestions?

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

        @stan said in OpenVPN to PIA: Separating networks:

        I have firewall rules on both the OpenVPN and PIA interfaces to, in order, send traffic from the A/V net to the WAN gateway (using the advanced settings)

        Firewall rules have to be defined on the incoming interface. So rules on the VPN interfaces can only handle incoming traffic from the VPN.
        Since you may not want to allow any incoming traffic here, there should be no pass rules.

        So you have to add your rules for outbound traffic to the computers and the A/V network tabs.
        The PIA VPN pushes the default rule to you if "Don't pull routes" is unchecked. Which means that any traffic, which is not routed by policy routing rule to the WAN gateway, goes through the VPN, also traffic from pfSense itselft.
        If you don't want that, you have to check that option and route the computers upstream traffic by policy routing.
        However, consider that a policy routing rule allow only access to the specified gateway. If you use your pfSense for DNS resolution you have to add an additional rule without a specified gateway for allowing this.

        @stan said in OpenVPN to PIA: Separating networks:

        I’m confused by the fact that I added outbound NAT rules for OpenVPN only for the networks I want to go through the VPN, but when “Don’t pull routing” is disabled, all nets are going there.

        Possibly there are automatic generated rules for it?

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

          Thanks for the advice, viragomann. I did remove all firewall rules from the OpenVPN and PIA interfaces. And I have a pass port 53 rule on my subnet interfaces, if that's what you are referring to when mentioning using pfSense for DNS resolution.

          I have tried setting the Outbound NAT firewall mode to Manual and enabling the "Don't pull routing" option in the OpenVPN client definition in order to prevent generation of automatic rules. Still the result is the same whether the Outbound NAT firewall mode is set to Manual or Hybrid. If the "Don't pull routing" option is enabled, none of the networks are routed to the VPN. If it is disabled, all of the networks are routed to the VPN. I haven't found a way to direct some networks to the VPN and others to the WAN.

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

            @stan said in OpenVPN to PIA: Separating networks:

            I haven't found a way to direct some networks to the VPN and others to the WAN.

            The way is easy, it's called policy routing as I told you above. I don't know if your rules are corect, since you don't share.

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

              viragomann,
              Here are the rules for my audio visual network. I don't want devices from this network going through the VPN.
              cef42b42-0851-43ef-a4fb-98064527cb42-image.png
              And the rules for my guest network. I do want the devices there going through the VPN.
              11260913-6aeb-4090-9b0b-45780ade8699-image.png
              The outbound NAT rules mode is set to manual, and I've enabled the "Don't pull routing" option in the OpenVPN client definition, so nothing is currently going through the VPN.
              The Guest network rules block access to private networks, which includes the local address for the VPN. I've tried a rule above the private networks rule with a pass for the local address of the VPN, but that didn't work.

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

                I removed 10.0.0.0/8 from my PrivateNetworks alias, just to check that again, and have the same result.

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

                  @stan
                  The policy routing rule on the guest net should direct the traffic to the VPN.
                  Is the VPN gateway up?
                  Possibly there is another rule matching the packets. Do you have an interface group defined or some floating rules?

                  To troubleshoot you may have to enable logging in all your rules to find out, which rule is applied to the packets.

                  @stan said in OpenVPN to PIA: Separating networks:

                  The Guest network rules block access to private networks, which includes the local address for the VPN.

                  That should not matter. The devices don't need to access a destination in the VPN network.

                  It's recommended to have the outbound NAT in hybrid mode instead manual.

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

                    viragomann,

                    Thanks for all of you help. Things are now working. The key was simply to reboot pfSense, a lesson I'd learned some time back, but forgot about. On your advice, I've set outbound NAT to hybrid mode. Also, I've disabled the "Don't pull routing" option in the OpenVPN client definition.

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

                      @stan
                      Glad that it's working now.
                      Yeah, the outbound NAT often requires rebooting the box to apply the rules. Didn't think of it as well.

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