I have very far physical PC running on W10 that sits behind a 4G router (teltonika Rut955) with public IP. The rut955 has a running and configured OpenVPN server that I was using to access the PC with TightVNC through the VPN.

The original LAN configuration was:


The OpenVPN server was running on with the push route option set to So I could connect through VPN to the PC.

As thightVNC was the ONLY way to access that PC I was trying to set another one, SSH. And as my skills with windows admin are so low I was trying to set a WSL2 and place inside it the SSH server that will allow me to manage files inside the PC.

Once I had debian installed on WSL2 I noticed that the WSL instance didn't have internet connectivity and it wasn't directly accessible neither, instead the W10 was running as router/nat for the WSL. In order to make WSL directly accessible I followed this:

And here are were problems start. Instead of clicking into the pyshical adapter and share it with vEthernet (WSL) I did it the other way around. I clicked on vEthernet (WSL) adapter and in "Home networking connection" I entered my physical ethernet connection. I was stressed and didn't read carefully, so I'm not 100% sure but I think so.

After that, popup appeared telling that the address was going to change to As I was making changes on the vEthernet (WSL) adapter and not the physical one I clicked continue because I thought it was referring to the WSL address. It wasn't. I lost connectivity instantaneously.

After that I changed the rut955 ip to and changed the push option on the OpenVPN server to But no ping through the VPN. I supose because the PC has no gateway configured.

If I ssh into the Rut955 I can ping the PC. Also, if I scan the network through Rut955 GUI, there it is the W10 PC.

Then I proceed to forward all the ports from the router wan to the PC and tried to vnc to the public rut955 IP. That fails too.

How can I recover my vnc connectivity to the W10 PC?

EDIT for @user1686 answer:

Thanks for your answer. I'm not an expert at all in networking so I have been reading about your answer for a while on the internet.

For the option A: I don't know if I have understood your answer correctly but isn't the Rut955 IP but the current PC IP. I had already forwarded through the Rut955 GUI the wan port 5900 (the vnc port, tried also with 0:65535) to the the PC ip (

I have studied it deeper and seems that the router GUI works on top of iptables. I have never worked with iptables directly but doing a little bit of research iptables -t nat -L returns:

DNAT       tcp  --  anywhere             anywhere             tcp dpt:5900 /* emergency */ to:
DNAT       udp  --  anywhere             anywhere             udp dpt:5900 /* emergency */ to:

So it seems that the router GUI creates DNAT. Should I replace it with a SNAT? Also I'm not sure at all between what IP's I should do the SNAT...

For the option B: Excuse my ignorance, but does this solution works if there is no SSH server on the PC? Actually, there is one, openSSH for windows, but the only windows user that exists has empty password...

  • 1
    You are aware that Windows has an optional built-in OpenSSH Server? It’s much easier to configure, compared to configuring WSL to a static network configuration, and configuring OpenSSH to run within it. As for fixing whatever is wrong, no idea, this is just an observation
    – Ramhound
    Commented Jan 18, 2023 at 13:17
  • Yes, there is one but I can't access because the single W10 PC user has empty/no passord. I have installed at first but ditched it because I preferred to have GNU utils. I would miss them too much SSHing into a W10 machine. I have no idea what are the W10 commands to edit, create, remove files and other tasks.
    – Héctor
    Commented Jan 18, 2023 at 15:41
  • A user without a password would have been fine provided you disabled password authentication, and use key authentication, thus would have protected the system from unauthorized access.
    – Ramhound
    Commented Jan 18, 2023 at 15:45
  • Yep, but I wasn't expecting to lock out myself.
    – Héctor
    Commented Jan 18, 2023 at 16:01

1 Answer 1


A gateway is not needed to reach addresses that are on the machine's own subnet, so you need to find a way to make your VNC connection appear as if it's coming from the router's LAN IP address instead of your own VPN address:


Add an SNAT rule on the router (for packets output through the LAN interface – i.e. the opposite of typical WAN SNAT/masq rules), so that packets from VPN clients to the LAN will appear as if they're coming from the gateway's own address (which is "local" to the PC).

  • For iptables:

    iptables -t nat -I POSTROUTING -d <pc_ip> -j MASQUERADE


    iptables -t nat -I POSTROUTING -d <pc_ip> -j SNAT --to-source <router_ip>

Note that "Port forwarding" is not SNAT – it's DNAT (as it rewrites the destination address rather than the source). SNAT is what residential routers typically use for packets going out to the WAN interface, masquerading them with the router's public IP; in this specific case you want to apply it in the opposite traffic direction (from router to LAN).


b) SSH tunnels

SSH to the router and configure a "local" tunnel for RDP (using the -L option of ssh.exe or plink.exe). On the remote side, it will look like the router itself is making the RDP connection.

  1. Locally, use ssh <router_ip> -L 3390:<pc_ip>:3389 (or the same with plink.exe, or configure the equivalent "local tunnel" in PuTTY).

    ssh <router> -v -N -L 3390:

    This will make the SSH client listen on port :3390 for connections, which will then be forwarded to <pc_ip>:3389 from the router's SSH server. (The listen port can be chosen arbitrarily, as long as it's unused on the local machine.)

  2. Locally, connect via RDP or VNC to localhost:3390. The connection will be proxied to the remote PC, which will see the router (whose address is "local") as the connecting client.

b.1) SSH tunnel to IPv6 address

Even if the machine no longer has a (known) IPv4 address, generally it will still have at least the "link-local" fe80::* IPv6 address. (Link-local addresses have a static prefix so they exist independently of whether the LAN has any form of IPv6 connectivity.)

  1. Try to find the machine's IPv6 link-local address in ip -6 neighbor (ip -6 n), or by watching network packets using tcpdump. The machine will likely send out some ICMPv6 packets every now and then; if it's Windows, it may also send mDNS or LLMNR or WS-Discovery packets.

    # ip -6 n
    fe80::6e3b:6bff:fec0:bf dev wlan0 lladdr 6c:3b:6b:c0:00:bf REACHABLE 
    # tcpdump -e -n -i eth0 "ip6 and not port 22"
    [wait for a familiar MAC address to show up...]
  2. Once found, configure an SSH tunnel for that address.

    ssh <router> -v -N -L "3390:[fe80::abc:def%eth0]:3389"

    Note the [brackets] around the address are required (to delimit it from the port number).

    Also note the %eth0 – link-local addresses must be specified with the "zone ID" which is the interface name or numeric index. Since the actual connection will be initiated by sshd from your router, you need to specify this from the router's point of view (not your local machine's). In this example, the router will connect to fe80::abc:def over its eth0 interface.

  3. Connect via RDP/VNC/etc. to localhost:3390 as before.

  • Thanks for your answer, much apreciated! I have edited my question with an "answer" to your answer.
    – Héctor
    Commented Jan 18, 2023 at 15:33
  • I didn't say anything about connecting over SSH to the PC – you connect via SSH to the router and use that as a tunnel for arbitrary TCP connections to the PC. Commented Jan 18, 2023 at 15:40
  • 1
    I have been able to make it work with the option B. I connected through VNC and restored IP settings, everything worked. Then I tried again to do the step I messed up but in the correct way this time and very careful for any alert message. But this time I have lost connectivity without any previous notice. The worst is that now the PC doesn't appear on the network nor the one. I don't know if it's windows fault or mine but I feel like an idiot right now... Is there anything that can be done?
    – Héctor
    Commented Jan 19, 2023 at 11:40
  • 1
    Nope, nope and... nope. I suppose that's a bad thing.
    – Héctor
    Commented Jan 19, 2023 at 14:18
  • 1
    Practically nothing, it would only make it easier to distinguish the host's packets among others in the ip/tcpdump outputs. Commented Jan 19, 2023 at 15:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .