Can you tell me what should i be looking on the remotit server side? If i move this router to a public ip and set port forwarding it is working all fine, but as soon as i move behind nat, it does not work thru remoteit. I have verified proxy connection address and port multiple times and it seeams there is an issue on the remoteit server side. Router accepts on port 51820 either udp or tcp.
What is the routing option you are using? (It’s under “Options” on the Service details view).
Try “peer to peer only” and “proxy only”. What is the result?
Can you SSH to this device using remoteit?
Get to a console on the device and run the following commands:
What is the result?
There’s a possibility that peer to peer connections won’t work here, in which case UDP will not work. If that is the case, then you can try configuring Wireguard to use TCP instead and then you’d need to configure a Service for TCP instead of UDP/Wireguard (use the “TCP” option and enter the desired port).
@piotrg were you able to get this working? Is this even possible?
I have a WG server on a remote rpi. Trying to connect from a local ubuntu as a client running through remoteit desktop doesn’t work. I should note that currently both the server and client are on the same local network using the same ISP. Testing without remoteit with both devices on the same local network is successful. So I know WG is working. SSH through remoteit also works fine.
I’ve attached screen caps and remoteit logs. As soon as I start the WG service on the client, I start seeing
80:00:01:7F:7E:00:82:51 !!status 308 seconds since startup lc=26 tc=0
80:00:01:7F:7E:00:82:51 !!throughput txBps=5 rxBps=4 80:00:01:7F:7E:00:82:51 pl=0 80:00:01:7F:7E:00:82:51 it=080:00:01:7F:7E:00:82:51
80:00:01:7F:7E:00:82:51 this should not be a possible state for UDP proxies
80:00:01:7F:7E:00:82:51 00318> !!status closeudptunnel=41, count=0 td=-1
And the client eventually disconnects from the remoteit service entirely, ie I get offline notification from remoteit until I stop the WG service on the client. Presumably because the client is trying to route local traffic through the WG VPN but failing?
I’m not sure that’s accurate. The screen cap piotrg posted only shows the client configuration. The listening port on the client is randomly generated on each service start. If in remoteit I add wireguard service with remote port 59820 mapped to local port 33000, I’d expect the endpoint in the WG config to be 127.0.0.1:33000 which should tunnel to :59820. I’m not sure how the listening port fits in. Maybe the issue is that WG actually needs two ports configured in remoteit?
I was unable to make connection with wireguard. I was able to connect successfully with openvpn by changing udp to tcp port. I think b/c remote.it does not support udp ports used by wireguard which I do not see an option to change from udp to tcp either.
Good to know. Thank you for the quick response. You are correct in that wireguard does not support TCP. I think using wireguard creates a sort of infinite loop where remoteit ends up trying to route it’s tunnel through the wireguard tunnel which of course is not possible because the wireguard tunnel needs the the remoteit tunnel to work. So it breaks.
Is there a better course of action to implement something like this? even without remoteit.
My use case is a remote rpi running rasbian lite installed on a 3rd party managed network that allows internet access only. In addition to ssh which works great with remoteit, I’d like to access devices on the remote network from my local desktop. I understand I can use things like x11 forwarding to use a browser on the rpi as a middle man to access other devices webadmin pages, and command line for telnet type things but I’d like to be able to connect directly from my desktop.
Now I’m looking at things like ZeroTier and Slack’s Nebula, or maybe tinc? Perhaps I’ll just switch to openVPN.
I am interested in the OpenVPN part. My VPN server is behind a router, and if I port forward on the router, I can connect to the VPN server, and browse the internet properly. When I connect via remote.it, without the router’s port forward, I can still connect to the VPN server, however, I cannot browse the internet on the client, and the client’s traffic goes crazy.
Do you have any idea where the problem lies? I suspect the problem is in the VPN config, as it is not prepared for such a scenario. In the log I have
Apr 9 16:31:50 ovpn_server_name ovpn-server: myPCname/127.0.0.1:35374 PUSH: Received control message: 'PUSH_REQUEST'
Apr 9 16:31:50 ovpn_server_name ovpn-server: myPCname/127.0.0.1:35374 SENT CONTROL [myPCname]: 'PUSH_REPLY,dhcp-option DNS 22.214.171.124,dhcp-option DNS 126.96.36.199,block-outside-dns,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 120,ifconfig 10.8.0.4 255.255.255.0,peer-id 1,cipher AES-256-GCM' (status=1)
The push reply from the server may contain config settings that are not valid for such a network layout. Could you please share your VPN config file? And also maybe the push reply, if you have any?
Granted I didn’t invest a ton of effort, but I was never able to get wireguard to work through remote.it. Probably a lack of my current networking skills. I did get openvpn with tcp connection working fine.
One thing that’s different is for some reason the default config wasn’t using port 443 instead of 1194. Perhaps choosing TCP instead of UDP caused that. Regardless, I had to check the port openvpn was listening on and update the remote.it desktop app config on the local machine.
I chose TCP because of reports UDP didn’t work. I’ll probably switch to UDP now that I know it works.
As always, @gary your assistance is much appreciated.
Here’s my working openvpn server config for anyone interested:
server 10.8.0.0 255.255.255.0
# Set your primary domain name server address for clients
push "dhcp-option DNS 188.8.131.52"
push "dhcp-option DNS 184.108.40.206"
# Prevent DNS leaks on Windows
# Override the Client default gateway by using 0.0.0.0/1 and
# 220.127.116.11/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
keepalive 15 120
status /var/log/openvpn-status.log 20
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device.
and the client config:
# mapped to port 33001 in remote.it desktop app
remote 127.0.0.1 33001
verify-x509-name <redacted> name
<redacted certs/keys here>
Strange, I have the same settings, but it still doesn’t work. I can connect to the VPN, and today, the only problem is that I cannot reach the internet, if log in via the help remote.it. The server confirms that the connection is established. The firewall on my Windows is turned off. Once connected, I cannot ssh into the server via it’s VPN address 10.8.0.0. However, the connection breaks every ~ 3 min. As there’s no proper internet, remote.it also stops working properly.
If I do it with a port forward on the router and connect to the port directly without remote.it, the VPN connection is not only established, but Internet works, and IP shows as the servers. SSH also works properly via remote.it, without VPN.
Windows’ ipconfig when it is connected to the VPN: