It's a while ago now. Can you guys confirm it will be fixed in the mentioned version, any news?Supposedly fixed in 7.15beta6.
There is also a workaround if you modify the logging rules to numb down those messages but in my book these shouldn't even be displayed (it's debug, not info)
still occuring BTH iOS and 7.14.3; checked 3d agoFixing what specifically? Abundance of Wireguard logs? That was already fixed
It's not in the `/wireguard/export` because it's "dynamic config" (i.e.configuration generated by another RouterOS option). And dynamic config is never in an export – think /ip/dhcp-client and /ip/address/export. So like elsewhere, "/wireguard/print detail" is what's needed to "see" BTH stuff. And /ip/firewall/.../print etc. too. Basically you'll see more "D" items from BTH in a few places.Okay understand I may be looking at a BTH setup incorrectly done on an Ops MT router and thus the missing export info?
You'll find the BTH users on the IP>Cloud window, from there you could delete the usersI already have several working Wireguard connections, but I also wanted to try this function.
Since then, I have a dynamic entry that can no longer be deleted. How can I remove it?
Thank you,
v 7.15.3
-faxxe
Create screenshot from Winbox or Webfig.How do I create QR codes from a standard setup ( hole punch not required ), that I can whatsapp to remote devices for them to ingest??
In documentation is stated "...create a new configuration from scratch" :), even it is possible to create peer QR code as in my screenshot example, that was why @anav is wondering why such possibility is not documented.iOS configuration
Download the WireGuard application from the App Store. Open it up and create a new configuration from scratch.
What?Regarding "GOAL", why mix manual WG setup with BTH app? Better to have ability to export/share configuration of such peers (from manual WG setup) in MT mobile app (not BTH) or in Winbox to have ability to save QR image without need to create screenshot, to use as configuration import into official WG client mobile app.
Well, the share link returns HTML that requires JavaScript. So if FB tries to "unfurl" (e.g. click the link, to summarize content for a message stream), the BTH link is only a redirect to the App Store with no HTML body - and FB may not like a link that leaves the app or needs JavaScript to render...i was trying with facebook messenger.
teams , whatsapp and messenger - all working
<html>
<head>
</head>
<body>
<script type="text/javascript">
var userAgent = navigator.userAgent || navigator.vendor || window.opera;
if (/android/i.test(userAgent)) {
window.location.replace("market://details?id=com.mikrotik.android.freevpn");
}
else if (/iPad|iPhone|iPod/.test(userAgent) && !window.MSStream) {
window.location.replace("https://apps.apple.com/us/app/mikrotik/id6450679198");
}
else {
window.location.replace("https://mt.lv/bth");
}
</script>
</body>
</html>
Much thanks for these efforts!Regarding the TOPIC
We have updated the manual with the Share function info (APP side) https://help.mikrotik.com/docs/display/ROS/Back+To+Home
Did you look in /ip/cloud/print (first BTH user), or /ip/cloud/back-to-home-users/show-client-config XX (2nd or more BTH users)?Trying to understand BTH some more.
Is this correct??
Bizarre that I cannot do this FROM or AT the router ?????
The docs aren't entirely clear, but the "share" ones should have QR codes in RouterOS under IP > Cloud > Back-to-Home User. And if you created a share on the phone, the WG peer config will be there. If you use the "New" in the /ip/cloud/back-to-home-users in winbox to create new BTH users, while you'd pick a key when you do it that way & since winbox isn't a phone, it cannot forward it directly via SMS/email/etc - but the "new" in winbox do same as app.Hi Ammo reading the docs there is only one qr/code one can generate from the router itself, the rest if I read this right, is that you can easily create and manage additional Qr codes and send them all from the admin smartphone.
The docs aren't entirely clear, but the "share" ones should have QR codes in RouterOS under IP > Cloud > Back-to-Home User. And if you created a share on the phone, the WG peer config will be there. If you use the "New" in the /ip/cloud/back-to-home-users in winbox to create new BTH users, while you'd pick a key when you do it that way & since winbox isn't a phone, it cannot forward it directly via SMS/email/etc - but the "new" in winbox do same as app.Hi Ammo reading the docs there is only one qr/code one can generate from the router itself, the rest if I read this right, is that you can easily create and manage additional Qr codes and send them all from the admin smartphone.
Now, I might not be understanding the problem. And agree docs are entirely clear about the QR codes for 2nd/"shared" users: https://help.mikrotik.com/docs/spaces/R ... me-IPCloud
But under IP > Cloud in winbox should have QR code for the main user and shared users from app.
But you can try in winbox, or via CLI too:In other words, the router itself can only generate one setup via BTH, the rest have to be done from the Admins smartphone.
Just waiting for NORMIS to confirm!
/ip/cloud/back-to-home-users/add allow-lan=no comment="2nd user - added from RouterOS" name="$[/system identity get name] 2nd user"
:delay 2s
/ip/cloud/back-to-home-users/show-client-config [find name~"2nd"]
/interface/wireguard/peer/print
/interface/wireguard/peer show-client-config [find comment~"2nd"]
Except I'm not wrong. All BTH are just WG peers, and have QR codes. So just like any other peer, don't use the same peer twice. The advice to first one (/ip/cloud), applies to the shared ones too (/ip/cloud/back-to-home-user) - don't use them twice as they have an IP address assigned in peer's client config.anav:1 ammo:0 ( but whose counting)
The peer is created by BTH app when initially shared, it has nothing to do if the end user "accepts" or uses it. The shared peer will appear under /ip/cloud/back-to-home-users once shared.I also understand that once folks have accepted the qr code on their smartphone app, or wireguard client app (laptops), etc. the results show up on the associated MT Routers IP Cloud tabs ( users ) and can be configured further if required ( add access to subnets, delete, and probably other options ).
Now here we agree. :)Now if we can just crack the Routing BUG and wireguard with multi WANs.........
Perhaps describing how it works "under the covers" might help these questions in the future. AFAIK, from RouterOS and WG client, BTH is still just a WG peer - just with DNS name that MAY use Mikrotik's custom "WG proxy" server & some dynamic firewall rules based on /ip/cloud/back-to-home-users allow-lan=.The back-to-home-users menu is a new menu, this is why some of the documentation is conflicting. We will fix that.
Disagree, the only thing in common is that they use the same wireguard interface.It's WG, so all are peers. The app and /ip/cloud just always create ONE peer upon enabling it. If you need more, you need the "managed shared" (or /ip/cloud/back-to-home-users). On the "shared" ones, there is the additional option to allow-lan= so that the only difference AFAIK.
So there is actually no difference from a shared user/peer (if allow-lan=yes) and the "MASTER" one.
Now I get the confusion. The thing is you can use a normal WG client app with the BTH config from /ip/cloud/back-to-home-users, and it work the same as for the 2+ BTH peers.The ROUTER initiated client peer, ( the one that should go on the admins smartphone ) can, via Managed Shares, create additional peer clients to the same router. The client peers (second created to infinity) CANNOT create additional peer clients.
They are not equal.....
That why the app is more confusing. Yes, BTH is also a wireguard client too - beyond it role to configure BTH. So, yes, the shared ones don't need the router user/password. But the provisioning step can always be done with "Create New" in app - which is where you need router user/password to do. Now how the app works is not the hill I'm going to die on, so could be slightly off –as I said it's MORE confusing than winbox/CLI - at least to me.Not sure what you mean. If a user (not admin) uses the BTH app to setup a BTH tunnel after receiving the QR code, or URL link or export config file generated on the admins smartphone, then the user access is done through the BTH app, not the standard wireguard app.
Nope. It should work, or at least that's how I use a BTH "shared user" on my Mac. And just retested with cut-and-paste client config from the "2nd BTH" user CLI shown. which was actually my 3rd user ... so it got automatically assigned an 192.168.216.4 / ::4 - since the default values will automatically use the next greatest IP with BTH subnet.Now what has not been explained at least to my knowledge and not in docs, is what happens if I take that QR code (a user generated by Manage Shares ) and try to import into the regular plain wireguard app. Me thinks its proprietary to the MT BTH setup and thus would not work on the ordinary wireguard app.
Assuming you were NOT already using the "Main"/MASTER client on your phone already. Otherwise, you'd need to hit the "Back to Home User" button in IP>Cloud to get the 2nd++ "peer".do the dirty deed by using the QR code generated in the BTH VPN WireGuard Tab selection ( identical to /ip/cloud/print ( this entry is meant to be used when only a single user presumably admin is involved ).
Can we agree to blame Mikrotik's docs? :)You know its very annoying that your right ;-)
On firewall, there is an address-list named "back-to-home-lan-restricted-peers" in /ip/firewall/address-list that get dynamically added by BTH code on RouterOS If "allow-lan=no" in /ip/cloud/back-to-home-users.I am working on that bit ( improving docs ) and is why I am being nitpicky in my understanding.
I forget, where do the firewall rules show up that allow a USER to access the WAN and possibly the LAN???
BTH also adds a NAT rule just by enabling BTH for the 1st peer:0 D ;;; back-to-home-vpn
chain=forward action=drop
src-address-list=back-to-home-lan-restricted-peers
out-interface-list=LAN
1 D ;;; back-to-home-vpn
chain=input action=accept protocol=udp dst-port=25297
0 D ;;; back-to-home-vpn
chain=srcnat action=masquerade src-address=192.168.216.0/24
/ip/cloud DDNS being enabled is required for BTH. And they use an additional DNS FQDN per router for the endpoint <sn>.vpn.mynetname.net. And that's what's used as the "Endpoint" in WG config. The value of the *.vpn.mynetname.net name is EITHER a public IP detected by /ip/cloud's DDNS, or if DDNS detects a NAT then DNS name resolves to Mikrotik BTH reply.Hmm, let say that ROS device WAN access at certain point is changed, goes behind CGNAT or oposite while BTH WG configuration is already shared, then in such case shared configuration becomes invalid? Assuming that shared WG peer endpoint is set in config to host depending when shared configuration is made, it doesn't seem flexible for LTE mobile routers (in some cases WAN access can be behind CGNAT or not if MO SIM is changed...). I would love to see plain text config for shared WG peer from QR to understand this, don't have BTH setup on my router to check...
# Name = bigdude 2nd user
# CloudDDNS = xxxx0a11yyyy.sn.mynetname.net
[Interface]
ListenPort = 51820
PrivateKey = AbcdAbcdiroehZ7kxlFj52qGrzAZogUk3kllvAbcd=
Address = 192.168.216.4/32, fc00:0:0:216::4/128
DNS = 192.168.216.1
[Peer]
PublicKey = Zxywo/62fHo/pe0g1JFdEkNZTHhZxywLdF+2ZxywFhz=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = xxxx0a11yyyy.vpn.mynetname.net:25297
PersistentKeepalive = 30
[Peer]
PublicKey = //////////////////////////////////////////8=
AllowedIPs = 0.0.0.0/32
Endpoint = xxxx0a11yyyy.sn.mynetname.net:25297
PersistentKeepalive = 15
That I was assuming when I wrote previously that DDNS host IP is changing depending on public access and it makes sense to work like that to have WG endpoint available in any WAN access case. Thx for clarifying and config sample.The value of the *.vpn.mynetname.net name is EITHER a public IP detected by /ip/cloud's DDNS, or if DDNS detects a NAT then DNS name resolves to Mikrotik BTH reply.
I know it does switch, but not sure the exact timing. I'd imagine it follows the value ddns-update-interval= under /ip/cloud to update if DNS name uses replay/proxy or direct, plus the DNS TTL — but I did not explicitly test this. I do know it will switch modes, and the WG clients don't care, other than not working while the DDNS is updated/expire-from-cache.
Yup. Just WG peer, with special DNS name.So in summary, its transparent to the end user, and hence why both apps can be used.