sonobus
sonobus copied to clipboard
sonosaurus
Use SonoBus over VPN/Tailscale
Hi,
I'm attempting to connect a MacBook Pro to an iPhone on LTE over Tailscale.
Has anyone attempted to use this application over a VPN or mobile data before? What are the best practices for doing so? It's not possible to connect using the connection server as it says there is a problem with the firewall. Would this likely be a computer-side problem or a LTE side problem, and would there be any logs for this?
I have tried using the standalone server method on port 10999 on the Mac, but it will time out on joining.
I am able to SSH into the target machine over the VPN connection from the iPhone, so the connection appears to be working
Thanks!
But, are you able to SSH into iPhone from MacBook?
LTE could be a carrier grade NAT (CGNAT) which is also sometimes referred to as symmetric NAT, in which case, I'm afraid, there is no solution. Now, throwing VPN in the mix could make it work, but it is hard to tell.
I believe you are threading an uncharted territory here. Good luck. :-)
NAT is generally a pain in the ass to deal with in P2P networking. Some VPNs do support P2P connections but your mileage may vary.
Update: I got it working fine over Tailscale on a RDP VM in US East from CA West.
Windows 10 to macOS, Stereo 256Kbps, about 30-50ms latency displayed on either side's client. Using VB-Audio Cable and ASIO4ALL on Windows side.
Were you able to get the iPhone-over-LTE working? (I'm attempting something similar; when trying with a private group I see the peer, but get the firewall message. When attempting to "Connect to Raw Address" the peer shows up in the list but with "0ch" and audio isn't transferred.)
I'm thinking that -- at least when attempting to connect directly -- if the socket described by the "Local Address" could be configured to bind on the IP address allocated by Tailscale (and/or "all interfaces"), that it might just work.
Currently, the "Local Address" appears to be using the primary network interface's IP.
Perhaps on a future update when ipv6 support is added you might have better luck when in mobile data networks.
The direct connect was only ever designed for local networks, and the displayed address will just be the primary local network, even though the sockets are bound to all interfaces.
Hi all,
I did manage to get it working, but it requires a VPN. I used https://github.com/trailofbits/algo to set one up and connected using Wireguard using the Wireguard app.
After this, audio transfer in both directions works fine on iOS.
This fix worked for me both in Canada on Fido and in the US on T Mobile (hotspot).
The latency isn't as bad as it would seem, but at times, it would drop for a second or two when on the train and moving, and sometimes I ended up having to set the buffer to a second to prevent this.
My use case for this was twofold - 1) to stream low quality music from my computer to my phone to save data with adjustable compression, and 2) to enable high quality calls on Apple AirPods. SonoBus is able to use the rather good microphone on the iPhone and the AirPods as an output device only. Thus, the quality degradation associated with the mic+headphones HFP profile is avoided. I prefer to speak into the phone's mic anyway and both sides can enjoy a call at 44.1kHz
Hope this is helpful!
Hi @larryqiann ,
Your use-case is quite similar to mine (I am also in Vancouver Canada, using Fido and iPhones/iOS). I haven't been able to connect my phones to my Wireguard endpoint running on my home router (perhaps this might have to do with IPv6; my home ISP doesn't provide me an IPv6 address); my iPhones-on-LTE cannot connect to the Wireguard endpoint, whereas they work fine when connecting to the Wireguard server from WiFi networks.
I'm curious what hosting provider you used for your Wireguard endpoint? Were you able to get it working with Tailscale? I've tried Tailscale and ZeroTier, but perhaps there is some critical factor I am missing. (it might be IPv6 related, so if I set up a different Wireguard endpoint then it might need proper IPv6 connectivity)
@essej I was thinking that the Wireguard endpoint (e.g. a VM) itself may need IPv6, so that the phone can connect to Wireguard over IPv6 (outside the VPN), and then inside the VPN Wireguard provides the device an IPv4 address that Sonobus can use.
(So the useful part of Wireguard here is bridging an IPv6-only client to a (virtual) IPv4 network.)
It's interesting that you are unable to connect to your own WireGuard setup - I used the algo script with Vultr. I was unaware that the LTE connection was V4 only, but I suppose that is possible.
@larryqiann Yeah, I'm not sure what about my home network Wireguard is not working (but I think it is a problem with my own setup of Wireguard, not Sonobus). I've used it to access my home network from work, but that was via work wifi; it probably never worked over cellular.
Now I'm attempting to set up a Vultr VM (with NixOS) for Wireguard, and I'll try a few experiments to see if disabling IPv6 connectivity to the VM matches what I'm seeing with my home network (also w/o IPv6).
Thanks @larryqiann , I was able to get it working (🎉) , by using Wireguard in a Vultr instance (and a Sonobus session between two iPhones, each using cellular).
The important parts when configuring the iPhone Wireguard config are:
- Allowed IPs
0.0.0.0/0 - Persistent keepalive
60
(keepalive needs to be set to any non-zero value). When using "Connect to Raw Address", the Wireguard endpoint doesn't need to route all traffic out to the internet, though "Allowed IPs" on the iPhone clients does seem to need to be more than just a private subnet (for example, "Allowed IPs" 10.0.0.0/24 doesn't work with Sonobus, even though the phones can successfully ping each other with that setting). Interestingly, when adding a Wifi-based laptop as a peer, it doesn't need the above settings; just using a private subnet in "Allowed IPs" and no keepalive works fine. (If you want to use private/public groups with aoo.sonobus.net, you do need to route public traffic to the internet)
IPv6 doesn't seem to be a contributing factor; I disabled it on the Wireguard VM and it still works. The Wireguard iOS app shows an IPv6 endpoint address even though I entered an IPv4 address for "Endpoint" (which I think is from the cellular carrier's 6-to-4 infrastructure).