Feature #11302


WireGuard XMLRPC sync

Added by Viktor Gurov 9 months ago. Updated 7 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:


It would be nice to sync WireGuard configuration and automatically set it to 'disabled' state on the secondary node
as a semi-automatic VPN backup

Related issues

Related to Feature #11354: WireGuard should respond from the address used by peerResolvedPeter Grehan02/01/2021

Actions #1

Updated by Jim Pingle 9 months ago

  • Target version set to CE-Next

Might be tricky since if it was allowed, it couldn't be assigned, or else we'd have to code around allowing it to be assigned and disabled since the interface wouldn't exist when disabled and that would lead to an interface mismatch.

I could see it being more viable for remote access style setups than for site-to-site.

Actions #2

Updated by Christian McDonald 9 months ago

I've been really running wireguard through it's paces and I have some thoughts concerning this.

So I have a typical two-node HA cluster and thinking about remote access setups using wireguard. Out of the box, if you point your wireguard remote access clients at your WAN VIP, you won't get traffic. Likely an issue with NAT on egress as the tunnel traffic would appear from the WAN interface IP not the CARP VIP, so the crypto blocks it (I presume). It would be handy to have a few settings though in the WireGuard Tunnel GUI that might make this type of setup easier.

1. Have a checkbox for XMLRPC Sync on a per tunnel basis.
2. Have a drop down for egress NAT address for the wireguard tunnel.

So presumably if you were syncing tunnel configuration between two firewalls, and you also paired it with an automatic NAT rule (based on number 2), for using the WAN CARP VIP for NAT'ing, you could theoretically have a highly available remote access VPN, and the state failover is just handled by who holds the CARP VIP at any given time.

Actions #3

Updated by Jim Pingle 9 months ago

As a general rule, anyone using HA would not be using Automatic Outbound NAT -- they would be using Manual Outbound NAT. So hooking anything automatic into that process isn't viable. Examples of appropriate outbound NAT rules could be added to documentation for using WireGuard with HA.

There are three main scenarios to consider:

  • Site-to-Site WireGuard tunnel
    • Would need outbound NAT to force the source of traffic to appear to be the CARP VIP when initiating traffic to a remote peer
  • Remote Access WireGuard "server" for multiple remote peers
    • Might need outbound NAT To nudge it to use the correct VIP when responding to clients, but otherwise shouldn't conflict.
  • Remote Access WireGuard "client" to a VPN provider or similar
    • Might need outbound NAT to force the source of traffic to appear to be the CARP VIP when initiating but it depends on what the remote end expects.
    • Depending on the use case, for example, XMLRPC could be disabled and each node could have its own keys, remote side could have two peers, etc.

Site-to-Site and "client" roles would cause a conflict as they would still attempt to send traffic out from both nodes and packets would still get to the remote side, but responses would all go to the node whose VIP is set to MASTER. This would at best confuse the remote end and at worst cause traffic to fail as both nodes attempt to send traffic.

I'm not certain how best to solve that yet, but it needs some thought and testing. Could maybe have the CARP up/down script do an ifconfig up/down on the interface so it's configured and present but not used, though I'm not sure how viable or stable that may be.

Actions #4

Updated by Jim Pingle 9 months ago

  • Related to Feature #11354: WireGuard should respond from the address used by peer added
Actions #5

Updated by Jim Pingle 9 months ago

After testing this for a while in several different configuration styles, it's not viable yet. NAT doesn't help, at best it sort of works but won't fail over. For the time being, it's better off without XMLRPC and with a tunnel built to both nodes. Use dynamic routing of some sort to handle the failover.

See #11354 for more details on what needs to be addressed for this to function.

Actions #6

Updated by Jim Pingle 9 months ago

Until the other issue is addressed, I have noted the limitation here:

Actions #7

Updated by Jim Pingle 7 months ago

  • Target version changed from CE-Next to Future

Also available in: Atom PDF