Can someone please explain (in simple terms) if there is any benefit or reason one would set up BTH is one already has a Wireguard vpn set up?

Thanks.

BTH is for the scenario where both ends of the MT tunnel do not have a publicly accessible WANIP ( either on the MT device, or can port forward from the upstream ISP router )

I think I understand.

In all locations I have ever worked at, there has been a public IP -- FIOS, Cable, cell phone.

Do you mean an environment where access to the WAN router is not available, so that ports cannot be opened or forwarded?

This sounds like desktop remote control solutions where the application on the desktop establishes a connection to a remote server and the remote client establishes a connection to the same remote server, and that server facilitates the remote client remotely controlling the "home" machine.

Basically a cloud server operated by Mikrotik, connects the two ends, so that they can punch out of a connection they have which is not public and reach other.

Basically a cloud server operated by Mikrotik, connects the two ends, so that they can punch out of a connection they have which is not public and reach other.

Well the other benefit to BTH, even with static/public IPs, the Mikrotik BTH apps (for phone/desktop) automatically create the peers from the username. BTH will ONLY use the Mikrtoik's cloud if a direct connection isn't possible.

If you already have WG setup and working, BTH ain't going to help anything. BTH is more like the VPN version of QuickSet.

Thank you guys!

The technical benefit was well explained above, but another benefit (does not apply in your case) is that BTH is easy to set up, if you do not know how to configure Wireguard and would like to avoid learning RouterOS. BTH app does it in a few steps, all you need is the router password. No need to connect to router with Winbox or anything else. App does it all for you,

The technical benefit was well explained above, but another benefit (does not apply in your case) is that BTH is easy to set up, if you do not know how to configure Wireguard and would like to avoid learning RouterOS. BTH app does it in a few steps, all you need is the router password. No need to connect to router with Winbox or anything else. App does it all for you,

I think this is a very very big benefit.

While I have worked very hard over the past couple of years to learn what I know about RouterOS, I still have only a very very basic understanding. It has been fun and rewarding, but I am certain there are many people who would prefer an easier path.

While we're talking about easier paths, do you think it's possible to make an easier VLAN solution for RouterOS? I have tried multiple times, with the great help of the guys here as well as tutorials and videos, and still can't make it work for me -- I'll be there are many others like me.

...... all you need is the router password. No need to connect to router with Winbox or anything else. App does it all for you,

@normis
Very nice ..... but this does beg the security question

Is the BTH app Open Source?

Winbox is also not open source. What is your point?

Winbox is also not open source. What is your point?

With WireGuard users have control over every aspect .... With BTH, users deligate control over to BTH .... I prefer that users have compl;ete control over the process.

Yes you make a good point regarding Winbox but at least here users can choose the CLI over Winbox .... from a security standpoint TRUST is a very difficult proposition ... that is my point.

BTH app uses Winbox protocol to connect to your router and to apply configuration, which you can fully read yourself. It is not magic. It simply helps user to do the same thing you can do with Winbox. If in doubt what config is applied, just connect to router when BTH app is done and see the /export

I prefer that users have compl;ete control over the process.

It has also a "sharing" feature that the person with router password creates another peer. These additional "BTH users" (e.g. WG peers) can be managed by admin in winbox/CLI.

But still more config wizard to create peers & you can see the config it generates in WG so nothing is hidden as @normis points out.

The only thing different in BTH is Mikrotik's WG proxy to deal with restricted NATs. But that is NOT used if one end has an open port (e.g. a static/public IP).

But still more config wizard to create peers & you can see the config it generates in WG so nothing is hidden as @normis points out.

BTH is an excellent idea for the home users ....
@Amm0
For BTH -- From a security perspective the only way to find out exactly what is hidden or not hidden is to connect the Tik Router to a Hub [not a switch] and have Wireshark view the actuall process then you can know what is and what is not. The very same for Winbox and the very same for routerOS actually .... Trust is a very difficult proposition as stated earlier .... the very same thing can be stated for any other brand name Vendor incluing CISCO, JUNIPER etc ....

My questions have to do with the bloat created by BTH.
Clearly it works also if one has at least one publicly accessible WANIP.
People are using it and ending up with Peer (Server for handshake) allowed IPs that contain 'extra' information such as endpoint address and endpoint port etc.......

Creates cleanup work, more than anything else.
(1) Thus I wish somehow that when NOT actually using BTH punch through, or as AMMO states MT proxy VPN, the extra entries on the Peer (server for handshake, would not be entered in the config).

(2) I am also waiting to see on next ver release ( to see the effects of :

- *) wireguard - added option to mark peer as responder only;
- *) wireguard - fixed performance issues showing QR code;
- *) wireguard - do not attempt to connect to peer without specified endpoint-address;
- *) route - rework of route attributes;

My concern, verified with others, is that when mangling incoming WAN2 connections for wireguard using the backup WAN.
The mangles are ignored as traffic response can be seen from WAN1.
One has to either:

Create a routing rule with Source of WAN2 IP address , and force all such traffic to table pointing to WAN2.

OR, even sneakier,

Dst-NAT traffic to dst-port=wireguard-port dst-address=WAN2, to-address=WAN1 *****

++++++++++++++++++++++++++++++++++++++++++++++++++++++

If paying attention this means the Router is originating traffic and seemingly not conducting normal response to traffic during the handshake, as the mangles are ignored ( routing rules dont use mangles either, so that is not a factor for routing rules )
but the non-marked traffic coming out of WAN2 is being captured by the routing rule!

The reason we see responses out of WAN1, without any intervention, is that although the wireguard traffic is coming from the correct interface (WAN2), its originated not responding traffic and thus although it comes from WAN2, it hits normal routing table main rules, where WAN1 is the primary and thus goes back out WAN1.


++++++++++++++++++++

****** The sneaky dst-nat method basically says to the router anything heading to WAN2 on that port dst-nat to WAN1. Thus any traffic attempting to leave WAN1 for that port would get un-dstnatted back to WAN2 on the way out.

++++++++++++++++++++

Attempting to understand the logic??
a. persistent keep alive setting being the problem ( not the case - ruled out by removing from all players )
b. the wireguard is attempting to send some payload back to the peer ( maybe the case? ).
c. BTH bug where the Server Peer continually attempt to re-establish or connect to client peer, outside of responding to handshake solely!!!

Create a routing rule with Source of WAN2 IP address , and force all such traffic to table pointing to WAN2.

OR, even sneakier,

Dst-NAT traffic to wireguard port to WAN2, to-address=WAN1

This has come up a few times.... Maybe @normis/etc can comment on it somewhere. Although it's WG, not BTH specific. WG+multiwan just doesn't align with the packet flow diagram, so it's difficult to say what's right.

No one has proven to me its not a BTH bug. Why else would the router attempt to initiate traffic (not properly respond to incoming traffic, thus bypassing mangles ) from the Peer (Server for handshake )? The only two things I can think of are.

A. BTH traffic in the background.
b. Normal conversation between peer and client where both seek to ensure they know the others Public IP addresses. This normally should not interfere with establishing a tunnel connection though.

Built-in Roaming
The client configuration contains an initial endpoint of its single peer (the server), so that it knows where to send encrypted data before it has received encrypted data. The server configuration doesn't have any initial endpoints of its peers (the clients). This is because the server discovers the endpoint of its peers by examining from where correctly authenticated data originates. If the server itself changes its own endpoint, and sends data to the clients, the clients will discover the new server endpoint and update the configuration just the same. Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data. Thus, there is full IP roaming on both ends.

Initially, the only real bug discerned or more accurately, an incomplete implementation that prevented that roaming, was the inability of the Peer ( client for handshake ) to re-establish a connection if the Peer (Server for handshake) WANIP changed or was unavailable for a length of time. The persistent keep alive timed out and the Peer (client) stopped trying to establish the connection (gave up) and thus work arounds were developed to keep trying. Fixed by MT around 7.12 or so ????

I think this is done in linux by the wg-quick wrapper app, or something similar.

@anav [this Alias is easier for me to remember]
I do Agree with you that you have discovered a BTH bug …. Traffic originating on wan2 should return to wan2 ….. surprised that MikroTik have not commented on this behavior…. RouterOS must honor WireGuard Routing Behavior….

Well mozerd there are two different things at play here.

The connection coming in to the Peer ( server for handshake), on WAN2, getting marked connections, should then result in return traffic from the wireguard module, also with marked connection and go out WAN2.

IF there are NECESSARY BTH connections ORIGINATING from the router, then this must be clearly documented to the users, so that we know how to deal with such traffic, mangle the outbound or routing rule the outbound traffic.

What should NOT happen, is BTH programming interfering with Normal Traffic meaning:

a. NON BTH configurations
OR
b. BTH configurations where the Peer (server for handshake) has a public IP and has no need to punch out to the proxy MT WG server.

b. BTH configurations where the Peer (server for handshake) has a public IP and has no need to punch out to the proxy MT WG server.

I'm not sure how BTH would interfere with other WG config. BTH with a "real" public IP would still use DDNS, but still does not "punch out" a ports – just a BTH peer uses snXXXX.vpn.mynetname.net instead of the WAN address directly. But "native" WG can also use DNS names too. In both case, it what's resolved as the address from DNS that matters. If /ip/cloud does NOT say "behind a NAT", a proxy will NOT be used (or at least it shouldn't) - e.g. BTH is same WG, just with DNS as peer address for clients (to preserve the ability to use a proxy WITHOUT adjusting peer configuration if later the BTH router's WAN changes to CGNAT or something).

I do Agree with you that you have discovered a BTH bug …. Traffic originating on wan2 should return to wan2 ….. surprised that MikroTik have not commented on this behavior…. RouterOS must honor WireGuard Routing Behavior….

The issue really come up ONLY in multi-WAN where both WG and BTH variant can run into SAME trouble if mangle rules are used for multiwan routing.

In some ways, WG is actually "OVER following" the Linux native "routing behavior" — which is to use routing rules to establish peers. i.e. using "mangle" for routing is a more specific RouterOS thing that arguably "interferes" with WG native routing selection logic.

Still issue is limited to only if the mangle rule result in selection on non-main routing table, where there does seem to be an issue BOTH WG or BTH. But if you're NOT using mangle rules, there is NO "bug".

100% agree be good if Mikrotik comment on this since it come up in quite a few thread.