smartsdr ios problems with VPN and audio

Howard Koenig

I've got a pair of Bose noise-canceling headphones.. Ahhhhhhhhh.... makes the trip most enjoyable!

Steve K9ZW

I'd leave the demo audio file change for a "someday list" as it gets the job done.

I'd rather a demo reflect something other than studio quality unless that high level quality will be achieved every time without fail.

This way the actual user achieved performance will be better in the majority of cases, rather than something so slick that only a few users can duplicate it in the wild.

One think that might we useful is to overlay the screen with some information about the demo when it is selected.  Explaining the limitations of the demo and what it is intended for might address some valid concerns.

73

Steve K9ZW

Ken - NM9P

Here is a thread that discusses, among other things, my journey to get my ASUS router working with my ATT Uverse Motorola DSL modem/router. The last post is the final update/solution. https://community.flexradio.com/flexradio/topics/openvpn-with-asus-rt-n66u-router?topic-reply-list[settings][filter_by]=all&topic-reply-list[settings][reply_id]=16412342#reply_16412342 Hope it helps, Ken - NM9P

Paul Christensen, W9AC

After spending two days trying to provision Softether and SSDR-ios with my iPhone/iPad settings, I finally have a VPN path between those devices and my Flex 6700.  So that others do not have to go through this level of pain, I have some suggestions, that hopefully will be of some value:

1) I don't want this to sound mean-spirited, but many folks, including K6OZY have been directing us to the K6OZY videos to set up SSDR-ios with Softether VPN software.  Chris has done a fine job with the presentation of the 2-part videos, but it must be understood that the videos were intended as a tutorial for remoting Maestro over a VPN, using a Raspberry Pi device.  When using Softether with SSDR-ios, the Part 1 video is not relevant until approx. 22 minutes into it.  Also, the video directs us to install only Softether Manager for Windows and not the Softether Server -- because again, the video is intended for VPN use between Maestro and a Raspberry Pi.  Bottom line, you need to install Softether Server with Manager.  Please folks, if you're going to direct users to a tutorial -- no matter how helpful your intention, at least explain the caveats stated herein.  When you know this stuff and point others to a tutorial that is filled with irrelevant, confusing gaps, it's easy to assume others can fill in the gaps -- but the gaps are big in this case.  End of sermon;

2) It may be best to first configure router ports before attempting to download and install the Softether VPN software.  If you cannot figure out how to provision a router, there's no need to aimlessly start clicking away at the Softether configuration menus to try and get a working VPN path;  

3) Another part seriously missing in these discussions is the ios VPN setup meanings.  A couple parameters need clarification, I think:

(a) TYPE: Use L2TP as others have correctly instructed;

(b) SERVER.  This is the target address set up in Softether.  Mine is w9ac.softether.net and further discussed in paragraph 4(a) below.  

(c) ACCOUNT: This one had me going in circles and again, not explained by other users here.  To be clear, ACCOUNT is the USER Name as set up in the SoftEther installation process.  it is NOT the Softether HUB NAME.  While folks have pointed to other on-line ios VPN tutorials, they are absolutely useless because they're generic and do not convey the association between ios VPN and Softether; 

(d) PASSWORD is the USER Name password set up in Softether.  It is not the Softether Administartor password or any other password field used in Softether;

(e) SECRET had me going in circles again.  But the fine print in the Softether L2TP menu does clearly explain this is the term that is used when the word "Secret" is asked in the ios client.   Mine is set up with the default "VPN," but I honestly thought this was a "secret reminder" for the PASSWORD above.  OMG, why call the **** thing "secret" next to password in the ios VPN setup menu?  Just my opinion, but the ios VPN configuration menu should have a small "what is this?" (i)nformation button next to these terms;

4) Within Softether, the Destination VPN Server Host Name is the global IP address, it is not an IP on your LAN network address (e.g., 192.168.1.x).  Mine is set to the dynamically changing Comcast DNS address.  Supposedly, this will track as the ISP periodically changes the IP.   As a test, I did try using my NO-IP DNS manager account and that worked too since NO-IP tracks my ISP's IP.  We'll see how this goes but a DNS manager like NO-IP should not be needed and the reason for the ****.softether.net addressing to manage this.

(a) Under Dynamic DNS Settings, this is where you set the ****.softether.net address.  This must match the SERVER name in ios VPN.  Give it time to propagate.  I had to wait over 10 minutes.

(b) Under the Local Bridge menu setting, my Intel Gigabit Ethernet adapter had to be opened for VLAN, even though it works fine for VNC and TeamViewer, and several other remoting programs.  I had to use the VLAN Transparency Setup Tool on the same menu page to open up the Intel Ethernet port;

(c) Under the IPsec/L2TP menu, this is where you will enable it with a check bot next to "Enable L2TP Server Function (L2TP over IPsec).  Upon doing so, the IPsec Pre-Share Key box opens and this is where you put the same name as the ios VPN SECRET name.  Again, mine is set to VPN as discussed in 3(b) above;

Another user here had to reset his ios Network Settings.  I had to do the same.  Re-entered the ios VPN information, and thank God, finally established a VPN connection.  Once connected. there were zero issues with SSDR-ios finding my Flex 6700.

Those are my issues.  No doubt others will have their own.  For Flex to make 2.0 work among its users, they will need to create a dedicated wizard with a means of streamlining the VPN set-up process to circumvent these configuration issues. Otherwise, they will be faced with a nightmare.

Paul, W9AC

 

Mark G Thomas

I'd like to further comment that there are many VPN options compatible with iOS (Iphone/iPad) devices. Softether is one of them, however many consumer and commercial firewalls/routers already provide a built-in compatible VPN that your iPhone or iPad can remotely connect to, no additional software needed. When using a VPN built into your router/firewall, you typically do not need to open additional ports or even run a PC, because the router takes care of this for you.

The Maestro and SmartSDR-Windows VPN situation is more complicated than using an iPhone or iPad native VPN, because the software lacks the configuration option to specify a fixed radio IP address, so requires a broadcast-passing VPN. Most VPNs do not pass broadcast traffic. I keep asking about this, because I believe this basic option would vastly simplify use and support. 

Mark, KC3DRE

K6OZY

Part 1 is for setting up a SoftEther server on a Raspberry Pi for use with any client, not Maestro only.   At the end of the video I test it using a Windows 10 client.

Also, You only need the manager component on Windows if the Server is running on the Pi.

Plus when 2.0 comes out, we won't be using VPN so this will all be moot.

K6OZY

This limitation is purposely implemented by Flex to make this hard.  They don't want us simply port forwarding stuff through the firewall to get our radios to work on the internet.  By forcing this requirement, it requires us to use a VPN solution to use the radio.

Mark G Thomas

Are you speaking officially for Flex, or is this more like speculation on your part?

There are numerous foolish and even dangerous things people could do with their radios. This is a licensed hobby for good reason. Restricting a client-end (SmartSDR) program so that hopefully people might be less likely to do something **** on the server (radio) end of the network connection seems misguided, ineffective, and like a disservice to many of us who would benefit from more FLEXible networking of this otherwise totally awesome and amazing product.

In order to prevent someone from opening up their Flex radio to non-protected-by-VPN risky connections from the Internet, measures would need to be taken on the radio end of the network connection. Crippling the client doesn't protect the radio.

Mark, KC3DRE

K6OZY

Obviously I'm not able to talk officially, as I'm not an employee, but it is well known since release that SmartSDR has been purposely restricted to same-subnet operation due to no authentication on the radio.   The restriction is done on the radio.  My attempts at deciphering the block allows TCP metering data to be forwarded out of the subnet, but the VITA49 UDP stream will not exit the subnet.   Radio discovery is done via a broadcast on the subnet.  The new IOS app allows a direct connect ignoring the broadcast as a discovery technique.

I've been part of the Alpha team since the beginning and am under NDA, so my ability to openly discuss reasons, future features, or even rumors is restricted.   An FRS employee will chime in if necessary to discuss displeasure in their business decisions.

Mark G Thomas

Perhaps I was unclear then. I am suggesting that it would be beneficial for SmartSDR for Windows and Maestro to permit the same kind of (more flexible) direct IP connection as the new iOS app does.

K6OZY

That's what 2.0 will be.

Ken - NM9P

Not speaking for anyone by myself...And purely my own speculation without reference to any Alpha discussions that I am aware of...

My impression is that it could be structured this way for multiple, overlapping reasons:

1) It may be intended to protect the integrity of future network-interlinked multiple receiving stations that may rely upon the data produced by a myriad of geographically diverse stations.

2) Requiring VPN or other authentication would protect the rest of the user's home/business network from outside mischief.  Having unsecured peripheral hardware opened to the outside world via a non-VPN connection can potentially put everything on the Local Area Network at risk, as well as anything else to which the Local Area Network is connected via OTHER VPN's.  i.e. One small leak in an otherwise solid water system can lead to contamination of the entire water supply.

(Remember the first Gulf War?  Some sources later reported that one of the techniques used to **** Iraqi Air Defenses was to introduce a printer or other device to the network that had Trojan Horse software which allowed timely disruption of the air defense computer network.)

FRS may be protecting itself from liability claims from those who poke holes in their own network in order to achieve easy connectivity and suffer the consequences, but wish to blame others via expensive lawsuits....  

3) This may be a requirement for more demanding government and commercial customers that may use common elements of the software/hardware incorporated into the Flex-6000 system.

4) Requiring authentication may be designed more to protect the radio itself from harm caused by hackers (which could result in expensive repairs and the opportunity for nay-sayers to malign FRS) than to protect the amateur from having his station hijacked by unauthorized users who might make illegal transmissions.

Again....I am not an employee or agent of FRS, but there are just a few possible reasons FRS may have considered in its decisions about how "open" this piece of equipment is to the Wider Internet. 

Ken - NM9P

K6OZY

The direct IP connection of the IOS app does not work out of the subnet either because of the radio-side restriction. Also, the IOS app was written by an external developer so that's why there may be a bit of dissimilar features between them.

Mark G Thomas

This is not true. It is not true that the direct IP connection of the IOS app does not work outside of the subnet.

The direct connection in the IOS app DOES work very well outside of the subnet via direct WiFi as well as via IOS-supported VPNs. These VPNs typically do NOT pass broadcast packets. The purpose of the direct IP feature is so the app can discover the radio when not on the same subnet. This is applicable regardless of whether you are using VPN, by the way.

I am enjoying using my Flex radio via the iPhone app right now, using a WiFi network which is not on the same subnet as the Flex radio base. While it is common in residential situations to put your WiFi network on the same subnet as your wired LAN, it is best practice not to in larger scale or more security conscious environments.

K6OZY

I have tried NAT forwarding only with the IOS app (TCP/UDP 4991-4992).  I haven't tried subnet to subnet without NAT involved yet with it with the IOS app.  If that does work, that will allow more VPN choices besides SoftEther.  Many VPN servers in cheap routers use a different subnet instead of ProxyARP or bridging.   Good info.

Lee Maisel

I went through all this, and turned on fixed IP ad scan instead, and was finally able to connect through VPN, HOWEVER   NO AUDIO and nothing on the waterfall!

Lee Maisel

i am able to connect using vpn and marcus's ios app, but NO AUDIO

Mark G Thomas

When I first connected, I thought I had no audio, but then I discovered that the default audio level is so soft as to be inaudible.
- Device Audio must be turned On, top option on left-side menu.
- Audio panel from frequency control must have Volume slider set to 90-100
- iPhone/iPad side-volume control must be set to near maximum
I believe this is probably a bug.

Mike va3mw

Not a bug. It's a feature.

Cliff - G4PZK

Even when V2.0 supports a VPN natively I would still not use the facility. It is far from ideal to punch ANY holes through the network gateway perimeter device. When ports are opened they normally route only to DMZ devices like web servers or SMTP systems. I deal with PCI-DSS credit card systems from time to time and opening ANY port usually results in the required security tests failing and subsequently PCI-DSS compliance. Over the years the credit card companies have massively tightened up their requirements for network hardening and with good reason.

It's true that for home users full commercial level security with hardened gateways may not be required but it's much better to make the router device itself act as the VPN server using L2TP/IPSEC or whatever rather than punch holes through the firewall. The next level used commercially is to use a router and a dedicated and hardened firewall device.

I'm not saying that SoftEther per se is a bad solution (quite the contrary) but having ports opened to other devices running other operating systems does multiply risk especially if the machine in question is running a general purpose OS rather than being a dedicated device. I really hope that SmartSDR will soon support the ability to specify the IP address of a Flex radio rather than using broadcast packets in order to discover any devices. I do appreciate why Flex used this method, not least to massively reduce their support burden, but I do not want to have to bridge my remote VPN connection when it should be sufficient to simply specify an IP address. Given that the Apple IOS client can do this it can't be a huge effort to modify the Windows client.

Just my 0.02 worth.

K6OZY

My gut feeling is that 2.0 won't use VPN, but rather encryption such as SSH and add user authentication. Auto discovery will likely be done similarly to TeamViewer. Again, these are guesses and I do not speak for FRS. This is how I'd build it.

Ken - NM9P

So just to speculate, as a relative VPN/SSH Networking noobie.....And not looking for anything that would violate NDA's...

If FRS or any other vender doing similar networking were to do SSH encryption with user authentication, would a user then need to do a simple port forwarding to the IP of the 6000 rig, similar to what is required to pass Echolink to a local computer?  Or would NAT punch-through routines or port forwarding already be automatic, like some media sharing and gaming applications?

Would we then have a pre-shared Key or even a key-code or config file similar to what OpenVPN requires on each client?
  
Might we even need to use either direct IP entry or a DDNS name server like I use with my ASUS router, since I do not have a static IP from my home internet provider?

These are hypothetical questions about general WAN networking more than specifics related to SSDR/WAN.  But is this the type of thing you are suggesting if they did it "the way YOU would do it?"

If so, it doesn't sound too difficult to master.  But might take a little hand-holding  for some who are more cyberphobic.....

I'm always trying to learn something more........

Ken - NM9P   

Tim - W4TME

I wouldn't speculate too much.  There are a dozen ways to "skin this cat" as they say.  I can tell you that the design goals are to make WAN remote as transparent as possible and for it not to require third-party software or make the user perform custom configurations on routers.

Ken - NM9P

Nice!  Especially the part about not requiring custom router configs.

My speculations, however, are mostly an exercise to sharpen my understanding of the many different nuances of networking.  

I have played around with SSH, VPN, Remote NAS Drives (such as D-Link DNS-232 and Qnap-210), Freenas on an old desktop, and have even done some other interesting things with embedded linux utilities on my NAS Drives.    But even then, I feel like a real rookie when I talk to some of you folks who do this for a living!

Looking forward to seeing what the real pro's will come up with.
Keep up the good work..

Ken - NM9P

Cliff - G4PZK

An SSH based solution would be a neater solution but still require a port to be opened of course.

<SPECULATION>

The only way you can avoid opening a port for incoming connections is for an outgoing connection to already be made like for instance if Flex (or whoever) were to act as an intermediary of some sort. Personally I shy away from those kind of scenarios or at least I never leave them active but only activate them as required (hmmm, I do use Skype!). This would give a very useful database/network of connected systems of course.

</SPECULATION>

Speculation is a pointless exercise really as Tim has been saying. They will do what they do and will naturally aim to minimise the support burden. As long as it's easy and works no user will care hugely I'm sure.

I await V2.0 from user land with interest.

K6OZY

To make it completely transparent, my method would be to use UDP hole punching + UPNP.  

The SmartSDR client machine has a TCP connection to the discovery server at Flex.  The radio has a TCP connection to the discovery server at Flex.  When you click Connect, the client tells the discovery server what it wants to do.  The discovery server gives the client the IP address of the radio.  The SmartSDR client begins firing UDP packets at the radio's public IP.  The radio is informed from the discovery server that you intend to connect and is given your client public IP.  The radio starts firing UDP packets at you.   This causes both firewalls (yours and the client) to let the traffic flow "punching holes".

This setups the UDP VITA 49 stream.  For the TCP metering, the radio could dynamically register a port on your home firewall with UPNP and convey this dynamic port to the client via the discovery server.  This TCP port would be encrypted and authenticated via SSH.

Mark G Thomas

I just wish we had the option to enter the radio IP into SmartSDR and Maestro, (like as we do with the iOS app), for those of us who already have secure firewall-based VPNs, or merely want to connect from a different subnet within our network.

Jay -- N0FB

Patience Grasshopper....Patience!

John W9KXQ

I now have an iPad with the SmartSDR for iOS App installed and working.  Additionally I have followed Chris K6OZY's YouTube Video and believe that I have the SoftEther Raspberry Pi operational---Now how do I set up the VPN from my iPad to connect so that I can use the iPad outside my home network??  I have been unable to find instructions for this.

Thanks,
John
W9KXQ

KC9NRN

Ever since I got things working on the iPad Pro using my R7000 with OpenVPN I have been having a blast listening to the radio. Works every single time now.