VPN with remote.it

I have numerous smart devices in my house that can only be controlled via mobile apps.

I am using remote.it via my Raspberry Pi connected to a cellular modem and my internal LAN for out-of-band access in the event my cable modem goes down. The cellular modem doesn’t have an accessible public IP.

Is there a way I could configure remote.it to act as a VPN server? My goal would be to start the remote.it connection, and while connected, have all traffic from my phone be routed to my internal LAN over remote.it.

The goal is to be able to reset power outlets to cycle devices in the event of a problem.

Thank you!

Hi Bryan,

By default, a remote.it connection uses a single TCP port. Some people have used this with OpenVPN (which needs to be configured to use TCP instead of UDP which is the default).

Then you’d need to make a connection at your client end which gives you a hostname and a port. Use that in your OpenVPN profile and you should have OpenVPN operating over remote.it.

The connections you make through the web portal are “proxy” connections and will disconnect and expire after 15 minutes of inactivity. Our desktop applications use peer to peer connections which do not expire in the same way, however you need to know that sometimes these don’t work if one or both ends are on a cellular connection. The only way to really know would be to try it.

Let me know if you have any other questions.

Thank you Gary, I will give it a try

Hey there @bryan3301, did you manage to figure this out?
Since p2p connections are binding to a local address (127.0.0.1), my openvpn client has issues connecting, I’m guessing the issue has to do with traffic being rerouted but I don’t have the networking knowledge to figure this out.
Looks like the connection is established but it’s being restarted because of a warning.

TCPv4_CLIENT link remote: [AF_INET]127.0.0.1:33100
WARNING: Bad encapsulated packet length from peer (29285), which must be > 0 
and <= 1544 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- 
this condition could also indicate a possible active attack on the TCP link -- 
[Attempting restart...]
Connection reset, restarting [0]