Tutorial: Configuring pfSense as VPN client to Private Internet Access
-
@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.
-
these are the updated instructions just provided to me:
https://helpdesk.privateinternetaccess.com/hc/en-us/articles/115005760606-Setting-up-a-Router-running-pfSense-Firmware
-
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'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:
-
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
-
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.
-
-
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 ?
-
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?
-
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.
-
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
-
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.
-
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?
-
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)?
-
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.
