PIA using pfSense WireGuard Package
-
@FCS001FCS I performed steps 1 through 6 on a dummy Debian VM. I installed the wireguard client using apt...
All you really need is the /etc/wireguard/pia.conf file generated when you successfully execute ./run_setup.sh
Just FYI, if you successfully run ./run_setup.sh, it will create a wireguard tunnel between your VM and PIA, and that will kill your ssh remote session to the VM. Be ready to jump to the console session of the VM and run "wg-quick down pia" to disconnect the wireguard tunnel, or just use the console session to read the contents of /etc/wireguard/pia.conf which is what really matters to successfully configure the WG client in pfSense
I will also say this: the "Address: 10.1.149.3" section of step #3 occasionally changes to some other IP address, and that requires me to re-run ./run_setup.sh to get the new IP, private key, etc and update all these in pfSense... So using WG with PIA in pfSense is not very stable as PIA changes things every once in a while.
-
@FCS001FCS The github page has this:
I dont know if those packages exist in FreeBSD so I just used Debian to make sure
-
I think this is too complicate for me at the moment and I will stay with Open VPN when using PIA on my pfSense bare-metal setup.
Hopefully, either PIA, or someone more knowledgeable with pfSense/FreeBSD, with create a pfSense package that does what you described for us less knowledgeable users.
Thanks for the help.
-
@eidi First, thanks for this guide, and a little shame for PIA for not offering something like this themselves, as other VPNs are more than happy to oblige.
But I'm not able to get it to work, probably due to ignorance.
I did as you did and spun up a VM to the configuration OK, but there are some things missing from your guide that I can't fill in the blanks myself.
EndPoint: somePIA-FQDN.com:1337 - This wasn't visible in my config, endpoint was an IP, I assume that's okay?
outbound NATs on pfSense - That's something I have done for openvpn, but for wireguard, there was no interface created automatically (probably because the wireguard package is new?)
So I created one myself using the address parameter from my config file as a static IP:
[Interface]
Address = xyzneed to configure a new gateway - Then of course there's no gateway automatically created, so I did exactly the same thing there, but the gateway IP is of course dynamic.
Then policy based routing...I did this too from my LAN rules, forcing traffic out through the above gateway.
Now, packets are routing through the above rule, but when I check my public IP, it's my ISP.
In addition, for wireguard status I've got zero TX/RX packets and 'Latest Handshake' is 'never'.Is anything jumping out at you here please?
-
If your "last handshake" for the new WG tunnel says "never", the WG connection was not properly established. Until the little handshake icon shows up in green, there's something wrong in your set up
Yes, the endpoint can be an IP address
Interface creation: yes, this process is manual --> go to Interface/Assignments, create a new interface and associate it with the new WG tunnel (in my case it's called "tun_wg2 (tun_wg2)". In the interface configuration, select static IPv4 and on the IPv4 address field, enter the IP you saw in the pia.conf file under [interface]/Address: in my initial example earlier in the thread, this was 10.1.149.3
The gateway. What you did is correct, you took the IP from [Interface]/Address from pia.conf and used it there.
The whole problem in using PIA's WireGuard implementation is that every once in a while (a few weeks usually), the IP from [Interface]/Address changes, so you need to reconfigure both your gateway and interface manually. Its a big pain in the ass!
I'm thinking about switching this whole set up to not use pfSense's WireGuard VPN client. Instead, maybe I'll create a simple debian VM with the scripts from https://github.com/pia-foss/manual-connections and use this VM's internal IP address as a gateway in pfSense (so the VM becomes a router). I think at least with this set up, the WG client should auto manage the occasional change in the IP, and I can have some watchdog script in the VM reconnect if it detects the WG tunnel is no longer working for some reason. But this will take time, I'm not very familiar with linux scripting
-
@eidi thanks again dude.
I might hang up my gloves on this one.
Sounds like I'd fare better offloading wireguard to a 'router on a stick' with better WG support from PIA, similar to how you're doing it. -
@ctuchik In case you still want to do this, I found the permanent solution to the problem. Instead of trying to have pfSense's wireguard client establish the WireGuard connection to PIA, if you run pfSense in a virtualized environment like proxmox or ESXi, you can easily create a linux VM with two network interfaces whose only purpose in life is to establish the VPN session with PIA and serve as a gateway for pfSense. That way, PIA's scripts work out of the box in the way they're supposed to, and for pfSense your linux VM is just another WAN interface for practical effects. It was quite easy to create the linux vm, I used a distribution based on Debian called DietPi which is super slim and I give it less than 1GB of RAM, 2 virtual processors, and it can easily sustain 700mbps down and up with PIA's WireGuard connection active.
With this approach, even if stuff changes in PIA's side, their scripts handle the disconnect / reconnect in the correct way.
-
@eidi Nice one thanks.
I do have proxmox and strangely, I have also deployed dietpi a few times before haha!
Are you me? :)I don't know if I mentioned it, but my workaround was to make 4x openvpn clients, then make a gateway group.
I was aiming to use this as a patchwork to the lack of openvpn 3 threading, but it turns out it's increased my anonymity greatly by presenting a constantly shifting public presence. -
-
@eidi @ctuchik: I got the DietPi setup and have it connected to WG with PIA. I am only getting 400 mbps on a 1gbps line.
My questions is.-
I have 2 NIC where the WAN is connected to PFSense. So that means the DietPi are getting IP address from PFSense DHCP Server then connect to PIA not directly with WAN network but through PFSenses WAN.
If I create 2 NIC in ESXi for DietPi, 1 for LAN, 1 for WAN, won't it create a problem with 2 VMs getting each WAN IP? -
And how do I get my endpoints to point to DietPi?
-
-
@Bjur I personally didn't get very far with the WG box, though I have done it in the past.
You would set your default gateway via DHCP to ensure traffic goes through the WG connection.
You would make sure that the traffic out to the Internet from the WG box is directly out, if it's got to go via pfSense itself.I run my hypervisor behind the ISP's router, while that's probably super inefficient, it does mean I can make as many gateways as I please.
-
@ctuchik Thanks for the answer.
I'm not sure I follow.
When you set you default gateway, it's normally just an IP address like 192.168.1.1. What do you mean setting it via DHCP?You would make sure that the traffic out to the Internet from the WG box is directly out, if it's got to go via pfSense itself.
So in Esxi I should dedicate a WAN interface to DietPi and still have the WAN interface also on PfSense?
-
@Bjur So, I think maybe we misunderstand each other?
Are you asking me how you set the default gateway for hosts on your LAN?
Because if you are, that's typically allocated by the DHCP server (Services > DHCP Server > Other DHCP Options > Gateway)If you mean pfsense' gateway, I'm not sure exactly of your unique setup?
What most people do to route traffic to the right place is make a PASS firewall rule for traffic from a particular place (like the IP of the dietpi box maybe) and under advanced options, specify the gateway you want the traffic to take:
For what it's worth, I just gave up bothering with PIA - I've moved to mullvad because they have an excellent self-written guide on setting up wireguard with pfsense.
It's reasonably fast too, compared to openvpn - I'm getting about 5-10x the speed, which still isn't near my uplink max, but far superior still. -
https://www.wundertech.net/how-to-set-up-wireguard-on-pfsense/
https://www.reddit.com/r/PFSENSE/comments/lmv1cp/how_to_setup_wireguard_on_pfsense_252102_with/
https://www.youtube.com/watch?v=CXFbEbzFEXw
https://www.paolotagliaferri.com/create-wireguard-vpn-tunnel-with-pfsense-2-5-0/
https://coygeek.com/docs/pfsense-wireguard/ - 404
These are the links I found most helpful.
This is what my setup looks using wireguard
https://forum.netgate.com/topic/181299/surfshark-guide-for-pfsense-wireguard/29?_=1730824716743 -
P Popolou referenced this topic
-
@chuchik: What I mean is how do I get all my clients on the network (laptops, tablets, TVs to use the DietPi VM?
How do I get the traffic routed through PfSense to DietPi to Internet?
In Esxi I have 3 network adapters usable (1 LAN, 1 WAN, 1 vm). On my motherboard I have 2 physical network ports.In VM for PFSense I have (1 WAN, 1 LAN) so the ISP bridged modem goes directly to PFSense.
In VM for DietPi which Network adapters should I configure? If I select (1 WAN, 1 LAN) wouldn't that create a IP public mismatch?
What should I select in PFSense to pass it through to DietPi?
As of now I have PIA configured as a client in PfSense where it is used for alias IP addresses.
This is what I have for my firewall rules LAN:
Ideally I would like to have WG configured in PFSense, but as you wrote earlier that's not easy to have.
In regards to PIA I've signed up for some years, so I would not be ideal to switch unfortunately. It would be nice if they upped their game and made an guide to follow for PFSense.
@The-Party-of-Hell-No Thanks for the links. I've also seen Wireguard to Pfsense guides, but to get PIA to work without interruptions, that's not easy.
-
@Bjur
hello, are you still struggling with this?Not sure what DietPi VM and DietPI are? Are these the clients created to go out to your PIA VPN service?
-
@Bjur I didn't use the dietpi method so I'm not certain, I can can pick parts of your questions to try and answer but networking isn't my speciality really!
Man there's a lot of ground to cover in just a loose plan like this. Is ESXi behind another router?
Here's how I once did it with fake IPs and hostnames.
Randomserver1 = 172.16.0.10/24, Gateway 172.16.0.1
Randomserver2 = 172.16.0.20/24, Gateway 172.16.0.100
DietPi (VPN Client) = 172.16.0.100/24, Gateway 172.16.0.1
Router = 172.16.0.1/24, Gateway PUBLICIPIn this basic example, Randomserver2 gets VPN and Randomserver1 doesn't.
The trick is to configure DietPi to accept traffic on its LAN interface, I have a loose note saved like this:
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADEThe alternative here is that you have pfsense do the routing instead, that seems to be what you're trying to do, and what other are suggesting.
The above suggestion though is a router on a stick...
Maybe this helps, IDK. -
The above isn't persistent sorry, I'm working on a phone right now, to make it persistent:
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
iptables-save | tee /etc/iptables/rules.v4 -
@The-Party-of-Hell-No Yes, I am. Would be nice if there was an easy to follow guide with PIA WG + PFSense that worked persistantly.
@ctuchik Thanks for taking the time for the write up.
My ESXi has PFSense configured and the WAN port goes through an ISP router, but it's bridged so it just passed through traffic.
So the RandomServers are IP created networks on PFSense?
In ESXi where you configure networks adapters. In DietPi does it only have one network card or two? -
So the RandomServers are IP created networks on PFSense?
Yeah, like a DHCP range if you like.
In ESXi where you configure networks adapters. In DietPi does it only have one network card or two?
With router on a stick, you can make dietpi just have one interface, on LAN.
As far as your LAN design goes, it's unchanged. You don't need to give dietpi a WAN interface because pfsense won't be hosting the VPN.Maybe this diagram will help display the flow of traffic.
Again, I'm not doing it this way now, it's something I once did...and, I don't know if it's 'poor network design'. It's a workaround for PIA being shit:
