Remote via VPN Challenge

KY6LA_Howard

Now that 1.4 is alive and well......

A few months ago we had a conversation about using VPN for remoting..

https://community.flexradio.com/flexradio/topics/has_anybody_tried

but it was pretty clear that DAX was going to be a bandwidth hog and somewhat of a PIA

BUT Remote LAN works great on 1.4 and by my limited testing does not seem to be a bandwidth hog...





NOT WANTING TO REINVENT THE WHEEL!!!

George KF2T Asked:

Anyone gone the VPN route and have success stories to share?

A bridged VPN from home LAN to the world is sounding really good with 1.4 coming soon.

Any service provider recommendations, or other advice?


Someone has to have done it already????

Please share!!!!!!!!!!!!!!!!

Larry Loen WO7R

I will see in a day or two how it goes with 1.4.  But VPN is not a significant issue on my 1.3.8 setup. 

As you may recall from other threads, I took a pair of commercially available routers, flashed them with OpenWRT, and installed a utility called tinc.  Tinc takes care of having each router find each other and ALSO establish a VPN connection between them, all automatic.  Thus, no port forwarding, not much muss or fuss really.

I run the remoterig solution today for CW and SSB audio, plus the "speaker" output.  I also run TightVNC to control the remote PC.  As far as I can make out from basic utilities like "top", VPN is not a big contributor to the CPU load on either router.  So, it can't be contributing much to latency either, other than whatever it takes to put a minimum encrypted packet together plus any pacing overhead.  But, I doubt very much.  Note that no DAX flows over the internet with this solution.  But, TightVNC replaces that load.

Perhaps by coincidence, my data load is about 275 k bits per second, which the reference thread suggests would be the case with a true remote with 1.3.8's DAX.  That's well within both system's capabilities as far as raw data rate goes.  Remote Shack's ISP is supposed to provide 2 megabits up, 3 down and home is supposed to be ten down and one up.

I do notice occasional dropouts on audio throughout the day.  Sometimes it gets bad.  While I don't quite have the tools to prove it, I notice it is strongly correlated with the early evening and some weekend times, when a heavier overall load is being placed on my ISPs by other users simply by being home from work.  And, sometimes minor tweaks in bandwidth help substantially.  So, my strong suspicion is that it is a queuing effect, not latency per se.  If it was real latency, it wouldn't come and go like that.

I am strongly tempted to continue to run the SmartSDR locally for at least RTTY based on these experiences even with 1.4.  I also sometimes run CWX (taking advantage of local LAN) instead of the remoterig solution (which is a local CW key that is somehow streamed) when I start to get lots of dropouts.  CWX isn't perfect because of some TightVNC glitches (not SmartSDR's fault, here) but it can get the job done in the face of dropouts as long as I can hear "enough" of the pileup.

I am eager to start the 1.4 experiments and also to see what I can do to "tweak" the bandwidth requirements so as to bring SmartSDR to the "home" side of the system.  It would be nice to mostly if not entirely dispense with TightVNC and its bandwidth, depending on how much I am able to actually run SmartSDR locally.

But, given what I currently think should be a similar or greater bandwidth to my 1.3.8 setup, congestion at the ISP level is likely to remain the larger problem.

Larry

kr4k

VPN Setup description:
Local LAN: Cisco RV320 router
LAN IP space: 192.168.13.0/24
VPN client: VPN tracker 8
VPN client IP space: 192.168.11.0/32
Radio software version: 1.4.0.53
Radio IP address: 192.168.13.146
Client IP address: 192.168.11.17

From Win7 command prompt, I can ping radio:
C:Usersgklott>ping 192.168.13.146
Pinging 192.168.13.146 with 32 bytes of data:
Reply from 192.168.13.146: bytes=32 time=58ms TTL=128
Reply from 192.168.13.146: bytes=32 time=59ms TTL=128
Reply from 192.168.13.146: bytes=32 time=97ms TTL=128
Reply from 192.168.13.146: bytes=32 time=96ms TTL=128
Ping statistics for 192.168.13.146:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 58ms, Maximum = 97ms, Average = 77ms

Using PuTTy on the remote computer, entering the radio's IP address, I can telnet into the radio and issue commands without an issue. All appears normal.

The problem is the requirement for Cisco VPNs to not have the same address space as the LAN address space. Thus, SmartSDR v1.4 running on the remote computer will not "discover" the radio because it will not see the discovery UDP broadcasts.

Need to be able to specify the IP address of the radio to make this work.

Suggestions?

Tim - W4TME

Your VPN needs to be configured in bridge mode if that is possible with the hardware you have.

Ric KV1W

What am I missing ? Why can't we just set up remote access with port forwarding in the routers ?

I suppose the Flex 6500 would need a way to find it in the first place, but after that it is only a matter of bandwidth and that is now much better. But heck, I could even manually find the remote IP so the radio would not have to do the DNS stuff. but we still need a way to give the radio the IP.

What clever schemes can be "invented" or applied on this one ?

I am presently using Remote Rig for audio, PTT and CW and that works great, BUT the screen is thru VPN and the reduced bandwidth of the radio to remote PC wont help Screen to screen as the SmartSDR is still on the Remote PC. Reports are excellent by the way !!

Ric KV1W

Tim - W4TME

The radio is designed to only operate on a local IP subnet.

rfoust

I tried to use microsoft remote desktop to my home computer this morning from work.  It actually works decent for receive now with v1.4 (it didn't work well at all with prior versions).  I can't remember if RDP handles mic input or not so that might not work though.

kr4k

Response from Cisco about small business router family, VPN Client-to-Gateway configurations. See models:
http://www.cisco.com/c/en/us/products/routers/small-business-rv-series-routers/index.html

"Broadcasts will not be sent out over the VPN tunnel.  The only traffic that
will go from the LAN to your client is traffic specifically destined for it,
otherwise the router won't send it out.  It sounds like your presence packet
is a broadcast, so any VPN clients will not be able to see it.

Christopher Ebert - Advanced Network Support Engineer
Cisco Small Business Support Center"

Tim - W4TME

That is correct.  Our radio discovery protocol is based on using broadcast packets which is why it and the client have to reside on the same IP subnet.

Richard G7EIX

I have a Skype sked with my fellow limey in blighty for this weekend to try it with OpenVPN.

https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Richard G7EIX

Here's a more direct link to setting up...

https://community.openvpn.net/openvpn/wiki/Easy_Windows_Guide

Larry Loen WO7R

I don't know if I have this problem for me or not (I suspect it is, but will find out later today), but it's a big world out there and this sounds like a large and unnecessary restriction.  Why not allow (also) an ordinary TCP/IP connection?  You can implement a password or something if you're worried about requests from the general internet.  In any case, it's my license that is on the line here.  And, I don't see why a VPN isn't sufficiently secure.

Ken - NM9P

I know it is not as good as a VPN connection would be, but has anyone tried the new 1.4 with a simple session of Teamviewer using the Remote audio channels?  I may give it a try this evening or this weekend.  But if someone else has already done it, I would appreciate some hints.  I tried with the last version with dissatisfying results.

Richard G7EIX

We have OpenVPN in Bridge mode working from Leeds in the UK to my station here in Franklinton, NC!   Bit of network latency, but its working and he is able to RX with no issues.   Not tried TX yet - but we are working on it!

Rob Fissel

Just thought I'd let you all know that I got it working via WAN using my router's PPTP VPN server. I have a Buffalo router with DD-WRT v24-sp2 (a recent 3/5/15 build) loaded up. Enabled the PPTP VPN server, configured it, checked off "Broadcast Support" and it most certainly works. 

More of a proof of concept as I have yet to run it through the ringer. I was able to test it tonight by RDPing into my office computer from home, connect the work box back to my home PPTP VPN, and ran SSDR. Voila, my Flex 6300 showed up, and I ran it without issue. I have a nice **** pipe (75/75) to work with, so I'd imagine that most of the issues I'll face will be bandwidth limitations when connecting outside of my home.

I'll be sure to follow up once I've had a chance to really work with SmartSDR via WAN. As you all know, it's gangbusters via LAN. 

Larry Loen WO7R

Rob, what is the configuration?  Do you have separate subnets or does the VPN make everyone look like they are on the same one?

Rob Fissel

Larry, 

The PPTP VPN sits on it's own subnet, 255.255.255.255. Of course, the LAN's subnet is 255.255.255.0. 

The firmware that was factory installed on my Buffalo router was 4 years old. After a little reading and research, it was evident that even though "Broadcast Support" was an option for the PPTP VPN server, bcrelay was not part of the build. Hence it wouldn't pass UDP broadcast packets from my LAN subnet to my VPN subnet and visa versa. 

I flashed the router tonight to a newer v24 version mentioned in the previous post. I also started from scratch, doing a 30/30/30 reset on the router. Re-setup all my configurations, port forwarding, and VPN from a clean slate. It appears that this build's Broadcast Support option actually works.

The PPTP VPN server now does a good job of translating broadcast packets from the LAN over to the VPN's subnet, and all appears well with the WAN SSDR experiment thus far.

DD-WRT, like other free router firmware options, really turns your cheap router into a powerhouse. 

K6OZY

You should not use PPTP anymore.  It is a compromised solution.   Usually only found using 128-bit encryption keys, in the years since it was first bundled with Windows 95 OSR2 back in 1999, a number of security vulnerabilities have come to light, the most serious of which is the possibility of unencapsulated MS-CHAP v2 Authentication. Using this exploit, PPTP has been cracked within 2 days, and although Microsoft has patched the flaw (through the use of PEAP authentication), it has itself issued a recommendation that VPN users should use L2TP/IPsec, OpenVPN, or SSTP instead.

Knowing that PPTP was insecure anyway, it came as no surprise to anybody that the NSA almost certainly decrypts PPTP encrypted communications as standard. Perhaps more worrying is that the NSA has (or is in the process of) almost certainly decrypted the vast amounts of older data it has stored, which was encrypted back when even security experts considered PPTP to be secure.

Rob Fissel

Very much so correct. 

The only reason I've enabled a PPTP router was for proof of concept in getting WAN SSDR capability. I also have the ability to enable and disable the server as needed via my routers GUI from anywhere on the internet. I run a separate L2TP server on an OSX box within the LAN for all of my non SSDR connections. 

I have a long way to go trying to wrap my mind around getting OpenVPN set up. I am by no means an IT professional, but once I figure out configuring OpenVPN in bridge mode, I'll make the permanent move away from PPTP. 

Rob Fissel

As an update, I just used my phone's hotspot on a Windows laptop to VPN to my LAN, and ran SSDR without any real issues. Latency was up around 70ms, and SSDR's network rating dipped down to a yellow 3 bars. There were a few minor audio drop outs. This was with two panadapters and two slices open, and no DAX. This consumed about 75kpbs both up and down. 

Jay -- N0FB

Larry, that is what SSDR version 2.0 will be all about. Wide Area Network (WAN) remote capability. You from a PC will be able to log into your Flex with a password from anywhere in the world with a password. 1.4 only allows for Local Area Network (LAN) connections. 1.4 is an important step to getting WAN remote capabilities. We are all looking forward to this. Until 2.0 is released, using a VPN type of connection is the only means of directly accessing your Flex outside your home LAN.

Larry Loen WO7R

If you say so, Jay.  I still don't get why it is implemented this way, especially in 1.4.  An ordinary TCP/IP connection is not exactly new and difficult technology.  Meanwhile, I have a VPN, but apparently the wrong sort.  I don't believe I have the bridging sort.  So, my entire home network strategy has to be of a particular and (as far as I can make out) not very common sort, to make this work.  I may be able to fix mine; I may not.  But I don't get why, once you decide to take the step that Flex has in 1.4, why you don't do the (to me) obvious thing and just lift all the local/remote restrictions.  Because TCP/IP, generally, is set up to make that the norm, the default.

rfoust

Security - authentication/authorization, etc. Also, the radio sends out broadcast packets on the network so that SSDR can find it. Broadcast packets aren't usually forwarded beyond the router, so something else has to be written to get around that. And there's the whole latency issue that probably needs to be tested across the internet since internet traffic does not have the same characteristics as lan traffic. Delays/dropped packets/etc.

Thanks,

-Robbie

Rob Fissel

Larry, 

I don't think it's as simple as you make it out to be. 1.4's current iteration involves transiting a lot of data, and requires (relatively) significant bandwidth. Steve - N5AC discusses the bandwidth requirements in detail here:

https://community.flexradio.com/flexradio/topics/smart-sdr-lan-remote-working-well-over-pptp-vpn

Flex appears to have reinvented the SSDR wheel here with 1.4, issuing a major software update that begins to focus on reducing bandwidth requirements. This works fine on a normal LAN, where wired connections provide at least 100Mbps and wireless connections using 802.11n. But the bandwidth requirements are still high when it comes to transiting that data over the internet. Most people with a basic cable connection typically only have 5 Mbps upload speed. That's 1/20th of your LAN's wired speed. DSL is typically even worse. It's likely that you'll see significant performance issues with a slow broadband connection like this when trying to work WAN using 1.4. 

Just guessing, but 2.0 with WAN functionality built in will require a lot of work when it comes to cramming audio, waterfall/panadapter data, and DAX into a stream that will play nice over the internet where limited bandwidth and latency become more of an issue. They need to come up with a solution that will work reliably well on the AVERAGE internet connection. I have 75Mbps up and down, which is way above the AVERAGE speed most American's get from their ISP's. 

As you're aware, 2.0 will provide a turnkey solution, and Flex has been very upfront about this roadmap. In the meantime, the Flex community, who seems to be all about experimenting and tinkering, is making nice strides towards getting 1.4 to play well over a VPN - provided you have the bandwidth to support such activities. 

Ken - NM9P

Would the openVPN solution work on an old PC running FreeNAS? I was playing with one several years ago and might resurrect it if it would work.

ctate243

Yes there are some security concerns with PPTP and appreciate your concerns...  but the point was to show that with an enabled vpn tunnel this does work.  We were directed by flex not to turn this into a huge IT networking discussion in the community so findings were posted with minimal disclaimer.  The concept has now been proven.. and we can now all make sure our ham networks don't end up under attack from the script kiddies :-).

Larry Loen WO7R

quote --  I don't think it's as simple as you make it out to be.

Actually, I'd like to know what it shouldn't become that simple because of what I've already achieved.

First, if I do manage to implement the VPN bridge, and thereby fool the current implementation, I believe I will have all the evils of an implementation that uses an ordinary TCP/IP connection.  Bandwidth, security, you name it.  All there.  How could it not be?

Secondly, I have remote operation working RIGHT NOW on 1.3.8, just with different trade-offs.  I can't figure for the life of me why panadapter data would need to be transmitted on any scheme.  I would hope that all that is needful is for the DAX  I/Q data to flow to the client machine and have _it_ do the panadapter calculations.  I have long assumed this happens now.

Right now, I have a pretty dumb remote implementation.  With remoterig, I already move not DAX but the ordinary audio output of the rig over the wire (in stereo even, so L versus R can be dealt with).  I even move CW keying in with success.

But my current solution will also move a ton of pixels using TightVNC.  That technology, I hope, going to prove to use more bandwidth than moving the DAX I/Q stream around instead.  Now a DAX I/Q stream should have more bytes than the audio stream I now move.  But I'm hoping it would be less, far less, than the TightVNC flow.  As for raw capacity, I supposedly have two megapixels up at the shack (via wireless internet to my ISP -- this is rural) and ten megapixels down at the home side of it.  Speed tests confirm this.  Since most of the data is flowing in that direction, those are the critical bandwidths (I have one MP up at home and three down at the shack end; should be ample for my SSB audio and CW keying). 

And, in fact, I have observed this crude implementation working quite well most of the time.  Most of my dropout problems, where data is dropped, is in the evening when there is congestion.  So, the issue isn't absolute bandwidth, which I mostly get, but congestion causing packets to be delayed or dropped or whatever happens to them (I don't have the tools; I just hear data dropping and the display go jerky; I observe when it works and when I will struggle).  I can see aggregate bandwidths as they flow through my router, so I can tweak the flow.

TightVNC is very crude.  I can substantially reduce the data bandwidth by minimizing SmartSDR when I can.  Old fashioned MixW2, with its very snowy waterfall display, generates almost as much data as SmartSDR does!  Yet, I can often run both.  Sometimes, minimizing MixW2 is enough; other times, I have to minimize both or (if I need the "visuals") work around the dropouts.

Yet, most of the time, I can even work DX, rare DX, in spite of the dropouts.  I admit this takes a little practice and is a sort of kind of skill on top of everything else.  In extreme situations, I also sometimes use CWX just to be sure my heard keying is OK.

But I've been working E30FB, K1N, TI9, and the like whether I have dropouts or not.  If I can make it happen under these conditions, I'm not terribly afraid of what _should be_ a lower bandwidth solution using the existing setup or even an ordinary TCP/IP connection to get it all going more readily.

So you can see why I am mystified at suggestions that this is difficult to make work.  My setup is pretty ordinary and yet it seems to be pretty darn good now.

Rob Fissel

But my current solution will also move a ton of pixels using TightVNC.  That technology, I hope, going to prove to use more bandwidth than moving the DAX I/Q stream around instead. 

First, moving 192khz of raw I/Q data would be very bandwidth intensive. Way more so than what's currently quoted for panadapter bandwidth consumption. And way more so than what at VNC connection will typically move. Also, you'd only be limited to 192khz in your panadapater. You wouldn't be able to see an entire band. Considering we're used to being able to look at up to 7 or 14 mhz of spectrum at once, the Flex community would freak out. 

Second, VNC will not run at 30 frames per second without using a ridiculous amount of bandwidth. It also uses significant compression to move that video data across the internet. 

First, if I do manage to implement the VPN bridge, and thereby fool the current implementation, I believe I will have all the evils of an implementation that uses an ordinary TCP/IP connection.  Bandwidth, security, you name it.  All there.  How could it not be?

You are correct, for the most part. This would work, and is working for many of us. But you need a rock solid, high bandwidth, low latency internet connection on both ends to do this well. Upload speed on the Flex side dictates how well this will work. Again, if Flex were to implement this WAN feature with 1.4 as it stands right now, the community would flip out when their congested 15/5 cable internet access at home can't support remote operations. 

So you can see why I am mystified at suggestions that this is difficult to make work.  My setup is pretty ordinary and yet it seems to be pretty darn good now.

You say it works, but you mention things like TightVNC is very crude, and your display goes jerky. That doesn't sound like a solution that Flex users would be happy with in a commercially delivered product by FRS. 

You also mention that your internet access at home is 2 megapixels up. I'm assuming you mean 2Mbps up. That won't come close to cutting it right now trying to run your Flex over the internet. Especially if you scale up the panadapter FPS and add DAX audio or I/Q into the mix. 

Flex's WAN solution will take significant work, incorporating compression solutions into how audio and associated data is transmitted across the internet. The key here is finding a solution that will reliably transmit this data over the AVERAGE internet connection - AND maintain a high level of sound quality that Flex users have come to know and love. Believe it or not, 2Mbps is a slower upload speed than the average internet connection, and when it comes to WAN operation of your Flex, upload speed is king. 

It's good that you have a working solution for your needs in 1.3.8. You can also try to see if you can get a VPN solution to work with 1.4, but I suspect your ISP bandwidth limitations will significantly hamper this. 

Jay -- N0FB

Larry, there some things you might need to understand.  TCP protocol is a point to point, stateful, connection based  protocol. It requires exactly 2 connection points. You need to know the IP Addresses at both ends to start the stream.  UDP is a stateless, connectionless, broadcast protocol.  Most routers block (thank God) UDP broadcasts except for those found on its own subnet.

SmartSDR 1.4 utilizes a UDP broadcast for radio discovery.  The radio sends a broadcast of basically "Here I Am" out to the whole local LAN.  The SmartSDR software client on what ever device it is installed on listens for this broadcast.  When it hears the broadcast it strips the IP Address of the radio from broadcast and makes it available to SmartSDR.  When it is time to start a set of direct TCP stream connections for control and audio traffic it utilizes this obtained IP.   There is no way I know of to create a similar TCP Broadcast that FRS could employ. 

I'm sure the concept FRS was operating from was a "KISS" for to aid the non-computer savvy Radio Operator.  Create a software client which allows the end user to connect to the radio without needing to know its assigned IP address.  The SSDR UDP elegantly provides this radio discovery on the Local Area Network.

SSDR 2.0 will have a completly different methodology employed to allow for radio discovery and logging in. We as users can only speculate how FRS will deal radio discovery from in a WAN environment.   We'll know in time.

Essentially, Flex Radio, from a network engineering standpoint, chose the right protocol for automatic radio discovery on a LAN. Period.

Here is a links you can look from a high level which explains the difference and the appropriate uses of UDP vs. TCP protocols:  

http://www.diffen.com/difference/TCP_vs_UDP

Larry Loen WO7R

You're basically setting up conditions where I and many others will never be able to run remote. So I give up some features like 192k data streams. Flex presumably implements programmable caps. So what? Compared to "no solution" I (and many others) are not going to feak out. Moreover, my problems seem far more related to congestion, something that can happen no matter what the bandwidth. Actual bandwidth seems quite OK. All residential solutions run the risk of congestion that increases latency. No matter what nominal bandwidth we buy. If your standard is that high, we may as well give up now. I'm deliberately emphasizing my worst case. In the daytime during the week, early AM and late PM I have no trouble at all. Meanwhile, someone in this thread is reporting trans Atlantic success, a situation much more difficult than mine. So, to recap, anyone with the right VPN will have all of your problems. Some here report success with 1.4 on ordinary internet, no freakouts yet. I succeed with what could or should be an inferior answer. Maybe the flex developers can explain it. I think the remote crowd is made of sterner stuff than you think. Remote stations are pretty easy today but the are not set up all that casually once you have two residences involved. You have to want it and that implies the reality of compromise with residential internet. Higher speeds alone are not necessarily dispositive here. Congestion can be a reality pretty independent of speed. I would welcome compression and all. Remoterig and TightVNC seem to somewhat achieve that as well. However it is not quite enough when it gets congested.

Rob Fissel

Transmitting audio via a VoIP solution and basic CAT commands via a solution like RemoteRig or CommCat are completely different from this, and require very little bandwidth comparatively.

If you view the transatlantic image posted, you'll notice that the network health indicator is poor, and the latency is very high, sometimes approaching 1.5 seconds. They haven't tried to transmit yet, and wonder what level of success they'll have with a connection like that. 

https://d2r1vs3d9006ap.cloudfront.net/s3_images/1173774/RackMultipart20150317-32041-y90me1-smartsdr....

Flex developers have already addressed and outlined the bandwidth issue at length already. 

 Just a note here to explain for anyone trying this out how much control you have over the bandwidth.  The SmartSDR architecture was designed to allow a lot of control over the bandwidth between the client and the server.  Here are the components that generate network traffic and the control you have over that traffic:

1. The audio codec today has a single setting that we control that provides excellent fidelity -- we really felt that this was the last thing most folks would want to compromise and so today, you don't get to control the bandwidth here.  The codec is running at something under 80kbps for receive audio, independent of the number of slices you are running.  
2. Each panadapter consumes bandwidth based on two factors: the frame rate and the width of the panadapter.  The height does not matter.  You can reduce the width of the display and you can control the frame rate by adjusting the FPS control on each panadapter.  A typical 25FPS fram rate and a 1500 pixel width will generate about 500kpbs of data.  Slow the frame rate to 5FPS and the bandwidth will perfectly scale down to 100kbps
3. The waterfall works very similarly to the panadapter.  With the same 1500 pixel width and a rate of 80, the waterfall will consume about 650kbps.  Reduce the rate to a setting of 40 and now the same display will consume only 55kpbs
4. Metering today is fixed and will vary based on the number of slices you have (largely) and will consume about 30-60kbps
5. The discovery protocol will take about 2kbps

So if you are in a constrained bandwidth situation, altering the speed of your displays will give you a lot of control.

You're basically setting up conditions where I and many others will never be able to run remote. 

Well, in some instances, for right now, yes. Because 1.4 is not designed to run WAN yet. 

Version 1.4 has been out for two days, and essentially, you're voicing your frustration that 2.0 isn't out yet.