Port 1883 Tunneling through VPN

[brianskurtz]

Hi Gang,

Using ZeroTier effectively to get Remote Desktop on a distant machine (more secure through a VPN). My question is, I have a communication protocol I want to use locally to access a computer on the other end of the VPN with a Static IP at Port 1883.

Is this possible? Do I need to use the ZeroTier IP instead of the 10.101.x.x I’m using on the secure network? If not inherently possible, is there a way to allow specific ports to target the remote network?

Thanks,
Brian

[pc.00000]

Can you clarify this a little bit?

If the local and remote machines are both authorized members of the ZeroTier network and each have a “managed IP” address in that network, you should be able to just use the remote computer’s “managed IP” address and the port you want to connect to.

For example, you can SSH into a remote machine with ssh user@zer.oti.era.ddr:22 (assuming the remote machine has an SSH server) where zer.oti.era.ddr is the “managed IP” listed for that member in your ZeroTier network.

Other port numbers should also work as long as the remote machine is listening. But I might not be understanding your situation correctly. It’s not clear to me whether 10.101.x.x is your ZeroTier network range or a LAN range on the remote end.

[brianskurtz]

See, what you said makes sense, but I’ve tried that. Here, I’ll clarify:

Machine A is in another state, on a 10.101.x.x network, running ZeroTier and a service called MQTT which listens on Port 1883. From that local network, I can connect to that service using MQTT Explorer, and see what traffic is flowing through that protocol.

Machine B is my Home Desktop, running ZeroTier, on the same “network”. From HERE, I can’t get MQTT Explorer to see the service on port 1883 over ZeroTier, even using the Managed IP…

(TBH, I’ve tried this with other VPNs as well, so it’s either the unusual port or the unusual protocol (MQTT)…)

[l0crian]

A couple thoughts:

• It’s possible that the service is not listening on the ZeroTier interface.
  • You can try to see if the service is listening on port 1883 for all interfaces (e.g. 0.0.0.0), or just the specific physical address that you’ve been able to get working before.
  • You can use something like netstat to see listening ports. You can also use something like NMAP to see if the ports shows open from the remote site.
  • If it is not listening on the ZeroTier interface, then you will need to see if the service has a configuration option for that.
• If the traffic is using SSL, it could be some common SSL issues:
  • MTU issues:
    • You may be trying to push a packet through ZT that is larger than the allowable MTU on the underlay. This would cause fragmentation, which will usually kill SSL traffic.
  • Time Drift:
    • If the 2 devices are not within a reasonalbe amount of time drift from each other, then that will also cause issues with SSL.
    • You can make sure both devices are on the same NTP to resole this.

[brianskurtz]

Good Sir, you win! I was not accounting for the fact that it was only listening on 10.101.x.x (actually to the computer’s internal IP) and I’m not used to VPNs yet. I had stupidly assumed that anything sent over the VPN popped out on the 10.101.x.x network and I could address things as such.

As soon as I asked it to listen on 0.0.0.0 it worked, so I went back and added BOTH the VPN address and the local computer address (so we don’t get anything from the wider Internet) and now we’re golden!

Five Stars!

[l0crian]

Awesome, glad you got it working!