How to recover connectivity to remote PC after messing IP settings sharing vEthernet (WSL) adapter to my physical one instead of the other way around

Question

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:

Rut955: 192.168.2.1 255.255.255.0
PC:     192.168.2.3 255.255.255.0

The OpenVPN server was running on with the push route option set to 192.168.2.0 255.255.255.0. 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 192.168.137.1. 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 192.168.137.100/24 and changed the push option on the OpenVPN server to 192.168.137.100/24. 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.

192.168.137.1
XX:XX:XX:XX:XX:XX
DESKTOP-9V9NTVH

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 192.168.137.1 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 (192.168.137.1:5900).

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:192.168.137.1:5900
DNAT       udp  --  anywhere             anywhere             udp dpt:5900 /* emergency */ to:192.168.137.1:5900

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...

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:

a) SNAT

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
  

  or:

  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).

Or,

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:192.168.147.5:3389
   

   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.