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.
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.
Statistics: Posted by ddejager — Fri Jan 10, 2025 1:08 am