SmartLink in the world of CGNAT, or: any difference between LAN and WAN?

AI7JP

Carrier-Grade NAT, CGNAT, is becoming very common and is largely being used due to IP address exhaustion. I have 3 ISP options, fiber, local WISP, and StarLink. All three use CGNAT exclusively for IPv4 and provide IPv6. Because this CGNAT/IPv6 world is the unavoidable future, I'm quite curious what the official solution is going to be for this from FlexRadio, and would love to hear their input so that those of us in this situation know what to expect.

The suggested method to work around this is a VPN, allowing the client to virtually appear to be on the same network as the radio. This works fine and is easy to set up using a bounce/relay server. My question about this method is if the network load is different between a "local" and "remote" connection. Does the radio work to limit the bandwidth in specific ways when it knows it's talking to a remote client? If it does *NOT*, then a VPN bounce server is perfectly acceptable and there's no reason to ever involve SmartLink at all as the client will always be "local" to the radio.

However, if the radio assumes that LAN traffic can support higher bandwidth, this will lead to some serious issues.

I'd love to know an official answer to this so we know if there's any difference between being VPN'd into the "LAN", or being a "remote" client.


===================
Assuming there is a difference:

One fairly simple workarounds that works with most protocols, which don't seem to work with SmartLink, is to use a VPN and a bounce server and route all the radio's IP traffic through the server in the cloud. This makes it appear from an IP perspective that the radio's public IP is that of the bounce server, off in the cloud. However it looks like the SNAT/DNAT on the bounce server doesn't really work because an inbound TCP/4994 packet is received, but the radio returns an outbound UDP/4993 packet which the bounce server has no idea where to forward to.

Another solution that would work would be to build a VPN client (wireguard, maybe openvpn) into the radio so that it could dial itself out to a user-provided bounce server.

Or a setting on the radio to treat specific LAN IP's as remote devices so that VPN'd in devices could be treated as remote.

Of course, all this is irrelevant if it's well understood that there is not now, nor ever will be, a difference in how the client app and radio treat LAN and Remote connections, in which case we can all happily use a VPN to pretend to be on our local network and disable SmartLink entirely!


Would love to know the answer to this so that we can work to architect the correct solution!

Ha Gei

I recommend using a L2 VPN.

I , and others had good experience with softethernet . Not too trivial to get it up, but seems to be best alternative.

There are other VPN´s with OSI L2 support, but not free and sometimes related to specific routers/isp´s

No OSI L3 routed VPN will work with SSDR as far a i know up to now.

Harry

AI7JP

It could certainly work, but would definitely lead to poor performance if the communication protocol treats "LAN" devices differently from remote devices.

For example, if you use a Plex server to stream video it might stream full 4k quality across your LAN to TV, but limit to 720p quality when streaming across your WAN connection. You could break this by using a VPN and getting your 4k quality, but your video isn't going to play because you don't have enough upload bandwidth to support 4k over the WAN.

What I'm curious about is if the FlexRadio is doing anything like this, which would mean the difference between WAN and LAN is important and using a VPN as you suggest will lead to less than ideal performance.

Mike-VA3MW

I wrote this up as a white paper 3 months ago.

There are ways to get it to work, but you may not like how well it works.

CGNAT Network

73

AI7JP

Prefix: Sorry if this comes off as snarky, it's not meant to. I'm a software developer and in fact genuinely curious, but after re-reading what I wrote I realize the github-issue-discussion style communication may not come across correctly for this forum. Mea Culpa, but here we are anyway:


Ahh, there's what I was looking for right there, thank you! The following quote from the article answers my question:

> When we use SmartLink it has different software to handle longer latency connections responsible for longer response times. Over a VPN like this, SmartSDR does not think it is on a long-haul routed network.

So, with confirmation that SmartLink has a different mode for "local" vs. "remote" connections, the question is what's the solution FlexRadio is planning for the inevitable future where more and more of us are on CGNAT?

I see a couple possibilities personally:

1) IPv6 support. Although this only solves the problem partially as some ISPs aren't going to support that either, for unexplained reasons that can only be attributed to malice. ;-)

2) Allow setting specific clients as "On a VPN". Using something like this would allow you to use the proposed VPN solution for connectivity, but set a software flag to signal that you're actually on a long-haul routed higher latency connection and make use of the code that expects such a connection.

3) Re-engineer the SmartLink system to do NAT busting using a STUN server. TailScale has a good writeup on how they do this in their case: https://tailscale.com/blog/how-nat-traversal-works/
(Works so well it seems like magic most of the time!)
This is probably the best solution from a K.I.S.S perspective for the user, and it would be interesting to know if it was technically viable, or if there was something really unique about the FlexRadio network traffic that would prevent it. This, I suspect, would also be the easiest as it could take advantage of the existing SmartLink higher-latency-expected code.

In any case, CGNAT is here to stay in the IPv4 world, and a proper solution is going to be required at some point, and knowing what the FlexRadio roadmap was to this solution would be very helpful! (Of course, knowing that there was no future solution and that we'd never be able to really effectively use a flex radio over a CGNAT connection would also be helpful to know, and at this point seems to be the default assumption.)

AI7JP

I suppose there's also an option 4) outsource the CGNAT busting VPN entirely, and embed something like ZeroTier into both the radio and client software, which would also be transparent to the user experience.

Mike-VA3MW

All good ideas.

Let me ask, if you were a CGNAT / SmartLink customer, would you pay for the solution and if so what would you pay for an annual subscription?

(I'm just thinking out loud and don't draw any conclusions from my comments). :)

AI7JP

An interesting question. I may not be the best target audience for that question as I'm *NOT* a K.I.S.S. user. As someone experienced with both software development and networks I'm a little more judgemental about /how/ things are done when I decide if I'm willing to pay.

Personally, I'd be irritated if I had to pay for a solution when I'm 99% sure that you could add a "treat client as remote/long-haul client" and allow me to use my existing road-warrior VPN configuration for free. But that's just me. :smile:

Although I'd probably be happy to pay a little bit to support the rather minimal bandwidth requirements for you to maintain a STUN server to help set up the direct client<->radio communication. $10 *maybe* $20 per year.

Hawk75

> @Mike-VA3MW said:
> All good ideas.
> Let me ask, if you were a CGNAT / SmartLink customer, would you pay for the solution and if so what would you pay for an annual subscription?
> (I'm just thinking out loud and don't draw any conclusions from my comments). :)



After moving to a location where it's the only option, I've investigated, researched tried to learn the ins and outs but as we all know, time is very valuable and in short supply.

If there was a fee associated with a reliable solution to overcome CGNAT, I personally would subscribe.

-73 Andy