VPN UDP Port problem

  • 2
  • Question
  • Updated 3 years ago
  • Answered
I make a VPN LAN-LAN at home I have a 192.168.1.0 and at office I have 192.168.2.0 VPN work fine if make a ping to Flex radio IP (192.168.1.106) respond with excellent ping under 20ms, but a SmartSDR Windows at office not see my Flex, with Its version not problem, I fixed Flex Ip into setting and work fine how-to resolve on windows?
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 178 Posts
  • 6 Reply Likes

Posted 3 years ago

  • 2
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 60 Posts
  • 32 Reply Likes
Official Response
Welcome to the club :) You either need a bridged VPN see the Softether tutorials in the forum or OpenVPN with TAB bridge. Or wait for Version 2.0 or see:

See https://community.flexradio.com/flexr...

and

https://community.flexradio.com/flexr...

73
Frank
Photo of Mike va3mw

Mike va3mw

  • 824 Posts
  • 199 Reply Likes
Frank, it has to do with the routing of VITA49 packets.  Simple story, is that your VPN connection has to be on the same subnet to function.    Meaning that at your office, you'll have to see a VPN Network connection on 192.168.1.0.  

Mike va3mw
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 178 Posts
  • 6 Reply Likes
No guys, it's easy! FlexRadio staff must Be update Windows version and maestro too as such as a iOS version for fixed manually a FlexRadio IP.... iOS version on VPN LAN-LAN work finw without change submask net, not possible make a VPN LAN-LAN with same submasknet!
Photo of Mike va3mw

Mike va3mw

  • 824 Posts
  • 199 Reply Likes
Frank

My Softether connection provides me with an IP address on the same subnet and my VPN connections with either iOS or Windows works fine.

Here is what my laptop at work looks like connected to my VPN at my remote base which is on 192.168.1.0.

C:\Users\xxx>ipconfig
Windows IP Configuration

Ethernet adapter VPN - Softether:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.1.148
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Wireless LAN adapter Wireless Network Connection:
 
   IPv4 Address. . . . . . . . . . . : 172.xxx.xxx.xxx
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . : 172.xxx.xxx.xxx

Mike va3mw
(Edited)
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 178 Posts
  • 6 Reply Likes
Yes I know this solution I used it a long time but the VON is on software emulation my solution is hardware I using two devise Fritzbox with hardware VPN LAN-LAN only one solution is a possibility to fixed on SmartSDR windows and Maestro FlexRadio' s IP
Waiting it from FRS HQ
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9188 Posts
  • 3550 Reply Likes
Native WAN capability will be available in SmartSDR v2.0
Photo of k3Tim

k3Tim

  • 925 Posts
  • 197 Reply Likes
and when might that be?   

:-)
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9188 Posts
  • 3550 Reply Likes
When it is done.
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 178 Posts
  • 6 Reply Likes
ETA?
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9188 Posts
  • 3550 Reply Likes
When it is done.  We will start working on it after SmartSDR v1.10
Photo of Frank, IZ7AUH/AK1CQ

Frank, IZ7AUH/AK1CQ

  • 178 Posts
  • 6 Reply Likes
Great news! I hope for end 2016... :-)
Photo of Frank, HB9FXQ

Frank, HB9FXQ

  • 60 Posts
  • 32 Reply Likes
Tim, here is my personal opinion: 

@Frank "All we can do is Sit And Wait All we can do is just.... ....or work-around" :-)

The architecture to enforce connecting to the radio by UDP broadcast based discovery provides only very very weak security. With that IOs client its completely invalid to say this is a security feature anymore. People can put the radio into the DMZ, or forward x ports etc etc. Better warn then not to do so, when informing in the forums which port numbers have to be forwarded to make the IOs thing work from LTE...

Now many users understand that exposing the radio to the internet by simple port forwarding is a dump idea. That's not good, since the so called script kiddies would find a way to abuse the radio without any discovery info ;) That's why we all build VPNs. Bridged VPNs are fine in single user scenarios, but for site-to-site with more than two sites (networks) a bridge is not always the desired way. IPv6 starts to appear everywhere. Look what happens, when a network peer starts to send IPv6 RA packages around your bridged network! That was happening in our bridged setup. Found no way to firewall IPv6 RA & NDS traffic on the bridges 100%. IPv6 spec seem to have some vendor specific workarounds as well...   

I share an official registered remote station with other OMs, and bridging was giving me so much admin work, firewall etc, that I've had to move to routing, separate subnets - and build my own workaround:  https://github.com/krippendorf/flex6k-discovery-util

I am already busy writing a very lightweight, C based version, to run it directly on our small PfSense hardware appliances.

But when I look at the FRS .NET API code, the Radio object constructor (https://github.com/krippendorf/FlexlibMono/blob/master/src/FlexLib/Radio.cs#L643) would be perfectly fine. I'd estimate it would't be too much effort for FRS to integrate it into Maesto and SmartSDR for windows! Maybe it is, don't know. Waiting really makes me a bit sad now, since it generates so much work here, to make it work with workarounds. And  technically it does work perfectly fine! And we're not talking about a 20 $ plastic router, we're talking about high price segment radios! 

Seeing other customers ending up in similar situations and FRS always talks about a fully WAN-ready solution makes me think, we're talking about two completely different things now. Not all your customers really need any authentication layer, NOR encryption, and I'd beg my open source based VPN solutions will be more secure on a longer term than any proprietary built-in thing I have no control of. Who is responsible if my WAN radio gets involved DDOS attacks, because it included a zero day exploit in a authentication routine? I'm sure my ISP would care and disconnect my line. And then? Wait for FRS to patch it?  Not an easy situation, so I want to stick with my own VPN and keep things under my control, as good as possible. 

So please don't talk about native WAN, when everybody talking about VPN. Technically I see it as it is a LAN, routed! 

Please don't make us wait for an authentication layer integrated. My wishlist for the soon future is: 

- Add a menu entry to enter manually defined radio endpoints to the radio list. Make DAX / CAT to look in the filters.txt file for some kind of known-devices list
- On Maestro and SmartSDR for Windows: Only allow to enter radio IP addresses that are reserved for private networks per RFC 1918 (10/8, 172.16/12, 192.168/16) No DNS.
Regex like  ;) "(^10\.)|(^172\.1[6-9]\.)|(^172\.2[0-9]\.)|^172\.3[0-1]\.)| (^192\.168\.)|(^[a-zA-Z0-9\-\.]+\.(hb9fxq.ch)$)"

- Keep manually entered radios in the list for simple re-connection after reboot / restart etc. 

- Allow non-private networks with v2.0 WAN included SmartSDR

end of my wishlist

73 & If you read this, thanks for reading 
Frank
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9188 Posts
  • 3550 Reply Likes
You're welcome.