Using Qt sockets over the internet with NAT traversal

[jars121]

Hi,

To provide some context, I asked this question on the Network Engineering StackExchange. As per the detail in the link, I'm trying to design a TCP connection between an IoT device (server) and client applications. I have no issue accomplishing this using QTCPServer and QTCPSocket when the device and client reside within the same network. The issue is when the IoT device is deployed into the field, and accesses the internet either via a 4G dongle or a mobile hotspot. In these instances, it can be assumed that the 4G/mobile carrier doesn't provide a public IP address, in which case peer-to-peer connection with the client(s) is not possible.

As per the suggestions and commentary in the link, the recommended approach seems to be to use a STUN/TURN server, whereby the direct peer-to-peer connection is made if possible, otherwise the TURN server acts as a public relay between the IoT device and client(s).

I've done some further reading, and while I understand the general STUN/TURN server premise, I'm really struggling to understand how that would work in practise within Qt. Note that both the IoT device and the client application uses Qt. Does anyone have any pointers or guidance?

Secondly, hosted TURN servers are expensive, so if anyone can think of some other novel approach I'd be very open to it!

[JKSH]

@jars121 said in Using Qt sockets over the internet with NAT traversal:

while I understand the general STUN/TURN server premise, I'm really struggling to understand how that would work in practise within Qt.

The Qt classes like QTcpSocket/QUdpSocket are low-level (around Layer 4 of the OSI Model). STUN is a layer above that.

So in a nutshell, you need to implement STUN handshaking logic on top of the Qt classes. Here is a sample project that does so (disclaimer: I haven't used this myself so I can't comment on its quality): https://github.com/VictorGerin/QT-UDP_Hole_Punching

if anyone can think of some other novel approach I'd be very open to it!

If you set up a VPN and connect your server + devices to it, then you can use your existing QTcpSocket/QTcpServer code, as if the machines are connected to the same network switch in the same room.

Alternatively, telecoms companies also sell managed IP services where, for example, their special SIM cards can automatically connect a remote device to the same network that the server is on. This type of service is targetted at enterprises however, so I doubt that it's cheaper than a hosted TURN server.

[jars121]

That's brilliant, thank you @JKSH!

I'll go through the hole punching example you've posted.

I had originally considered a VPN approach, and spent some time looking into OpenVPN as a possible option. The main issue with using a VPN, is the computers running the client application need to remain on their standard networks; I can't tunnel all network traffic through the VPN. If there were an easy way of using the VPN only within the Qt application, and leaving all other traffic to the existing network then this might be feasible.

As for the 'special' SIM cards, I had also given that some consideration. In a previous job we had a setup similar to this, and it worked exactly as intended. However, for a host of reasons (including cost), that approach won't be suitable in this instance.

[JKSH]

@jars121 said in Using Qt sockets over the internet with NAT traversal:

The main issue with using a VPN, is the computers running the client application need to remain on their standard networks; I can't tunnel all network traffic through the VPN.

Look up "selective routing", e.g. https://serverfault.com/questions/134753/openvpn-and-selective-routing