Remote via VPN Challenge

  • 3
  • Question
  • Updated 2 years ago
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!!!!!!!!!!!!!!!!
Photo of KY6LA - Howard

KY6LA - Howard, Elmer

  • 3541 Posts
  • 1396 Reply Likes
  • Curious

Posted 4 years ago

  • 3
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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
Photo of kr4k

kr4k

  • 73 Posts
  • 13 Reply Likes
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:\Users\gklott>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?
(Edited)
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
(Edited)
Photo of Jay -- N0FB

Jay -- N0FB, Elmer

  • 534 Posts
  • 211 Reply Likes
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
Photo of kr4k

kr4k

  • 73 Posts
  • 13 Reply Likes
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.
Photo of kr4k

kr4k

  • 73 Posts
  • 13 Reply Likes
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.
Photo of Mark Thomas

Mark Thomas

  • 47 Posts
  • 14 Reply Likes
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
Photo of Ric KV1W

Ric KV1W

  • 45 Posts
  • 0 Reply Likes

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

Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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.
(Edited)
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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.
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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.
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 479 Posts
  • 77 Reply Likes
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.
Photo of K2ERA

K2ERA

  • 36 Posts
  • 1 Reply Like
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.  
Photo of Robbie - KI4TTZ

Robbie - KI4TTZ

  • 479 Posts
  • 77 Reply Likes
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.
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 3969 Posts
  • 1225 Reply Likes
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.
Photo of K2ERA

K2ERA

  • 36 Posts
  • 1 Reply Like
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.
Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes

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!


Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes
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.   
(Edited)
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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 fat 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. 
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
Rob, what is the configuration?  Do you have separate subnets or does the VPN make everyone look like they are on the same one?
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
Photo of K6OZY

K6OZY, Elmer

  • 532 Posts
  • 197 Reply Likes
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.
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
Photo of Rob Fissel

Rob Fissel

  • 270 Posts
  • 47 Reply Likes
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. 
(Edited)
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 3969 Posts
  • 1222 Reply Likes
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.
Photo of Chris Tate  - N6WM

Chris Tate - N6WM, Elmer

  • 808 Posts
  • 217 Reply Likes
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 :-).
Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes

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.


Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes
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! :-)
Photo of Richard Clafton W4/G7EIX

Richard Clafton W4/G7EIX, Elmer

  • 455 Posts
  • 117 Reply Likes

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

Photo of K2ERA

K2ERA

  • 36 Posts
  • 1 Reply Like
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.
Photo of K2ERA

K2ERA

  • 36 Posts
  • 1 Reply Like
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.
Photo of K6OZY

K6OZY, Elmer

  • 532 Posts
  • 197 Reply Likes
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.
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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.
(Edited)
Photo of Larry Loen  WO7R

Larry Loen WO7R

  • 189 Posts
  • 23 Reply Likes
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.
Photo of Steve Walker

Steve Walker

  • 71 Posts
  • 10 Reply Likes
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
Photo of Steve Walker

Steve Walker

  • 71 Posts
  • 10 Reply Likes

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.