I have a MikroTik router behind CGNAT. I have enabled back-to-home-vpn on this router (router1) and have successfully configured both an android phone and a windows computer to connect to the router. I would like to configure another MikroTik router (router2) to connect to the back-to-home-vpn router using a wireguard tunnel to bridge the two LANs together.

I've tried to use WG Import function to import the wireguard configuration file into router2 for the peer that I've created on the back-to-home-vpn router1, but that fails with a parsing error. Can someone provide me a prototype, sample configuration that I can use on router2 that will allow me to successfully bridge the two LANs?

You cannot.
The BTH feature is for individual devices only ( smartphones, ipads, laptops, PCs )
If you have two wireguard devices that you wish to connect together, then,
a. change one of the ISPs so that you can get a public IP either on the MT itself or at least on the ISP modem/router where it can forward a port to your MT router
OR
b. purchase a CHR license and then a monthly subscription to the CLOUD server of your choice, lots available in the $7 per month range.
OR
c. find a friend with mikrotik router that can act like a CHR for both your routers, they will connect to the friends router and then will be able to be connected to each other.

I believe you might be able to but not an easily. First, using wg-export is wrong - that's going to replicate the entire wireguard config... While what I think you want to do is make the router2 as peer to router1's BTH.

So you need to create an additional BTH user ("shared user") via app or /ip/cloud/back-to-home-users/... And then using CLI find the new BTH user using /interface/wireguard/peer/print and "show-client-config" with a file=, replacing the <#> with line number for new BTH peer:
And download "wgpeer" from Files for import into router2.

Then on router2, copy the saved "wgpeer" file to router2's files, and at CLI use This will NOT alone bridge (or routing) between networks, but you should have a L3 connection with 192.168.216.1/24 being router1's gateway address. So if router2 can ping 192.168.216.1, the WG peer is working.

There are a few approaches to "bridging the LANs", one being EoIP using WG. Or, you may be able get by with routing if router1 and router2 are using different LAN subnets (i.e. by adding static /ip/route on each route using the remote BTH IP address as the gateway). But I'd try above "show-client-config" on router1 and "wg-import" on router2 and see if "ping" works via CGNAT.

Hmmm,,,,,,,, I suppose as long as the config contains the endpoint address and endpoint port for the Cloud relay. Manual in any case.

I have it working. I now have two MikroTik routers, both behind NAT, connected to each other, leveraging back-to-home-vpn to do so.

Here are the steps:

1) Set up back-to-home-vpn on one router (let's call it routerA) as normal. Do NOT set up or enable back-to-home on the other router (routerB).
2) As described by @Amm0 above: create a BTH Shared user on the routerA, save the WG config for that user as a file on the router and download the file.
3) Optional: You may wish to edit the file created in step 2 to remove the line that says DNS=192.168.216.1, depending on where you want routerB to look for DNS. If routerB has its own connection to the internet where it will look for DNS, you will probably want to remove this line.
4) As described by @Amm0 above: move the file to routerB and use wg-import import to import the file.
5) Manually assign the 216.X ip address that was listed in the imported file to the wireguard interface in routerB. Use a /24 address: 192.168.216.X/24. This should dynamically create a route for the 216 traffic to the wireguard interface.
6) Add an input udp accept rule on routerB for the port specified in the imported file.
7) At this point the wireguard tunnel should be up and you should be able to ping 192.168.216.1 from routerB and ping the 216.X address that is in the config file from routerA.

To actually connect the LANs behind the routers, additional steps are required:

Step 8: As configured the peer that was created in step 2 on routerA will only allow traffic addressed to 216.X to go to routerB. This needs to be changed to allow any traffic (or at least all routerB LAN traffic to get to routerB). To do this in winbox: a. Make a copy of the WG-peer on routerA that is for the shared user that you created (use the copy button in winbox after you have double clicked on that peer). b. Change the allowed address in the copy from 192.168.216.X/32 to be 0.0.0.0/0. c. Under ip.cloud in winbox find the list of back-to-home users and disable (do not delete) the user that you created in step 2. d. Now apply the change to the peer that you copied and changed in step 6b. If you try to apply the copy before you disable the user, you will get an error.

At this point the Wireguard tunnel should allow any traffic to pass between the two ends, but you need to set up routing each router so each router will send LAN traffic to the other router. The simple way to do this if you have only a few LANs is to:

9) Create static routes on routerA that will send traffic to any LANs that exist on routerB to the wireguard interface on routerA.
10) Create static routes on routerB that will send traffic to any LANS that exist on routerA to the wireguard interface on routerB.

11) Depending on your firewall configuration, you may need to allow traffic from the wireguard interfaces to be forwarded on each router. The MikroTik default forward rule blocks forwarding for a traffic not originating on the LAN. This will block all traffic from the WAN but it will also block all traffic from other, non-LAN sources like tunnels into the router. There are two easy ways to fix this: 1. add the tunnel (wireguard in this case) interface to the LAN interface list OR 2. Change the default rule that drops all non-LAN (!LAN) traffic to drop WAN traffic instead. I prefer option 2 because it "fixes" the problem for all tunnel traffic, but the firewall will still, correctly, block non-NATted traffic from the WAN.

Step #8 above is really the only tricky step. As near as I can tell, the "allowed address" field in wireguard peers is used by the wireguard interface as a type of internal routing table for all the peers on the interface. It allows the interface to route specific destination address to the correct peer. If you don't specify either 0.0.0.0/0 (or the specific LANs that you have connected the the peer), your traffic to the destination LAN will not get through the tunnel. If the destination peer is just an endpoint (computer or phone or tablet) there is no problem with the default "allowed address". If you are connecting more that one router to the main back-to-home router, you will likely need to specify the correct LAN addresses for each peer, rather than using 0.0.0.0/0 as specified in these instructions.

I dont understand the need for step 6. Router B in both BTH and normal wireguard is the client for handshake never the server ????

I dont understand the need for step 6. Router B in both BTH and normal wireguard is the client for handshake never the server ????

What you say seems correct, however I note that the BTH setup in routerA automatically added this rule (perhaps in case the router is not behind NAT?). So I simply duplicated the rule in routerB. Funny thing is, that I do see packets coming into that port on both routers with the source of the packets being the BTH cloud server (193.72.220.100) on both routers. I don't fully understand how the BTH cloud server/relay plumbing works.

What @anav here is trying to say is that the routerB is the one that initiates connection to the routerA in your case so rule on routerB is not needed as its the router himself that initiates connection and when this connection is established then it will pass the firewall.

On routerA it's needed because routerB is trying to connect to the routerA thought the internet and without that rule firewall would drop the traffic.

Good write up! Few points:

- BTH does add all the firewall stuff automatically - that's why it "easy"... while doing it "by hand" on RouterB you do have to allow the WG port otherwise it be blocked by the default firewall's drop WAN in rule.

- AFAIK, the BTH "server" run by Mikrotik, I believe, just copies the packets as recieved based on the WG dst port being used (which their server likely knows since BTH must register it when enabled). But on RouterB (non-BTH) I'm not 100% the port you use matters, but likely best to use the one defined by BTH config file.

- if one side does have a public IP... that is router where you'd want to be the RouterA running BTH - that might avoid it from using the proxy. Internally BTH on RouterA determines if a "direct" connection is possible (i.e. public IP). Mikrotik's cloud DNS will resolve xx.vpn.mynetname.com based on BTH detecting a public IP or it will use BTH proxy's IP address

What @anav here is trying to say is that the routerB is the one that initiates connection to the routerA in your case so rule on routerB is not needed as its the router himself that initiates connection and when this connection is established then it will pass the firewall.

On routerA it's needed because routerB is trying to connect to the routerA thought the internet and without that rule firewall would drop the traffic.

I agree with you and @anav. My observation, however, is that I DO get packets coming in through the rule on routerB even when it is behind NAT. I don't understand why. Perhaps there is some outbound traffic from that port that opens up a hole in routerB allowing response traffic? Anyway, I think it does not hurt to leave that rule in place.

On routerA it's needed because routerB is trying to connect to the routerA thought the internet and without that rule firewall would drop the traffic.

Perhaps there is some outbound traffic from that port that opens up a hole in routerB allowing response traffic? Anyway, I think it does not hurt to leave that rule in place.

Yup, that could be happening. It take more dissecting your config rules to know for sure - there is not actually one default configuration and /interface/list stuff matter too... I can say you'd need/want the allow filter rule if RouterB had a public IP, but if using the proxy then outbound is all that's needed.

Keep in mind BTH will also use IPv6, so if that's enabled... it's possible your WG peers are going via IPv6 too.