External RDP settings

[Pierro]

I have a Proxmox VE8 virtualisation system with several VM's and Containers. I am really happy with everything, loving learning docker but it would be very helpful to be able to externally connect to a Windows 10 Pro VM I use.

I am able to connect using RDP to the Windows 10 VM (192.168.0.251/24) from another windows machine on the same network.

I have disabled the firewall on the W10 VM for the purpose of testing.

Port forwarding is set up on the router and and works fine with a physical machine (192.168.0.222/24) But I am unable to get to the VM.

I figure it must be something to do with a firewall on the Proxmox Server (192.168.0.244/24)

This is what I have for my interfaces file

o lo
iface lo inet loopback

auto enp6s0
iface enp6s0 inet manual

iface enp5s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.244/24
        gateway 192.168.0.1
        bridge-ports enp6s0
        bridge-stp off
        bridge-fd 0


post-up iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j SNAT --to-source 192.168.0.244
post-up iptables -t nat -A PREROUTING -d 192.168.0.244/24 -i vmbr0 -p tcp -m tcp --sport 1024:65535 --dport 3389 --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DNAT --to-destination 192.168.0.251:3389

It is probably wrong but it's my best attempt at pushing my knowledge.


Where am I going wrong?

Thanks very much!

 

[LnxBil]

Why the POST and PREROUTING rule? If everything is in the same network, you don't need any rule.

 

[Pierro]

Novice trying everything. Not in the same network. I am coming from the outside via a Port Forwarding rule.
As I say, inside on the same network is fine. Outside to standalone W10 box is fine, Just the option with the Proxmox VM

 

[LnxBil]

Outside to standalone W10 box is fine, Just the option with the Proxmox VM

The network is normally bridged, so it should not matter where you are (outside or inside of PVE). Unless you configured a special firewall rule, the connection is allowed from everywhere or denied from everywhere, so the problem is probably not firewall-related if you have not configured anything.

Now to the rules, they don't make sense:

iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o vmbr0 -j SNAT --to-source 192.168.0.244

This source nats every connection from your local network to the IP of your PVE box.

iptables -t nat -A PREROUTING -d 192.168.0.244/24 -i vmbr0 -p tcp -m tcp --sport 1024:65535 --dport 3389 --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DNAT --to-destination 192.168.0.251:3389

The flags are "and"ed. Such a package with all the flags does normally not exist.


Maybe I spotted your error in reasoning: have you port forwarded the port to your PVE host or to the IP of your VM? The later would be correct.

 

[PMoxL1]

Thanks for the information, really useful from a learning perspective. I think I just got myself in a ‘what else can I try’ situation.

Regarding the Port Forwarding, it is indeed forwarded to the Window VM rather than the PVE

 

[LnxBil]

Thanks for the information, really useful from a learning perspective. I think I just got myself in a ‘what else can I try’ situation.

Next thing is the swiss army knive: the shark-family. You need to know where the error is, so please install tshark on your PVE host and run it like this:

tshark -i bond0 port 3389

and try to connect from the outside to your VM.

 

[PMoxL1]

Not sur if it helps to know, but I can’t connect RDP to rhe VM using my Cloudflare Zero Trust tunnel either, whereas otherVM services, albeit they are docker containers and a web server.

 

[scyto]

given RDP should never be port forwarded on to the internet (trust me I used to be the product manager for it) you may have someone else in your network path blocking it (isp or cellular provider). Also modern RDP operates on both TCP and UDP if you have not cleared both protocols it can sometimes cause issues. Attempt a true VPN or tailnet and see if you have the same issue.

 

[PMoxL1]

Thanks. It’s only port forwarded to troubleshoot ahead of a permanent tunnel solution.
As I mentioned 3389 is fine on a physical machine just not the VM.

I’ll have a look at tshark later. Appreciate that, thanks.