pfSense with multiple Proton WireGuard tunnels
-
Has anyone had any luck following Proton VPN guide for incrementing IP and DNS/Gateway IPs for multiple WireGuard tunnels in pfsense.
https://protonvpn.com/support/wireguard-configurations (instructions middle page)
I can get the first tunnel setup using the 10.2.0.2 and 10.2.0.1 but if i try to add a second tunnel(different port/configuration etc) using 10.3.0.2 and 10.3.0.1 the gateway is down.
I have talked with Proton support and they confirmed this should work and they provided me with the ports they use for WG.
I have setup multiple WireGuard tunnels with another vpn provider without issue on the same system.
I have done a sanity check with a wireguard client on windows and the incremental adjustments work, although the client app can't run simultaneous connections.
I have been researching this for days and Proton support sent me packing.
Thank you for your time.
Edit
I don't know what happened but the second tunnel have come up and it is working . I don't have an explanation sorry. -
@0Blaster0 said in pfSense with multiple Proton WireGuard tunnels:
I don't know what happened but the second tunnel have come up and it is working .
I have seen the same, it is really strange.
-
All tunnels have suddenly gone down. Tried recreating them and they stay up for a couple minutes and stop working. I would steer clear of using proton wireguard configs. I'm done fighting with this...I'll just use Mullvad which has been rock solid on pfsense.
-
Just went through this last night and have 6 tunnels running.
In my circumstance it was having all wireguard peer endpoint ports to be set to 51820 and the other port settings are more flexible providing they do not conflict with others.The MTU and MSS settings of 1420 in the Interfaces configuration.
NAT in manual mode
I added "static routes" in the /System/Routing/Static Routes/ config page, which was a copy and paste of each wireguard peer end point ip and the drop down menu pointing to your WAN.
I added the "Use non-local gateway through interface specific route." option in the advanced section of each wireguard tunnel in the /System/Routing/Gateways/, (bottom of page).
That is what got me up an running. Hope it helps.
-
@wardex said in pfSense with multiple Proton WireGuard tunnels:
I added the "Use non-local gateway through interface specific route."
Why was that needed in the first place. Maybe give some more details how you configured the interfaces.
-
@Bob.Dig It might not have been needed at all, it was a long night of skipping a groove on the 51820 peer end point port, something that I should have figured out while I was creating the second tunnel.
After the tunnels were up I started seeing crosstalk between the interface and the wrong subnets on my firewall. Added the static routes and then added the associated "IPv4 Upstream gateway" to the Interface config in the "Static IPv4 Configuration" section, incremented my subnets 10.x.0.x/29 and proceeded to the "Use non-local gateway" section for a click.
Works well so far.
-
@wardex A Screenshot of one interface would be nice, maybe details matter.
-
-
I did some more testing on WireGuard with Proton on pfSense and came to the conclusion that pfSense's Gateway Monitoring is the culprit. Maybe Proton is doing some IDS/IPS(?) on the tunnels and this triggers it immediately.
I wish pfSense would in general offer two presets for Gateway Monitoring, one for local gateways and one for remote ones.
Back to Proton, If you set a gateway on your WireGuard Interface in pfSense, it gets immediately monitored and all traffic will be blocked by Proton it seems. One way to avoid that is to set the gateway to the same IP-Address as the WireGuard-Interface itself (/32). With that, there are no pings going through the tunnel and the connection works, tested by routing some traffic through it. Now I can set monitoring however I want, it will work too. For how long, I don't know yet.
So the problem only exist right when the tunnel is created and no traffic has passed yet, gateway-pings will be the first.
One way of avoiding the problem would be to not use gateway monitoring at all, but I don't like that idea.
Maybe it only needs to be reduced but to what degree. -
Can you not just set a monitoring IP that does respond consistently?
-
@stephenw10 The problem seems to be the initiation, if the tunnel has transferred data and not only ICMP, it does work. Let's see for how long.
-
said in pfSense with multiple Proton WireGuard tunnels:
Let's see for how long.
Until today. I had to restore from an Image-backup because I ran into yet another WireGuard-problem on pfSense.
After the restore, which was from early morning this day, two of the three proton-tunnels where offline. The only way to make them work again was to disable Gateway-Monitoring, then pushing some data through them (already worked). Then I could re-enable Gateway-Monitoring and everything is fine. I even rebooted pfSense and they all still came up.
Interestingly, if I use my OpenWRT-Router-VMs instead of pfSense for the tunnels, I still do the Gateway-Monitoring with pfSense and there is no problem at all...
-
Hmm, weird. If you have gateway monitoring enabled and it's failing then, by default, pfSense will exclude that gateway from policy routing, But hard to see why it wouldn't work unless Proton is doing something unexpected.
-
I've been using 3 Proton tunnels via wireguard on pfsense for about a year with no issues. I do have gateways set up for each tunnel. For the gateway monitoring I have been using the public IP address (the Endpoint IP provided by Proton's config file) of the Proton server the tunnel is connecting to.
-
@Bob.Dig
When I look at your link, It appears you are using the same subnet 10.3.9.0/x on all your gateways? That could be a problem I would look into.My setup increments the Gateway ip's to their associated interface:
Gateways
PROTO_SEA_1 - 10.2.0.1
PROTO_SEA_2 - 10.3.0.1
PROTO_VAN_1 - 10.4.0.1Interfaces
PROTO_SEA_1 - 10.2.0.2
PROTO_SEA_2 - 10.3.0.2
PROTO_VAN_1 - 10.4.0.2and of course the "IPv4 Upstream gateway:" is pointing to the appropriate gateway in the Interfaces settings.
The only settings in my Gateway config are the Interface name, Gateway name and the private Gateway IP of the remote gateway 10.2.0.1 or 10.3.0.1, etc.
The Gateway monitoring defaults to the private gateway ip and works fine.
Hope it helps. :)
-
My interfaces and gateways follow this as well:
@wardex said in pfSense with multiple Proton WireGuard tunnels:
Gateways
PROTO_SEA_1 - 10.2.0.1
PROTO_SEA_2 - 10.3.0.1
PROTO_VAN_1 - 10.4.0.1
InterfacesPROTO_SEA_1 - 10.2.0.2
PROTO_SEA_2 - 10.3.0.2
PROTO_VAN_1 - 10.4.0.2Here's a screenshot of my interface and my gateway for one of the subnets:
Note the following in the gateway screenshot:
Monitor IP: I use the Endpoint IP provided in the Proton Wireguard Config file.
Static Route: I had to check this to get it to work. With it unchecked a packet capture shows the pings going out via 10.3.0.1 but there were never any replies received on the interface. A packet capture with it checked stills shows the pings going out via 10.3.0.1 and results in the replies being received. I don't know why it would not work with a static route but dpinger still seems to be correctly binding the pings to the correct interface even when it is checked. Maybe @stephenw10 has some words of wisdom here?
Use Non-Local Gateway: I enabled this per Proton's directions (https://protonvpn.com/support/pfsense-wireguard)
Also note that I do not have any static routes setup at System|Routing|Static Routes.
Good luck, I hope it helps!
-
Do you have /System/Routing/Static Routes/ configured with each peer endpoint IP pointing to your WAN?
Edit: What I meant to ask is why don't you have static routes pointing to your WAN? I would try to add the static routes and then try it without the "Do not add static route for gateway monitor IP address via the chosen interface" and see if the Gateway monitoring works without using the endpoint IP.I forgot to add that I have the "use non-local gateway" also checked in the Advanced section of the Gateway configuration. my bad.
-
@wardex said in pfSense with multiple Proton WireGuard tunnels:
Edit: What I meant to ask is why don't you have static routes pointing to your WAN? I would try to add the static routes and then try it without the "Do not add static route for gateway monitor IP address via the chosen interface" and see if the Gateway monitoring works without using the endpoint IP.
I struggled with getting it setup with multiple tunnels for a long time. I could not get anything to work. I can't remember everything that I tried at this point but I'm pretty confident I tried to manually set the static routes and was not able to get it to work.
But I did get it to work with the settings in the screenshots so I just stopped there. At this point in time it isn't broke so I haven't wanted to "fix" it.
But that is an interesting question. I would think having the Static Route unchecked in the gateway's setting would do the same thing as manually binding the interface to the WAN via System|Routing|Static Routes. I could be wrong but that's my current understanding. But regardless, it appears that dpinger does the binding to the interface as it shows all the pings going out the interface.
As to monitoring to the Endpoint IP that's just a personal choice. I tested the 3 tunnels for about 4 months with the with the Gateway Action checked in the Gateway's settings so that it would not mark the gateway as down if the monitoring failed. Any time that the monitoring failed a quick check of the tunnel status showed that the connection between the peer and the server was also down. So wasn't just some lost pings. I have never once has a situation where the monitor failed and the peer and server were still connected. So I'm very confident that Proton's servers are a reliable source for the monitoring.
-
@dma_pf said in pfSense with multiple Proton WireGuard tunnels:
I would think having the Static Route unchecked in the gateway's setting would do the same thing as manually binding the interface to the WAN via System|Routing|Static Routes.
I believe the setting "Do not add static route for gateway monitor IP" in the Gateway configuration appears to allow dpinger access outside the tunnel interface.
But If you set static routes in System/Routing/Static Routes/ for all the tunnel interfaces, uncheck "Do not add static route for gateway monitor IP", leave "Monitor IP" blank, dpinger will use the Gateway ip's, 10.2.0.1, 10.3.0.1, etc. and fire the pings through the tunnel. This works really well with PROTON, I have been working 9 tunnels with this configuration.
-
Guys, most of the stuff you do makes no sense and the HowTo on Proton's site isn't 100% correct either.
@wardex said in pfSense with multiple Proton WireGuard tunnels:
When I look at your link, It appears you are using the same subnet 10.3.9.0/x on all your gateways
No, I don't, please read more carefully.
The problem has something to do with gateway-monitoring on pfSense. You can tackle this multiple ways (disabling it in the beginning) but sadly there is no perfect solution to this.
