SmartUnlink for VPN connections

Mike-VA3MW

SmartUnlink

Make your FlexRadio visible over VPN connections

The Problem

If you've ever tried to use your FlexRadio remotely over a VPN, you've probably run into a frustrating issue: SmartSDR can't find your radio.

This happens because FlexRadio uses a discovery system that broadcasts special packets on your local network to announce "Hey, I'm here!". These broadcast packets work great on your home network, but VPNs typically don't forward them. So when you're connected via VPN from a remote location, SmartSDR sits there searching... and searching... and never finds your radio.

The Solution

SmartUnlink solves this problem by running on a computer at your remote location (where SmartSDR is running) and broadcasting those discovery packets on your behalf. It tells SmartSDR "there's a FlexRadio at this IP address" - and suddenly your radio appears!

https://github.com/brianbruff/SmartUnlink?fbclid=IwY2xjawOtBJVleHRuA2FlbQIxMABicmlkETFKWUVQWHVqY21hREExTHpEc3J0YwZhcHBfaWQQMjIyMDM5MTc4ODIwMDg5MgABHlQy3eEbbLeg7Bwc7eywVjZXlHgAWRIlCs1blfTB6N3Sw2adBf2KonuxBDZR_aem_0dDkVNmvBcBM3LLzmpdSZA

Trucker

That is a nice solution. A friend of mine will be happy to hear about this.

Thanks for posting.

James

WD5GWY

Mike-VA3MW

Make sure you thank Brian! (I couldn't find his callsign)

reed

Seems like a lot of work. Why not just allow the user to manually declare an IP address in the radio discovery pane?

Mike-VA3MW

FlexRadio's canned answer:

At this time, we do not have plans to allow SmartSDR to support direct IP addressing.

The primary reason is security. Enabling direct IP access would require users to open non-secure ports on their firewalls, which creates a significant risk of exposing the radio’s control port to the public internet. That scenario makes radios an attractive target for bad actors and is not something we are comfortable encouraging or supporting.

For users who require direct access, there are well-established VPN solutions that solve this problem correctly and securely. Options such as SoftEther and similar VPN technologies allow full, direct network access to the radio while maintaining proper encryption, authentication, and firewall protection.

We understand the desire for flexibility, but protecting customers and their stations from unintended exposure has to remain a priority.

reed

Is downloading and running third party code, which is outside of FlexRadio's control, not a potential vector for "unintended exposure" on the customer's station? The network configuration is identical in both scenarios (3rd party IP spoofing vs native support). FlexRadio is endorsing this solution, so the network setup aspect isn't be the objectionable part. I don't see why native support is a hard "no", despite it solving the exact same problem using the exact same method: a user-supplied IP.

Mike-VA3MW

That is a fair question, and you are correct that security always involves an element of trust somewhere in the chain.

The key difference is where that trust is placed and how broadly the exposure is created. With a VPN, the user is explicitly choosing to trust a specific piece of software whose sole purpose is to create an encrypted tunnel with authentication and access controls. The radio is never exposed directly to the public internet, and no FlexRadio service ports are opened to unsolicited traffic. From the radio’s perspective, the connection behaves as if it were on a private LAN.

Native direct IP addressing would require users to open and forward control ports on their firewall. In practice, many users would do this incorrectly or incompletely secure it, even with warnings and documentation. Once those ports are open, the radio becomes directly reachable by anyone who can find it. That is a fundamentally different risk profile than a VPN, even if the end goal of connectivity looks similar on the surface.

You are absolutely right that running third party software requires trust. The distinction is that this trust is intentional, limited in scope, and well understood, whereas exposing a device control port to the internet creates ongoing unintended exposure that cannot be meaningfully mitigated by the application alone.

We are not saying VPNs are perfect or that trust is eliminated. We are saying that placing trust in a mature VPN solution is a far safer and more controllable approach than encouraging users to expose radio control services directly to the internet. That balance is why native direct IP support remains a no at this time.

Mike VE3CKO

I had used SoftEther in the past that had seen the radio on the network and opened up SmartSDR no problem, used it remotely without issue. I have not tried it for a few years and it does not work now. Using SmartUnlink does broadcast and I can see the radio on the remote laptop and it does connect to the radio, however there is no stream passing see below, what am I missing ?

Lasse SM5GLC

Big Thank You to EI6LF Brian! It works great, even with my ancient 6500 :)
Have to admit no tunneling yet, but the discovery packets do work!

reed

Mike, would FlexRadio consider manual IP address support for the intranet IPv4 blocks? 192.168.0.0/16, 172.16.0.0/12, and 10.0.0 0/8 aren't publicly routable, so there is no added exposure risk for manual entry, but it would be very handy for solving this sort of problem.

Lasse SM5GLC

@Mike VE3CKO my bet is the UDP-stream is not working due to closed ports! Not sure if you can open those, all depends on your provider, or could be in your router.

But having the Smartunlik s/w allows the use of all sorts of simple tunnels not having to find one that supports layer2 i.e. discovery packets.

Mike-VA3MW

@reed Not likely, but I will pass on your request. Part of this answer is related to higher priority items being worked on. AKA, just not enough time and given that there valid solutions with VPNs, etc. it won't be a priority (just telling it like it is).