NAT broken after Reboot
-
I have a wokring setup of 4 Wireguard VPN gateways.
This stops functioning when I reboot my Netgate Pfsense.
Everything starts working again as soon as I add a new dummy Wireguard tunnel.
It seems related to NAT.My working VPN Gateways before reboot.
After the reboot the Wireguard Tunnels are up and running but the monitoring is failing. It seems due to NAT using wrong Destination.
On each interface the Destination should always be 10.2.0.2 but instead the un-Natted ip is used by the ICMP packet (10.2.2.2, 10.2.1.2, 10.2.4.2 etc) which is wrong
Packet capture WG_PROTON_2 for 1.1.1.1. It seems as 10.2.3.2 is not 1:1 Nat to 10.2.0.2 before going to 1.1.1.1
As I said as soon as I add a dummy Wireguard tunnel everything starts working properly again and the NAT is using the proper destination.
(working capture after dummy tunnel is added)
I thought it is maybe a problem in reboot sequence. Trying to restart VPN Wireguard Tunnel Service does not help. Only adding a dummy tunnel makes it work.
Any idea what breaks my setup at restart?
As ref these are using NAT 1:1 and Outbound
-
@iggybuddy6 how did you come up with that configuration? Have you read the pfSense documentation on configuring wireguard? There's plenty to read, for example
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/index.html
https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2ms.htmland an official video to follow also (somewhere on youtube...).
If I compare my working wireguard setup with yours, the main differences are:
- I only use ordinary gateways (not "VPN gateways", where did they come from?)
- I only use outgoing NAT, no 1:1 NAT
- each WG tunnel is connected to an interface, connected to a gateway (I can't see any interfaces in your post)
There's normally plenty of ways to skin a cat, but when it comes to pfSense and wireguard I think there's only one way: follow the documentation
Update:
this recepie is probably the best one, as it matches your setup (and mine) the best:
https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-client.html
-
@pst thanks for your answer
-
I only use ordinary gateways (not "VPN gateways", where did they come from?)
They are normal Gateways (I just called them VPN as they are bound to the wireguard interface)
-
I only use outgoing NAT, no 1:1 NAT
You are probably using a VPN provider that gives you different IPs
I am using ProtonVPN. ProtonVPN attempts to preserve privacy by using a single IP address 10.2.0.2 when you connect using Wireguard. The routing table rejects adding route collisions for multiple Wireguard connections all using 10.2.0.2/32 pointing to multiple different interfaces. Hence I can not use the "normal way" to add multiple Wireguard -
each WG tunnel is connected to an interface, connected to a gateway (I can't see any interfaces in your post)
yes I did not post the whole configurations as I thought it is irrelevant to the problem. Here are the interfaces
Sample Interface conf
As I said you are probably using a VPN provider that has different IPv4 address that you can assign to the Interface. ProtonVPN uses 10.2.0.2/32 all the time for privacy reason and that is why I am using the 1:1 NAT trick. [more here]
As you can see it is not the 'usual setup'.
Everything is working fine up until I reboot the Netgate.
Rebooting somehow breaks the NAT 1:1 on the way out. Simply adding a dummy Wireguard Tunnel makes everything work again. -
-
@iggybuddy6 ok, I'll have another think. I only tried proton once, with the free vpn offer and it's difficult to compare tunnel setups with only one tunnel. But if it is as you say, it feels like proton has shot themselves in the foot. What security aspect can they refer to? it's an interface address that gets mapped again once the packet leaves the tunnel at their end. Baffeling.
-
"The misconception that WireGuard inevitably generates logs is probably based on the fact that, by default, it requires a static (and therefore identifiable) connection between the VPN app and the VPN server. To get around this, we hardcoded our apps to begin every WireGuard VPN connection using the same internal IP address (10.2.0.2).
To allow more than two people to be connected to the same VPN server at the same time on WireGuard, we use double network address translation (NAT) to dynamically provision sessions.
This means when your app connects to one of our VPN servers via WireGuard, the first NAT will rewrite the 10.2.0.2 IP address to a random but unique internal IP address that is assigned to your session. From this point on, WireGuard works like any other VPN: The second NAT rewrites your session IP address again to the VPN server’s public IP address before it connects to your desired website."
wireguard-privacy -
@iggybuddy6 yup, just found those pages...
-
@iggybuddy6 said in NAT broken after Reboot:
Hence I can not use the "normal way" to add multiple Wireguard
You can. Just don't use 10.2.0.2. Use 10.2.0.3 and so on. And use that IP also as the gateway. -
@Bob-Dig
How do you mean? The VPN provider tells what the Internal IP address is. If proton always uses 10.2.0.2 I can not simply choose another IP.I do not think you ever tried to add multiple Proton VPN connections to your pfsense.
I think we are diverging a bit from the real issue. As I said my setup is working up until I restart the Netgate. After that I need to add a fake Wireguard tunnel to make it work again. Something is off with the behavior ... -
@iggybuddy6 There is another approach suggested in that reddit thread, a comment by CounterI four months ago: https://www.reddit.com/r/ProtonVPN/comments/127zpbe/comment/mi1mq2x/
They ended up not doing 1:1 NAT but added another set of interfaces and NATed those
(you better read that comment)Maybe that is a cleaner solution?
(fwiw, I've reached my daily goal of learning something new every day
) -
@iggybuddy6 said in NAT broken after Reboot:
I do not think you ever tried to add multiple Proton VPN connections to your pfsense.
You are right, I must have confused this with another VPN-Provider. I am using OpenWRT-VMs for all my Proton-WG-tunnels.
-
@pst I will definitely check this. Thx a lot for pointing that out!
-
@Bob-Dig Sure np.
I was thinking a high level details NAT debug after after reboot and after fixing the problem adding dummy tunnel would trigger an answer pointing me to some known behavior and fix -
@pst I have tried a couple of wireguard connections using that alternative method and it seems to be working without the need of NAT 1:1 !!!
It looks good so far after rebooting. Thank you so much for pointing out that comment. I have spent so much time and this definitely should make the setup more reliableYou saved me so much time and from a massive headache I can not thank you enough
-
@iggybuddy6 I'm just happy I could help. Today I went from thinking I knew everything about setting up wg on pfSense, to realising I did not, and that is a great reward in itself!
Hopefully your setup will remain stable going forward.
