I’m trying to better understand the Back to Home function. I might want to use a similar setup elsewhere, and want to know better how it is implemented.
I copied this example BTH configuration for a WireGuard Client:
[Interface]
PrivateKey = Iabcdefghijklmnopqrstuvwxyz012345678901234I=
Address = 192.168.216.2/32,fc00:0:0:216::2/128
DNS = 1.1.1.1,8.8.8.8
[Peer]
PublicKey = //////////////////////////////////////////8= # Actual key in every config
AllowedIPs = 0.0.0.0/32
Endpoint = a01234567891.sn.mynetname.net:49876 # BTH Router "WAN" IP
PersistentKeepalive = 15
[Peer]
PublicKey = Yabcdefghijklmnopqrstuvwxyz012345678901234Y=
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = a01234567891.vpn.mynetname.net:49876 # Relay IP
PersistentKeepalive = 15
My first question is about how the Endpoint IP addresses change with BTH configured behind a NAT. Even though they have different domain names in configuration, when connecting, both endpoints end up with the same IP address!
My second question is how to force relay mode. So far, the NAT hole punching works very well, and I haven’t been able to force relay mode to work. Any suggestions for how to force relay mode for testing?
I will re-phrase the questions, and add some detail. The use case is VPN access to remote locations.
1.) How do the endpoint IP addresses not match the domain names after connection?
The configuration that MikroTik provides for a Wireguard configuration for the remote device includes two different domain names. Here are examples with example IP addresses:
a01234567891.vpn.mynetname.net # Relay IP 203.0.113.10
a01234567891.sn.mynetname.net # BTH Router Public IP 198.51.100.10
The names would resolve to specific IP addresses. However, when actually connecting with the WireGuard program, both Peer Endpoints change from their respective domain names to the IP of the BTH Router Public IP. Why doesn’t the second Peer Endpoint keep the Relay IP address after connecting?
2.) How to force relay mode?
When connecting remotely over BTH, the connection is supposed to be either a direct connection from your device back to the BTH router (Remote Device ↔ BTH Router), or a connection through a MikroTik server acting as a relay (Remote Device ↔ Relay Server ↔ BTH Router). So far, none of my testing requires the Relay. What chance can I make to ensure the relay server is used in the connection path?
If you have a public IP and can run 'normal' wireguard, it makes little sense to me to use BTH.
To answer your question the relay and router first check for a direct path, and if there is the relay is not used as priority goes to an existing public WANIP.
In this example, the BTH router does not have a public IP, but the domain name automatically configured resolves to the public IP that you NAT through.
Yes that is normal for how IP Cloud works. It shows the public IP associated with internet connection, even if your router is not the one with the public IP.
The endpoint uses DNS, which MikroTik will either resolve to router public IP (direct mode), or the IP address of MikroTik BTH relay server (relay/proxy mode). So the a01234567891.vpn.mynetname.net:49876 in example could resolve to either, depending on if BTH on router detects a public IP and open port, and then BTH/router will register the public IP (or lack of one) with MikroTik's DDNS backend for the vpn.mynetname.net address. While DNS result has a short time-to-leave (TTL), and WG "client" will recheck DNS for x.vpn.mynetname.net name when TTL expires. So the peer connection go down for some period between switch modes, since TTL has to expire (and connection needs to be detected as down). The MikroTik BTH like detects this quicker (see below).
This section, I believe, more of a heartbeat for the MikroTik app that attempts to create a direct connection to the router. IDK but perhaps used by app to also do detection of a direct reverse path to router. Note it uses a01234567891.sn.mynetname.net which is always the public IP detect by "normal" DDNS. And 0.0.0.0/32 is, essentially, an invalid IP so it cannot be used for routing, but does bring up a WG connection (which can be used to know if direct path is successful).
No, or at least not easily. You can insert another actual router between your internet to cause a double NAT. This is easier for ISP/business with extra IPs, since test router can use a public IP, and then disable it and connect via a "normal" production LAN to cause a double NAT. Now that obviously be pretty dramatic if you have only one IP, since you'd have to move it to another router just to test BTH (and need a 2nd router).
Perhaps you can "mess" with NAT rules to cause a double NAT, somehow, but IDK off top of my head how. Another thing, maybe, that trigger proxy mode is blocking port(s)...but less sure that work since port still have to work via proxy and/or blocking cloud2.mikrotik.com also stop it from registering BTH too.
This part I have not test well. But believe there is hidden middle option in BTH where the port used BTH WG get punched through a CGNAT. So the proxy server is only used to cause the open port, but since port is open through the CGNAT, WireGuard can be direct, without a public IP on router. So in OP case, this seems be the mode being used since public IP does not match router IP & yet BTH is going direct. And also means normal WG likely cannot work since there is no process that is doing the "hole punching".
Finally, keep in mind the *.vpn..mynetname.net (or *.sn.mynetname.net) can be IPv6 address (AAAA in DNS), which may have a direct path, which could be used by BTH/WG too.