Remote via VPN Challenge

Richard G7EIX

A quick update on what we are using connection wise....

NC - 75mb down 8mb up.    UK - 100mb down, 5 mb up.

Currently looking at doing some TX tests this evening.   But RX has been slick and seamless with no issues for the past 24 hours.   

Richard G7EIX

W4/G7DCT in England currently on 7.235 LSB running remote on my Flex 6500 situated in Franklinton NC 

Time now 7:20PM EST  have a listen and try and work him.

Richard G7EIX

Worked two stations with no issues - no drop outs and I was monitoring on WEBSDR.ORG

WB2OHN in NYC
W4GDD in Virginia 

Looks like it works! :-)

Richard G7EIX

We also had Skype running from UK to NC also - just audio.   But even with Skype running - no issues.

kr4k

Good description - agree. This means that most VPNs will not work, since there will be few VPNs that will allow you to be in the same address space as the LAN. Cisco does this properly for security. Flex developers have a challenge ahead for the WAN connectivity.

Until 2.0, my current solution when off the LAN remains Splashtop for screen and receive audio plus PigRemote or RemoteRig for two-way. Am glad v1.4 has this new LAN capability for simplified operation.

kr4k

Good description - agree. This means that most VPNs will not work, since there will be few VPNs that will allow you to be in the same address space as the LAN. Cisco does this properly for security. Flex developers have a challenge ahead for the WAN connectivity.

Until 2.0, my current solution when off the LAN remains Splashtop for screen and receive audio plus PigRemote or RemoteRig for two-way. Am glad v1.4 has this new LAN capability for simplified operation.

K2ERA

I am using openvpn in bridged mode with 1.4 and it does work pretty good but it would be so much better if there was a way to directly connect to a radio by ip address rather than having to bridge the LANS to deal with the broadcast discovery of the radio.

By bridging the lans you end up having lots of non-radio related broadcasts come over the VPN so it becomes a hassle having to try and filter them all out.

I understand that they dont want people using simple port forwarding to connect to the radio because there is no security in place but perhaps allowing direct connection by IP could be some advanced option that could be enabled for those of us using a VPN.  It would make using a VPN so much better allowing usage in routed mode.

I have mixed success with audio via remote audio over the VPN.  Sometimes I find it better to use skype for the 2-way audio and then just use the VPN for control of the radio.

I was using teamviewer previously but it adds too much latency to SmartSDR and ruins the experience a bit.  I find it a much better  experience to run SmartSDR locally.

I believe your results will depend mostly on your total latency.  My total latency is between 20 and 30ms so my results are good, if your latency is higher like 70ms and up, I would expect poorer performance.

I am using an old original model raspberry pi b model as my openvpn server.  One tip is to increase the sndbuf and rcvbuf for your openvpn connection, before I increased mine it was unusable.  I also disabled crypto on the tunnel (but still authenticate the packets) to reduce latency further.  I plan on upgrading my openvpn server to a raspberry pi version 2 in the near future to hopefully improve things further.

K2ERA

Yes, that is how I ran my setup before 1.4 and it does work and I still use teamviewer from time to time.  However its not great, at least in my situation teamviewer doesnt do a great job of keeping up with smartsdr.  I end up with some stuttering in my spectrum scope and waterfall.  The remote audio back and forth with teamviewer didnt work well for me either.  It added too much latency to the audio.  This could however be due to me using the linux teamviewer client which is pretty poor.  Your results might be better if you are using windows.

K2ERA

I am curious, What OS are you using as the RDP server?  In windows 7 you cant connect to the console using RDP so all the audio devices are not available in the RDP session.  

K6OZY

That is true that all the lan stuff can make it to the VPN client using bandwidth for no reason.  But with pfSense you can isolate it so that only traffic from your radio makes it over the bridged interface.   That's what I do to stop random lan broadcast chatter going over my link.

I think a consistent connection is more important than latency to a point.  On my iPhone,  I am getting a stable 70-90ms ping.  I sat in the SkyWarn class last night with my laptop connected via LTE to my 6700 and it ran perfectly for 2.5 hours.   There would be a point at where latency is too much, but I'm seeing great success all the way up to 100ms.

K2ERA

Yeah since I am using a raspberry pi currently as my openvpn server I will just need to add some iptables rules to restrict the traffic coming across the VLAN.  Since i am running my SmartSDR locally inside of virtualbox this helps greatly as my entire local lan is not bridged since virtualbox runs in its own virtual lan.  There is only 2 computers on the remote lan so luckily broadcast traffic is currently quite low.

Yeah I think total network quality is important here.  Latency (I have 20-30ms latency measured by smartsdr so that is total latency including the vpn overhead), Bandwidth (I have 75/75 locally and upgraded the remote to 50/25 from 25/5 which helped a lot), and since both are using broadband connections (fiber on my side, cable on the other side) the network connection is quite stable.

That is not to say there have not been hiccups, as there have been, but overall it works great.

One thing I should add, I do all my digital model stuff on the remote lan via teamviewer.  I have a machine hooked up on the same lan as t he radio that I use for jt65, cwskimmer, etc and I find this is basically a requirement.  The digital modes seem to have issues handling the extra latency involved and I end up with poor results when using DAX over the VPN for the digital modes.

This hybrid type solution seems to be best for the time being.

K6OZY

If 2.0 supports DAX remotely is to be seen.  Since DAX is an uncompressed data flow, it may not be conducive to remote audio over small pipes.   I'm hoping for a clever solution for a highly compressed yet lossless stream.  I could live without remote DAX/IQ but I really hope we get a remote DAX for AF passband work.

Larry Loen WO7R

Well, based on the numbers you have ( which I had somehow never seen -- bad googling by me I guess ) it appears I am really doing is expressing ignorance of the design point.  But, I do suspect that with those numbers, I never will be able to run WAN, period.  Or, at best, it will run no better and may run forever worse than what I already have.

My very crude solution is putting out closer to 250 kilobits per second, total, and doing the job.  I can adjust it up and down with settings similar to what you cite.  If it gets tight, I can get it down to 175 or even a bit less.  Regardless, it is marginal in the evenings, as I have said, but I don't really see a solution that even approaches a megabit per second as ever really cutting it in a consumer environment.  The reason?  My aforementioned congestion.  Truth is, in a consumer setting, we don't get the bandwidth we are promised at all hours of the day.  I always knew that in the abstract, but now I am living it. Moreover the "isochronous" needs that we have will always make network congestion, when it happens, a mortal enemy.  Cutting down total bandwidth, though, will always help. 

I assume all this is known, but bear with me.

I am also astonished that panadapter data and waterfall data is flowing over the internet.  I hope the WAN solution (at least optionally) moves that to the client and settles for moving just the DAX I/Q data, which itself would need to be limited and capped at least optionally.  That would really cut the traffic down.  Yes, that will mean something in the i5/i7 class on the client side, but given the totality of circumstances, it would be cost effective (e.g. compared to paying more for added bandwidth that I strongly suspect won't really solve the congestion problem anyway).

Based on my remoterig-based experiences (nearly a calendar quarter now) in a consumer-grade environment, I would want a solution that was closer to 100 kilobits per second, less if it could be managed.  Moving the creation of the panadapter/waterfall information over to the client, produced from the I/Q data, should manage this for those of us who need it, which I think is just about everyone doing remoting over the general internet.  In effect, my existing TightVNC is kinda sorta dealing with the panadapter/waterfall stuff now, it's just doing it in pixelated form.  Get that off the network and the required bandwidth goes way down.  Get the bandwidth down and congestion is less of a problem.

That's perhaps nothing new, but it's experience with a version of our actual product, which I hope is useful feedback to someone.

Larry Loen WO7R

I think for my needs, presuming my revised understanding is correct, remoting the DAX I/Q _in replacement for other things_ such as panadapter data, is something I am going to need to get off of my current solution.

Larry Loen WO7R

I agree with K2ERA that there needs to be some recognition when someone is running VPN.  Is Flex on the line for this? 

No competitive solution I am aware of seems quite as concerned about securing the radios; presumably, they see it as a user responsibility to put it as far behind a firewall as possible.  Remoterig's devices are simple affairs; they have a "business" port for data transfer, but the primary interface for configuration (it is a directly addressable device with an IP) is just http over good old port 80.  My AC power controller (internet addressable) requires a password (not sure remoterig even requires that).  It does it over http (not https!).  We could go a bit better than remoterig or even my controller and require some sort of password-based https  based protocol, at least to start things rolling.  Something like "no signon, no other ports would be visible even on the local LAN".  In effect, the firewall (there is one, right?) on the radio would shut it all down until the signon.  Something like that could be enabled in lieu of all of this bridging stuff for those of us who want to run that way.

Given that congestion appears to be my biggest problem, extra broadcast data works disproportionately against me.  I don't have the tools to prove it, but I suspect that the absolute packet count, not aggregate data, is a substantial issue when ISP congestion gets in my way.  So, even that "small bit" of traffic is not welcome.

rfoust

I use windows 8.1 at home, connecting from ms remote desktop on a macbook pro. Remote audio works fine but rdp doesn't support the other audio devices like dax. Looks like it doesnt recognize the mic either.

Steve Walker

I followed the advice above and used pfSense to remove anything other than the radio from the WAN VPN and that suits me, we have 50 down and 20 up at both ends and tests with 1.4 show it to work fine - there is no congestion and latency so far it more than manageable.

ddWRT on the router and OpenVPN vs SSH tunnels & pfSense are fun for anyone wanting to learn VPNs and play radios at the same time.

However I am sat at work using FTTC here in the UK at both ends with 1.4 playing nicely whilst I listen in on a net on 40m. The radio is about 10miles from my work QTH and this is well worth the messing about with the network IMHO. Cannot wait for v2.0.

73 Steve

Steve Walker

I have tried very hard and I can keep more or less in the "yellow" at work in 1.4 - radio at home - and over FTTC which is probably the UKs best you can get for a sensible price.

Enjoying listening to the radio at the office. 73 and thanks again FRS for a wonderful release.

Mark G Thomas

It seems simple and obvious to me, that there could be an advanced user option to type the radio's IP into SmartSDR, assuming the IP address is known but might not be on the same subnet, and hence not discoverable by UDP broadcast. This would open the world for advanced users to environments with multiple subnets, such as non-residential WiFi setups, university campuses, business buildings, and non-bridge-mode VPNs such as Cisco and Juniper. KC3DRE