A few months ago we had a conversation about using VPN for remoting..
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????
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.
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: 188.8.131.52
Radio IP address: 192.168.13.146
Client IP address: 192.168.11.17
From Win7 command prompt, I can ping radio:
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.
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 !!
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.
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.
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.
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.
- 5208 Conversations
- 1589 Followers
- 3071 Conversations
- 632 Followers
- 3599 Conversations
- 930 Followers
- 980 Conversations
- 397 Followers
- 873 Conversations
- 150 Followers
- 2965 Conversations
- 849 Followers
- 483 Conversations
- 160 Followers