Tunneling into a labrad computer with dynamic ip

[zibrov-zlobin]

Hi guys,
I'm not sure this is the right place to raise an issues since its not really an issue. But I was wondering if any of you had any experience setting up a tunnel, say ngrok-like or similar to connect to labrad?

the problem is that we often end up measuring not in our lab but in shared facilities. We run labrad on a laptop that is usually connected to a wifi like eduroam. Have you had any experience/success in accessing the labrad manager remotely in this case? My most simplest attempt in using the free ngrok to create a tunnel didnt work, either because the free version doesnt support TLS or because its a stupid idea in the first place. Seems like it should work easily with any web-interface easily.

I guess the alternative is to setup a VPN connection to the remote computer.

And on a related topic: when setting up a remote connection I always end up editing /etc/hosts to create an alias for the remote labrad ip address. Is there a way to connect to generate a proper self-signed certificate based on IP address? Googling showed that it is possible but not very used often and could be done by adding an "alternative name" in the openssl request. But I am not sure if this is the right way to go around it.

Any recommendations/best practices would be great!

[clayton-ho]

This is many years late, but I was trying to do this as well and just figured it out.

If your router supports NAT forwarding (basically accessing the local network when outside it), you can set up port forwarding/triggering or a virtual server (this is pretty easy with tp-link routers, i think), allowing you to connect to certain ports (i.e. the labrad host port on whatever device your manager is running on).

Ideally, you'd want to make the external and internal ports the same (i.e. both 7682, which is the default port for labrad). For the host IP address/LABRADHOST value, you would set it to the IP address of the router.

However, this is bothersome since the manager has myriad issues with accepting nonlocal connections (nonlocal connections have to use TLS, but TLS connections don't really work), so what I do instead is this:

• set up port triggering on a different port on the host computer (e.g. 8682)
• use a port forwarder (e.g. this one) on the host computer to send messages from the forwarding port (e.g. 8682) to the labrad port (i.e. 7682).

this makes external connections look like local connections, bypassing the manager's issues with nonlocal connections