Tutorial: Configuring pfSense as VPN client to Private Internet Access


  • LAYER 8 Netgate

    They are completely separate. Just use a separate tunnel network for the Remote Access OpenVPN.



  • @Derelict:

    They are completely separate. Just use a separate tunnel network for the Remote Access OpenVPN.

    Does this mean I have to choose under Firewall - Rules - OpenVPN Server a different gateway for the server? (''clean'' WAN instead of the PIA gateway)

    Thanks!


  • LAYER 8 Netgate

    You need to select the interface you expect the connections from the client to arrive on. That is probably WAN and not PIA.



  • @Derelict:

    You need to select the interface you expect the connections from the client to arrive on. That is probably WAN and not PIA.

    Still can't set it right. When a client is connected to the OpenVPN server, my PIA connection is either slow or down. I have to disable the server to get my connection back.

    Do I have to create a rule for both OpenVPN and PIA interfaces or just for OpenVPN? Currently under Firewall –-> Rules ---> PIA there aren't any rules set at all.

    I have created a rule for the OpenVPN interface to look like the one below:

    Interface: LAN (''Bridge'' in my case as I have bridged 2 NICs to act as one)
    Address Family: IPv4
    Protocol: TCP/UDP
    Source:Any
    Destination: Any
    Destination Port Range: 1194

    Advanced Options -->  "Gateway"---> WAN

    I apply the above but still don't see any difference.



  • Anyone that can actually help with the problem above? It will be much appreciated.

    I did the following:

    -I have created separate interfaces for both my PIAVPN and OpenVPN Server.

    -Under NAT, I generated the default WAN ''Outbound'' values for both PIAVPN (client) & OpenVPN Server

    -Created a WAN rule which allows TCP/UDP traffic to port 1194 and have selected under ''Advanced Settings'' –--> ''Gateway'' the WAN_DHCP instead of the ''Default'' I then duplicated that rule to be present under ''LAN'' as well as under ''Bridge'' tab as I have bridged the 2 NICs of my APU2C4 to act as one LAN.

    -There are no rules at all under the tabs ''OpenVPN'', ''LAN2'', ''OPENVPN'', ''BR0''.
    At the moment, rules are set only for ''WAN'', ''LAN'' and ''Bridge''.

    On the pfSense dashboard the available interfaces are all being shown as active:

    WAN        ---- up        (ip assigned)
    LAN          ---- n/a
    LAN2        ---- n/a
    PIAVPN    ---- up        (ip assigned)
    OpenVPN  ---- up        (ip assigned)
    BR0          ---- up        (ip assigned)

    What am I missing?



  • I've followed a few different guides, and googled for quite a while and can't seem to get my connection to work properly. 
    My mappings are set:

    pfSense shows openVPN as connected, and my VPN interface has an IP assigned to it.  Everything looks like it should be good

    I have two LAN firewall rules to specify which computers use the vpn and which don't:

    I am unable to access the internet when OpenVPN is connected from a VPN_Users aliased computer.
    I am able to ping fine from this computer ex. www.google.ca, but when I try to load a page Firefox just sits saying "Preforming TLS Handshake with.." and never loads. As soon as I shut down OpenVPN service, internet works as normal

    I've tried looking at the log, but see no mention of an error.

    I'm assuming this is related to my firewall not being configured properly and blocking the access.  I just don't know what I'm missing.

    Any Suggestions?



  • @Haze028, I noticed your LAN network is 150.160.170.0/24, which is a public IP range.  If you haven't purchased or otherwise own this block of IPs, you should stick with private IP ranges.





  • i've followed the instructions above and now i am getting several events in the logs

    WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'

    WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
    WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a –cipher with a larger block size (e.g. AES-256-CBC).
    WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

    seems like several red flags.  what is everyone's opinion on this?



  • @bcruze:

    i've followed the instructions above and now i am getting several events in the logs

    WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1558', remote='link-mtu 1542'

    WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher BF-CBC'
    WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a –cipher with a larger block size (e.g. AES-256-CBC).
    WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.

    seems like several red flags.  what is everyone's opinion on this?

    I get the 'link-mtu' warnings as well.  The Blowfish/SWEET32 warning is because PIA can't competently maintain their systems (and I'm a customer!) and still defaults to BF-CBC instead of at least AES-128-CBC.  They really should be using the latest OpenVPN 2.4.4 with NCP support.  As much as I like PIA, they can be a real frustrating PI[T]A….

    As long as you (the client endpoint) have your config set to use AES-128-CBC or AES-256-CBC, it'll override the server settings, so don't worry about that warning.



  • Thanks for the guide. I was able to get this configured in about an hour or so. There are a couple of things to note:

    1. OpenVPN server port numbers are different for PIA depending if you use a sha256 or sha128 cert: https://www.privateinternetaccess.com/forum/discussion/21213/sha256-with-openvpn

    2. I didn't want my Steam gaming traffic going over the VPN (ports 27000-27015,…) so I used a NAT Alias to create a list of ports to apply to the outbound NAT rule.



  • LAYER 8 Netgate

    That's great but outbound NAT rules have nothing to do with what traffic goes out which interface. They only dictate what NAT occurs when traffic is already routed out that interface by policy routing or the routing table.



  • Hrm, makes sense I guess. Got a link to something explaining how to route 80/443/53 over the VPN interface while leaving all other traffic egressing the WAN ?


  • LAYER 8 Netgate

    Just check don't pull routes in the OpenVPN Client configuration then policy route those destination ports to the VPN Gateway followed by pass any without setting a gateway.



  • Ah, I think that works but only if I specify the VPN gateway in the LAN pass rule (under Advanced).  You mention "pass any without setting a gateway." but where else would I specify the VPN gateway for those ports?


  • LAYER 8 Netgate

    You policy route using firewall rules as you already stated. So you make a rule specifying those destination ports and the desired gateway/gateway group.



  • Thanks. Netflix won't work going over the vpn interface so I've created a hosts Alias containing the IP ranges for AS2906 (netflix) and created a second rule on the LAN to route the Netflix alias destinations over the WAN interface instead of the VPN interface. It doesn't seem to pick up the change though. I've reset under 'diagnostics > states > reset states' but the rule doesn't seem to be working. Tcpdump on the vpn interface shows the Aliased IP addresses still going over that interface.

    The docs say "first match wins" so if I have the Netflix rule at the top, and the VPN rule after that this should be working, correct? I'm assuming I'm missing some IP addresses Netflix is using but want to make sure I understand the rule ordering.


  • LAYER 8 Netgate

    Post your rules then. I guarantee if the alias contains the required destinations and the rules are done correctly, it works.



  • The rules are working, I think I'm just missing IP ranges. I'm using tcpdump on the PFsense box to see what's egressing the vpn interface. Even after adding a new range, I'll reload Netflix in my web browser and tcpdump shows it still hitting that IP on the vpn. If I wait a minute or so, then it seems to pick it up. Are rule changes only applied to new connections?



  • this works for me

    180 is the static ip address of my tv



  • LAYER 8 Netgate

    Yes, it is often easier to just exclude everything from the device from egressing the VPN than try to match every destination address and port for something like netflix.



  • @bcruze:

    180 is the static ip address of my tv

    I'm not sure I understand. Are you just filtering by source IP rather than by a zillion Netflix destinations?


  • LAYER 8 Netgate

    Yes. He's telling it to put everything FROM that device out WAN regardless of destination. Far easier than trying to single out "Netflix."



  • Good idea. Unfortunately, I have a mix of devices on the LAN which also access Netflix.  For now, I've added around 30+ subnets to my Netflix Alias. It's not great but it keeps the tablets/phones on the VPN for everything but Netflix.



  • If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?



  • @Dave:

    If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?

    To fix this, go to Services / DNS Resolver and under "Outgoing Network Interfaces," select only your PIA VPN interface(s) and make sure "All' and "WAN" aren't selected.

    This fixes the DNS leak over your regular WAN but introduces the problem that if your VPN ever goes down, pfSense will not be able to resolve DNS to reconnect the VPN.  To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing (Google, OpenDNS, Level 3, Verisign, etc.).  This setting only affects outbound DNS queries by localhost, not by anything on your LAN, which should go out the PIA VPN only via unbound.



  • Thanks! Precisely what I was wanting. em0 egress is looking better now.

    @Finger79:

    To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing

    I'm assuming the screenshot is correct?




  • @Dave:

    Thanks! Precisely what I was wanting. em0 egress is looking better now.

    @Finger79:

    To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing

    I'm assuming the screenshot is correct?

    see now this is when my head starts hurting.    the  instructions never say to create a new interface.  so when i got home i disabled, the PIA interface to test my connection to see if it still worked and it did.  so i deleted the openvpn/ PIA interface.    so i can't change this setting.

    so are you saying on the standard PIA instructions your data is not routed correctly on the outgoing interface..?

    when i go to PIA.com i have a protected IP.  and i am getting my normal speeds and i have not for some time.  i really don't want to alter this unless i have too



  • @bcruze:

    so are you saying on the standard PIA instructions your data is not routed correctly on the outgoing interface..?

    My setup is a little different than "VPN all the things!" which is the direction given by all the tutorials I've found anyway. Straight off, yes all my traffic was egressing the VPN tunnel as it should but I don't want Steam going over it, and Netflix absolutely refuses to run as well. Fiddling around with splitting the traffic over multiple interfaces is inherently problematic because now I need to use IP addresses, protocol and port to determine what goes where. And that's not always a straightforward thing (Especially for Netflix. I'm a little surpised my setup is working at all with all the Aliases I had to configure.)

    That said, I'm continually impressed by pfSense. It's enterprise grade software in features, quality and functionality. I'm very grateful for the tutorial in this thread and all the support from the forum folks. Thanks all.

    PS: Um..not sure I follow what you mean about creating a new interface. Isn't it right there in the first post under "Create OpenVPN interface" ?



  • i am following the newest guide:

    https://www.privateinternetaccess.com/forum/discussion/29231/tutorial-pia-on-pfsense-2-4?new=1

    i also posted an updated link just about the top page of 22.  from a PIA staff



  • @bcruze:

    i am following the newest guide:

    https://www.privateinternetaccess.com/forum/discussion/29231/tutorial-pia-on-pfsense-2-4?new=1

    i also posted an updated link just about the top page of 22.  from a PIA staff

    Their guides are never perfect.

    @Guide:

    14.) Ensure NCP is checked.
          Remove AES-128-GCM and AES-256-GCM by clicking on them in the darkened box in NCP Algorithms
          Add AES-128-CBC and AES-256-CBC  by selecting them in the left box.

    This is stupid and defeats the purpose of NCP in OpenVPN 2.4 which automatically negotiates the NCP ciphers if both client and server support NCP.  NCP should remain set to AES-256-GCM and/or AES-128-GCM.  And the traditional cipher should be set to AES-256-CBC or AES-128-CBC.

    @Guide:

    17.) Custom Options: Add these parameters:

    persist-key
              persist-tun
              remote-cert-tls server
              reneg-sec 0

    "persist-key" and "persist-tun" are already hard-coded in pfSense's OpenVPN implementation and are redundant if specified here.  They should be left out because all this does is list the directives twice in the config file.

    Mine are currently set to:

    Advanced Configuration Settings from GUI

    remote-cert-tls server
    auth-nocache
    tls-version-min 1.2
    reneg-sec 0
    pull-filter ignore "auth-token"

    I learned a lot from reading the OpenVPN 2.4 Manual.  Took several hours over several days before I had a basic understanding of how to harden the config settings.  The pull-filter ignore "auth-token" is my latest addition since I was having issues with the session token expiring and the VPN would never automatically reconnect by itself.  Adding that directive keeps pfSense connected to PIA 24/7 and automatically reconnects.



  • @Finger79:

    "persist-key" and "persist-tun" are already hard-coded in pfSense's OpenVPN implementation and are redundant if specified here.  They should be left out because all this does is list the directives twice in the config file.

    It's worth noting  (and this may have been stated already in the previous 20 pages of thread) that the tutorial in this thread also configures /etc/openvpn-password.txt for the vpn user and password. I've omitted this portion since there is a configuration field in the UI for both of these (I presume earlier versions of pfSense did not have this feature). Either method does seem to work but I prefer keeping config items in one place when possible. Not to mention the added potential problems with cleartext files and permissions.



  • First thank you for taking the time to write this tutorial.

    I went through it but got stuck to the point where no traffic goes through VPN interface and couldn't find how to resolve it.

    pfSense's WAN and VPN interfaces are up and running, WAN and VPN's gateways are also online, and OpenVPN client instance to our VPN's Provider server is also up (please see attached file), I'm able to ping VPN's Hong Kong server from pfSense's WAN interface but not form VPN and LAN's interfaces. I know it's something wrong with firewall rules or DNS that not been configured properly.

    I did upgrade pfSense to the latest version 2.4.2-RELEASE-p1 (amd64).

    Could you please help me on where else to look into to fix this.

    ![pfSense OpenVPN client.PNG](/public/imported_attachments/1/pfSense OpenVPN client.PNG)
    ![pfSense OpenVPN client.PNG_thumb](/public/imported_attachments/1/pfSense OpenVPN client.PNG_thumb)



  • I've been dealing with Jeremy from PIA as I discovered that I had a DNS leak, using their DNS servers. I even used their servers on the modem. If I used their dnsleak.com test it all came back fine but if I used a different service, dnsleaktest.com and ran the extended test it came back to my home address and not the PIA address.

    Here is my latest:

    Thank you for that information, Looking through the log it looks like you are using either a firewall rule or some piece of code that is incorrect. Looking this up online it looks like the block-outside-dns is not compatible with the openvpn version running inside PfSense. This could of been added recently and may not have anything to do with the leak but I just wanted to make sure.

    These leaks may be attributed to not creating the firewall and NAT rules protecting your connection. Please follow this more up to date pfsense guide fully to ensure that the VPN is set up correctly including the correct firewall rules. Here is the guide if you get stuck please let me know.

    The guide: https://helpdesk.privateinternetaccess.com/hc/en-us/articles/115005760606-Setting-up-a-Router-running-pfSense-Firmware  which says to use 1194 as the port, and when I do that I receive TLS errors I've been using 1198 and it connects without an issue. I do not have TLS configuration checked as it fails to connect when I do.

    I just sent him a reply with screenies showing him the rules I've used, through this guide. I eagerly await his reply.



  • @Finger79:

    @Dave:

    If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?

    To fix this, go to Services / DNS Resolver and under "Outgoing Network Interfaces," select only your PIA VPN interface(s) and make sure "All' and "WAN" aren't selected.

    This fixes the DNS leak over your regular WAN but introduces the problem that if your VPN ever goes down, pfSense will not be able to resolve DNS to reconnect the VPN.  To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing (Google, OpenDNS, Level 3, Verisign, etc.).  This setting only affects outbound DNS queries by localhost, not by anything on your LAN, which should go out the PIA VPN only via unbound.

    This is not entirely true.  You do not need to add a 3rd party DNS for WAN use.

    When System >> General DNS "Outgoing Network Interfaces" is configured for a given DNS server, pfSense creates a static route for that DNS entry to go out that interface, but only when that interface is up.  Otherwise the routing is subject to the current routing table default routing, thus DNS queries will go out the default route, usually the WAN.  (This also applies to policy routing rules, which are only added after the target gateway interface is online.)  So you have to plan routing and rules in two states; 1) When VPN links are down and WAN is default route, and 2) when VPN links are up.

    What's missing in the DNS routing is configuring Unbound to use localhost for outbound queries so that outbound DNS queries go through default routing.  If Unbound is configured to only use the VPN links as outbound interfaces, then of course those interfaces will not be usable when the VPN is down, and Unbound will have no other interface for outbound queries.

    Additionally to really prevent unexpected DNS leaks, and extra query traffic, especially when using multi-wan / multi-vpn, configure Unbound to only use localhost for outbound.

    The reason is that Unbound will try to query all configured DNS servers on each configured outbound interface directly, bypassing the route table, and then manage responses accordingly, which results in leaks if WAN is configured as an outbound interface, and lots of extra activity if you have multiple links.  Configuring Unbound to only use the localhost for outbound not only limits the amount of queries outbound attempts, but also subjects all outbound queries to NAT'ing and routing.  Thus when the VPN links are down, dns queries are routed out the default route, which should be the WAN, but when the VPN links are up and are the default route, DNS queries go out the VPN default routes (either by default or as configured for "Outgoing Network Interface" once the link is up.  When Unbound is configured to use only localhost as outbound, you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.) as outbound queries from localhost will go out the VPN link once it becomes the default route.

    And as an added note: Since PIA does not support IPv6, Unbound needs to be configured to disable IPv6 queries, otherwise there is a bit of a performance hit with all DNS queries as it wil try to resolve both A & AAAA records for all queries.  Add the Unbound configuration directive "server: do-ip6: no" to turn off AAAA record queries.



  • @TechyTech:

    @Finger79:

    @Dave:

    If I'm running 'Services > DNS Resolver' on PFsense, It looks like (most?) of my DNS queries are still going out the WAN. Is this because the the source IP is 'LAN net' on my VPN policy (ports 80,443,53) and the Resolver is using my WAN IP for the DNS queries (at least what it looks like from tcpdump)?

    To fix this, go to Services / DNS Resolver and under "Outgoing Network Interfaces," select only your PIA VPN interface(s) and make sure "All' and "WAN" aren't selected.

    This fixes the DNS leak over your regular WAN but introduces the problem that if your VPN ever goes down, pfSense will not be able to resolve DNS to reconnect the VPN.  To fix this, go to System / General Setup and specify a 3rd party DNS resolver of your choosing (Google, OpenDNS, Level 3, Verisign, etc.).  This setting only affects outbound DNS queries by localhost, not by anything on your LAN, which should go out the PIA VPN only via unbound.

    This is not entirely true.  You do not need to add a 3rd party DNS for WAN use.

    When System >> General DNS "Outgoing Network Interfaces" is configured for a given DNS server, pfSense creates a static route for that DNS entry to go out that interface, but only when that interface is up.  Otherwise the routing is subject to the current routing table default routing, thus DNS queries will go out the default route, usually the WAN.  (This also applies to policy routing rules, which are only added after the target gateway interface is online.)  So you have to plan routing and rules in two states; 1) When VPN links are down and WAN is default route, and 2) when VPN links are up.

    What's missing in the DNS routing is configuring Unbound to use localhost for outbound queries so that outbound DNS queries go through default routing.  If Unbound is configured to only use the VPN links as outbound interfaces, then of course those interfaces will not be usable when the VPN is down, and Unbound will have no other interface for outbound queries.

    Additionally to really prevent unexpected DNS leaks, and extra query traffic, especially when using multi-wan / multi-vpn, configure Unbound to only use localhost for outbound.

    The reason is that Unbound will try to query all configured DNS servers on each configured outbound interface directly, bypassing the route table, and then manage responses accordingly, which results in leaks if WAN is configured as an outbound interface, and lots of extra activity if you have multiple links.  Configuring Unbound to only use the localhost for outbound not only limits the amount of queries outbound attempts, but also subjects all outbound queries to NAT'ing and routing.  Thus when the VPN links are down, dns queries are routed out the default route, which should be the WAN, but when the VPN links are up and are the default route, DNS queries go out the VPN default routes (either by default or as configured for "Outgoing Network Interface" once the link is up.  When Unbound is configured to use only localhost as outbound, you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.) as outbound queries from localhost will go out the VPN link once it becomes the default route.

    And as an added note: Since PIA does not support IPv6, Unbound needs to be configured to disable IPv6 queries, otherwise there is a bit of a performance hit with all DNS queries as it wil try to resolve both A & AAAA records for all queries.  Add the Unbound configuration directive "server: do-ip6: no" to turn off AAAA record queries.

    Very interesting.  Thanks for the info!

    @TechyTech:

    you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.)

    It's frequently advised in the forums here to disable pulling routes in OpenVPN client config.  Lots of people do that, which helps with policy-based routing.



  • @Finger79:

    @TechyTech:

    you do not need to configure an DNS outbound interface under System >> General (unless you have disabled pulling routes in the VPN client.)

    It's frequently advised in the forums here to disable pulling routes in OpenVPN client config.  Lots of people do that, which helps with policy-based routing.

    Disabling of pulling routes and use of policy routing is not covered in the "Tutorial", the subject of this thread, and shouldn't be for people just trying to get their VPN service up and running because policy routing can not be applied to traffic generated by the firewall such as Unbound and Squid proxy.  This is why so many people have problems with DNS & proxied traffic leaks when using Squid Proxy, even though traffic from their LAN passes (via policy rule) out the VPN.

    Therefore, whether configured from the VPN's pushed configuration, or manually, you need a default route for at least one VPN link, and configure firewall services to use route table routing (via us of localhost as an outbound interface) otherwise traffic that can't go through policy routing will go out either the outbound interface{s} directly, (as both Unbound and Squid will do), or routed via whatever state the routing table is at, including the default route (if VPN is not configured as default route), such as the WAN, again resulting in traffic leaks.

    The main reason I see for disabling of pulling of routes and manually managing them is due to edge cases where the default route get's mis-directed to an undesired link, or is not updated during VPN link transitions, but falls back to the default WAN, resulting again in traffic leaks.  This gets further into use of policy routing and the use of gateway groups in multi-WAN/multi-VPN, but does not eliminate the need for a properly configured default route.  But alas also, using multiple VPN links is outside the scope of a simple tutorial to get PIA VPN link up and running with pfSense, without leaking traffic out the WAN.

    So in a single link scenario, better to stick to pulling route configurations and understanding default routing is necessary for firewall initiated services such as DNS and Proxy, to simplify initial configuration, for people just trying to get their VPN service configured, without leaking data.



  • This tutorial still works however you need to make the following changes.
    Change port number from 1194 to 1198
    Change encryption from BF-CBC (128-bit) to aes-128-cbc



  • great tutorial, thank you!
    are these instructions still valid for the current version of pfSense?


Log in to reply