I fixed it, it was my mistake. For those of you who may come across this, here's what I did wrong: I set the listen port for both tunnels to be the same, if I had read all of the documentation, I would have known that they need to be unique... :)

@ddbnj Feel free to fork and modify it- I had a "StateKiller" package that I was working on to do more complex rule-based state killing / failback but I sadly never finished it. Not sure how much interest there is for that now that they added some more general purpose state killing options in the recent builds.

@luckman212 it's the same as a non bgp peer. setup bgp router options [image: 1664907772561-306a917e-13c2-44c5-8a5a-8cfada76f504-afbeelding.png] [image: 1664907793482-4f5593a5-9d1c-408b-a111-e3ff89537a9f-afbeelding.png] neighbour (target system) [image: 1664907838085-3b7f143a-26aa-4a7d-a80b-b84b9f133790-afbeelding.png] [image: 1664907879262-d72ded88-c449-4839-8cd0-86b5dcd303d9-afbeelding.png] You need to setup frr [image: 1664908023563-b943ce1a-0a31-4ebc-a4ac-6cd092f300c9-afbeelding.png] [image: 1664907980899-565fac11-b6dd-4103-8f12-0e12cd5a75ef-afbeelding.png] That's the allow all on the bgp And setup ofcourse interface and firewall rules

This is the best I could come up with for now. It's a pair of floating rules (block/quick) one for each direction (in/out). In the screenshot below, n_coresite_ext is an IP alias of the far end static IP/subnet, 51828 is the listen port on the far-end tunnel, and WAN2_RUT is my failover WAN interface (the one I do not want any WG traffic to traverse). It also helps to have wgfix.sh (github) installed. [image: 1664895848013-dbb94a9c-5fe3-47c5-96d1-cd94ce605a2b-image-resized.png]

@sgc would also love to know the quick details (dont need a super detailed writeup) of how you got your WG remote access tunnel set up with SLAAC or DHCP6

@cmcdonald thank you for the explanation. indeed the problem was my frr configuration, all is working fine now.

After really long try and error I found the cause of all the mess. It is in this case mandatory to enter a MSS into the wireguard interface. I thought its calculated automatic based on MTU so 1420 - 40 = 1380. but it is not! After entering the MSS (1380) the connection is working like charm, also with large packets and hardware offloading.

@JeGr Apropos living on the edge. [image: 1663510391633-screenshot-2022-09-18-161302.png]

Update - Running iperf3 on Windows and setting the "-w" flag to "1m" gets me closer to ~450Mbs. Now I've got to figure out how to get windows to do that by default...

So, after some further digging, I discovered a couple things. You have to actually assign the tunnel to an interface The MacOS Wireguard app doesn't support .ddns.net domains Thank you for your help, once I assigned the interface correctly everything worked like a charm.

@bob-dig It works! Thanks!

@ben9090 Good that it's working but if you want to troubleshoot the pings, do packet captures on all relevant ports to see where they're getting lost.