Running two HRI-200’s on one IP Address

I use VyprVPN from GoldenFrog. It is necessary to turn of NAT for your account. That means that each VPN connection is a raw connection straight to the Internet. YOU HAVE NO PROTECTION OTHER THAN WHAT YOU PROVIDE!!! (The same company will rent you a VPN that you can host on your own cloud provider where you can control port forwarding – but I suspect this is well beyond most folks.)

 
I’ve been using this solution for over a year. If you’ve ever seen me demonstrate WiRES-X, I’m either using AT&T/cell or the local Wifi along with the VPN to get access to the incoming ports.
 
Good news! My fully patched and maintained Win7 boxes have not yet been hacked. One of which has been online via VPN for over a year.
 
Most VPNs won’t work because they don’t give users their own IP. The VPN host shares IPs between multiple users which means they can support more users with fewer IPs (and better obscures your traffic). I’m only aware of two VPN providers that allow you to specify incoming ports.
 
The previous post of using the Ham’s IP space is a good one. I plan on giving that a try when I have time. But VyprVPN is very much plug-and-play.
 
Note: You will need to PAY for VyprVPN (~$70/yr). The free service does not allow you to disable NAT.


What Does the HRI-200 Actually Do?

What’s the difference between using an HRI-200 and directly connecting to the radio?

1. It is the only option for connecting a repeater to WiRES-X.
2. It uses UDP communications sent directly to the Room. So network communications are very efficient.
PDN uses TCP instead of UDP. (Why use UDP? UDP is simple. If anything gets lost, it is dropped. Good for real-time communications. If a packet is missed with TCP, it will keep retrying up to a limit which is not good for real-time. VoIP, VPN’s, Netflix, etc. all use UDP.)

The PDN TCP packets (non-HRI-200) are sent to a server in Japan. This server converts the packets to UDP and then sends them to the selected room in the same way the HRI-200 does. So by using the HRI-200 you bypass a drip to Japan and a potentially problematic conversion from TCP to UDP and back to TCP for the return trip to your station.

Yaesu uses the TCP approach to get around forwarding of ports. The WiRES-X PDN software establishes a TCP connection with the Yaesu server. It’s through that connection stations can contact you even though you don’t have an open port. With the HRI-200, stations just get your IP address and send you packets directly. This is why PDN cannot efficiently host a room – all room traffic would have to go to Japan for the conversion process.

In a previous post (2016) I described what the HRI-200 does. Why it is the way it is is somewhat historical from the history of WiRES, WiRES-II, and now WiRES-X. Obviously an Ethernet port on the back with an embedded processor to run things would be a better way to go. I can only guess that the ROI is simply not there for Yaesu. They do, after all, have to make a profit.

One further note. It’s probably a good thing non-Yaesu equipment doesn’t connect to WiRES-X. The biggest problem in bridging hotspots (YSF, FCS, etc.) to WiRES-X is that the hotspots are bad neighbors. They generate bad packets, do crazy things, and can really trash a network. As a room operator we have no control over who tries to connect, so at least the Yaesu equipment has gone through compatibility testing. Believe me, very little testing is done on hotspot software.

MNWis (21493) bridges to YSF (21493) via a YSF Reflector where I have extensively modified the code to drop bad packets, control information, and all manner of things that shouldn’t see there way into the WiRES-X node. I had to do this because we were constantly having hotspots connect and mess everything up. It got very, very tiring working with the (mostly new) hotspot owners to fix their problems. I mean the conversations were endless and constant! So I just dropped anything that looked bad in the YSF Reflector software and the problems went away as well as a few hotspots who could no longer connect or talk to people.

System engineering is critical. We need Yaesu to play the roll of system engineering to keep all the Fusion products working with each other. It’s so nice that all the Fusion equipment basically works the same way and does the same thing all of the time! 

BTW, you can bring your questions/comments to the MNWis Fusion Technical Net held Monday’s at 7:30 PM Central in the above mentioned locations.