Hi everyone.
I would like to install a redundant setup at one of our most critical locations. This location is connected to a Wireguard server in the cloud (so it initiates the connection as client).
What I would like to do: Triggering the Wireguard starting script as soon as an appliance detects a state-change to MASTER as well as triggering the Wireguard stopping script as soon as an appliance detects a state-change to SLAVE.
In this setup, both appliances (MASTER and SLAVE) would use the same Wireguard configuration with just one of both being active.
Can anyone explain (a bit in detail) how this can be accomplished? Due to the stateless nature of Wireguard I think this would be pretty easy to implement - at least much easier then setting up active-active redundant tunnels with routing protocols, multiple paths and stuff.
Any help is very appreciated.
Best
qdrop
WireGuard itself can not select the source IP which sends the packets.
Lets say unit 1 has 192.168.1.50, unit 2 has 192.168.1.51.
2 VIPs, 192.168.1.1 and 192.168.1.254.
WireGuard will always reply with the highest IP, there is no binding to an IP as the connection is stateless.
You have to report this feature request to WireGuard directly (did this couple of times).
Quote from: mimugmail on September 04, 2020, 02:12:01 PM
WireGuard itself can not select the source IP which sends the packets.
Lets say unit 1 has 192.168.1.50, unit 2 has 192.168.1.51.
2 VIPs, 192.168.1.1 and 192.168.1.254.
WireGuard will always reply with the highest IP, there is no binding to an IP as the connection is stateless.
You have to report this feature request to WireGuard directly (did this couple of times).
Thank you very much for your response!
hmm, it should not be a problem at all if one client dies and another picks up it's configuration. I can do the same manually: Having the identical Wireguard configuration on two clients. The first is activated (wg0 active) and the second is deactivated (wg0 deactivated). I then unplug client 1 and just start Wireguard on client 2 with a command (wg-quick up...) - no problems.
Bear in mind: In our configuration, both clients are effectively Wireguard clients; none of which has Wireguard exposed as a server.
As far as I'm aware, the Wireguard server will always respond to the IP from which the last packet originated, right?
To clarify: There is no need for an active-active redundant configuration.
I'm looking into ways to cope with hardware-faults: If one gateway dies entirely, how can we make sure the second one starts the Wireguard tunnel automatically?
Best
qdrop
Quote from: qdrop on September 04, 2020, 04:10:34 PM
As far as I'm aware, the Wireguard server will always respond to the IP from which the last packet originated, right?
No. Just try it .. add some virutal IPs in different ranges and from an endpoint set the different IPs.
It's stateless, the operating system will choose the highest one (depending of it's networking stack).
Quote from: mimugmail on September 04, 2020, 04:48:19 PM
Quote from: qdrop on September 04, 2020, 04:10:34 PM
As far as I'm aware, the Wireguard server will always respond to the IP from which the last packet originated, right?
No. Just try it .. add some virutal IPs in different ranges and from an endpoint set the different IPs.
It's stateless, the operating system will choose the highest one (depending of it's networking stack).
So I just tried said setup.
- I have two OPNsenses with their own different public IPs (without virtual ones - not necessary / one via Fiber, one via 4G.) and configured them in a HA-cluster (with just a virtual IP on the LAN side).
- I then configure Wireguard similarly on both OPNsenses. On one it's activated, on the other it's deactivated.
The clients behind the HA-setup are now properly connected to the cloud via the Wireguard VPN using the primary node.
The (currently manual) failover-procedure goes as follows:
- I disable Wireguard on the primary node.
- I enable Wireguard on the secondary node.
- Now I switch the CARP-status from the master node to maintenance mode.
The clients behind the HA-setup are now properly connected via the Wireguard VPN. I can also revert back to the primary node doing the same without any issues. On the Wireguard-Server, I can see how the endpoint changes its IP.
So maybe there was a misunderstanding. But in my opinion, my brainchild should still work: I want to automate the activation / deactivation of Wireguard according to the CARP IP state (master / slave).
I'm aware, that this will mean, that when failing over (or back), we will lose states and the VPN will go down couple of seconds. But considering that I'm mitigating a hardware-failure that ain't a problem for me.
I'm open for a remote session to demonstrate how this is working... ;-)
And as always: Any help is still highly appreciated.
Best
qdrop
QuoteSo I just tried said setup.
I have two OPNsenses with their own different public IPs (without virtual ones - not necessary / one via Fiber, one via 4G.) and configured them in a HA-cluster (with just a virtual IP on the LAN side).
This is not a real CAPR HA setup ...