wireguard kernel implementation

[JeGr]

> That's a feature.

I assumed it is ;) But I'm not so deep into the implementation itself to say "more logging is possible" :)

[mimugmail]

It's a killer for CARP ... enterprise integration will be low .. lower than low :)

[chemlud]

yeah, considering the nature of the beast...

https://www.wireguard.com/#conceptual-overview

... only option might be to log all packages for the FW-rule. Tried for the allow rule for the tunnel IP on the wiregurad FW-rules tab, but see nothing in live view.

PS: now I enabled logging for the allow rule on Wireguard FW-rules tab for one of the remote nets and I see the traffic flow.

But where to see these "keepalive = 10" packages? They should be going back and forth between the tunnel network IPs, or?

[JeGr]

It's a killer for CARP ... enterprise integration will be low .. lower than low :)

Ah because it binds on the interface instead of an actual IP? Makes sense, failover possibility is nonexistent that way.

[Patrick M. Hausen]

I figure the problem @mimugmail is seeing with CARP is more due to the fact that presumably a WireGuard tunnel router cannot determine if the tunnel is alive or not.

But I may stand corrected with respect to my last statement. There is this "last handshake" information, so there must be a little bit of keepalive checking, nonetheless. Possibly one can use that amount of state to force a CARP failover if necessary.

The rest can be pretty simple, IMHO, just use two boxes on both sides and two tunnels. Clients on either side throw their packets at the active node that forwards it through *its* tunnel to the other side. Provided that a keepalive check and failover is possible, there is no need to have *one* redundant tunnel as long as there is redundant connectivity.

[mimugmail]

The problem is, there is no daemon to bind an interface. So when you send a packet to the client, you cant decide if the source is whether IP of Interface or CARP IP

[Patrick M. Hausen]

Ah ... I wasn't thinking road warrior, because without user authentication and IP address pool management this is not going to fly in a corporate environment, anyway.

My idea was

Code Select Expand


              Box 1a ------------ Tunnel 1 ------------ Box 1b
                |                                        |
                |                                        |
LAN a --- CARP Address                             CARP Address --- LAN b
                |                                        |
                |                                        |
              Box 2a ------------ Tunnel 2 ------------ Box 2b



But back to the road warrior scenario.

There is not really a "client" and a "server" in WG. So the client would accept that packet from any IP address as long as the keys match. In that case the problem lies with the NAT gateway which will be in front of the "client" in most cases.

But if on the "server" side incoming packets to the CARP address are taken care of, why not NAT WG packets originating from the interface address to the CARP address?

[JeGr]

Ah ... I wasn't thinking road warrior, because without user authentication and IP address pool management this is not going to fly in a corporate environment, anyway.

My idea was

Code Select Expand


              Box 1a ------------ Tunnel 1 ------------ Box 1b
                |                                        |
                |                                        |
LAN a --- CARP Address                             CARP Address --- LAN b
                |                                        |
                |                                        |
              Box 2a ------------ Tunnel 2 ------------ Box 2b



But back to the road warrior scenario.

There is not really a "client" and a "server" in WG. So the client would accept that packet from any IP address as long as the keys match. In that case the problem lies with the NAT gateway which will be in front of the "client" in most cases.

But if on the "server" side incoming packets to the CARP address are taken care of, why not NAT WG packets originating from the interface address to the CARP address?

Or put the routes out of WG and use the wg interfaces in a FRR/OSPF Setup with both sides watching their "other side" gateway IP so if one is down (because Box1a/b/WAN1 is down) then FRR should route via #2 - AFAIR that should be possible as long as one configures the WG interface as "non broadcasting" and add a manual entry for the Neighbor using the WireGuard interface address of the appropriate peer?

[mimugmail]

Yes, there were ppl reporting to work with OPNsense implementation and dynamic routing yet, but that's not carp, if you have a clean failover strategy, dynamic routing would not solve it and it's hard to write a generic documentation on how to setup WG with HA.

I already had small success with outbound nat, but no chance to test on a ha cluster due to homeoffice :)

[chemlud]

There is not really a "client" and a "server" in WG.

Yes and no, the client is the one who has no allow rule on WAN, so he has to initiate the traffic in outbound direction to make the tunnel happen

So the client would accept that packet from any IP address as long as the keys match.

No, the receiver checks both, key and IP to identify legitimate traffic:

"Once decrypted, the plain-text packet is from 192.168.43.89. Is peer LMNOPQRS allowed to be sending us packets as 192.168.43.89?"

https://www.wireguard.com/#conceptual-overview

[JeGr]

The problem is, there is no daemon to bind an interface. So when you send a packet to the client, you cant decide if the source is whether IP of Interface or CARP IP

@mimugmail: Just a heads up - perhaps one could have a look into the patched kernel module in Netgates Redmine Thread.
-> https://redmine.pfsense.org/issues/11354
Seems the patched ko actually recognizes and respects the destination address so incoming traffic e.g. on WAN1 will be responded via WAN1, WAN2 will get answers via WAN2 and packages to CARP IP seem to respond via CARP IP. Only problem open seems that a manually demoted CARP master (that's still active otherwise) is still sometimes getting packages but the other failover scenarios look good. So when implementing the kernel module mode - that could also bring a fix for using CARP and MultiWAN - or let's say for most cases. :)

[mimugmail]

Thx, I'll have a look when Franco added the patches to Kernel :)