User Tools

Site Tools


See Below for information on other VPNs

Using the Hamachi VPN to connect your Cloud for NDI Gateways

The most reliable method to connect Cloud for NDI Gateways with the best video streaming performance is to implement port forwarding so each Node can connect directly to the others with no intermediate complication.

In some cases, it may not be possible or convenient to setup port forwarding or DMZ settings on your network and if this is the case, you may want to use a VPN instead. A VPN (Virtual Private Network) creates a 'virtual' network between the members of the VPN even if they are on different physical local area networks. If you are part of a large corporate enterprise you may already have a VPN between sites.

There are many different VPNs available and they are not all the same. For Cloud for NDI the one we like best is LogMeIn Hamachi, which can operate as a peer-peer MESH popup VPN. Hamachi provides complete connectivity between its peer members, allowing UDP Port 9002 to flow smoothly.

Note that some VPN products only allow HTTP or other specific connectivity and are not suitable for Cloud for NDI. Check with your network Admin for details.

Hamachi can be found at and you can sign up for a free account. You should create a MESH network, and add your various Cloud for NDI Gateway computers to the network. Once connected they will all be part of a virtual network and will see one another, and be free to communicate on UDP Port 9002.

You will use the Hamachi VPN IP Addresses which appear in the LogMeIn Hamachi control software


Hamachi networks MAY NOT be suitable for Cloud for NDI - depending on the type of connection which the VPN achieves between the peers. Only a 'Direct' Hamachi connection is suitable for Cloud for NDI. If your Hamachi connection is made in 'Via Server' or 'Via Relay' mode it is NOT suitable for Cloud for NDI and will NOT give the level of performance required. In this case you MUST use the Port Forwarding or DMZ mode instead.

To check which connection mode you have got between each site, right click on the Hamachi connections in the control panel, and select 'details'

The Connection type MUST be 'Direct' - if it's anything else, then this Hamachi connection is not suitable.

Also, if your local security restrictions are really tight you may find that Hamachi is completely blocked. In this scenario we generally find it impossible to 'turn on' Hamachi with the power button - you press it to turn it on but it immediately goes off again. This is believed to be due to local restrictions blocking attempts of Hamachi to negotiate with the servers. Information on opening ports to allow this is available at at the Hamachi website

There is one additional consideration with Hamachi - that is that it allows 'leakage' of Bonjour service advertisements between the peers. This can be very confusing with Cloud for NDI since you will see the actual NDI services advertised on all the Cloud for NDI Gateway computers, not just local ones. If you select these leaked services in an IP Video device it will attempt to pull the full bandwidth NDI stream from the remote site which will typically not be possible.

Locally relayed Cloud for NDI services are identified in the list of NDI Services with the machine name of your Cloud for NDI Gateway along with “R+” prefixing the remote service name (with the remote Cloud for NDI Gateway name)

Typically you will only see these leaked services when you are on the actual Cloud for NDI Gateway computer (other LAN users probably wont see the leaked services) - but its important to be aware of what this is when you are setting up and testing. NB: Some versions of the Cloud for NDI Gateway are able to actively filter out NDI source propagation over Hamachi.

Using other VPNs to connect your Cloud for NDI Gateways

Very little current knowledge exists of running Cloud for NDI on VPNs other than Hamachi.

Hamachi is particularly useful when both ends of an Cloud for NDI network are behind opaque firewalls which the users have no control over. However, there are many situations where at least one end of the connection will be configurable from a networking perspective. In this mode, both ends communicate with the Hamachi server and attempt to tunnel across to the other end by negotiation through the server. This only works well if both ends allow for direct tunnelling, something which is prevented by symmetric NAT routers found in some locations.

One recent test involved enabling the VPN functionality of a SonicWall Firewall Router and the limited experience is documented below.

- The scenario involved an Cloud for NDI setup where one end was a fixed location belonging to a sports broadcaster where they have control of the local firewall. The other end was a stadium within a *very* locked down corporate network. The objective was to enable a VPN in the firewall at the fixed location and allow the stadium to connect.

- This user typically uses public IP addresses with port forwarding for Cloud for NDI so this was a new experience, triggered by very strict security at the stadium location which prevented a direct connection with a public IP address.

- The first challenge was to establish the IP addresses to be used. Unlike the Public IP mechanism, the remote end connecting into the VPN is assigned an IP address by the VPN, and its this address with port 9002 which should be used to identify the stadium node. This was found in the System Preferences (macOS) networking panel, for the NIC created by the VPN. The other node is within the local area network opened up by the VPN and its normal network local IP address is used, again with port 9002 since no port forwarding is involved in this setup.

- Initial connectivity was established and the nodes were able to communicate and exchange NDI service advertisements. However at the time of writing the performance across the VPN was insufficient to allow video streaming despite a very high internet connection speed. It is assumed that the Sonic Wall VPN has a bandwidth limiting parameter which will need to be modified to allow for full data rates. Sonic Wall documentation states that enabling bandwidth limiting without specifying a value results in a 384k/sec limit.

- More details on the outcome of this scenario will be added as information becomes available.

hamachi.txt · Last modified: 2017/08/26 10:25 by mark