RDP with NAT/RAS Stops Working when Running WinDivert

[jjxtra]

Running WinDivert and using filter inbound and tcp.Syn on network layer. I call WinDivertRecvEx and WinDivertSendEx to pass packets on through - very simple code, nothing fancy, just testing WinDivert will work.

I am using NAT and RAS for Windows to connect to RDP. When WinDivert is opened successfully in my console app, new RDP connections fail with a timeout error. Is there something in the WinDivert code that might get tripped up when using NAT and RAS on Windows? I see some packets from my ip in my logs, but I am not sure if those are RDP syn packets or not as the dest port is not 3389...

If I run my same WinDivert filtering code on another server that uses RDP directly without NAT and RAS, RDP works as normal, although again I still don't see any port 3389 in the tcp headers...

EDIT I verified this with passthru.exe (default params, and using filter (inbound and tcp.Syn) or icmp on both boxes and same issue happens, unable to RDP with NAT/RAS but able to RDP just fine on the other box. My custom app was not running at the time.

[basil00]

I assume that passthru.exe did not report any error?

One thing you are try is running netdump.exe with a lower priority than passthru.exe, but with the same filter. Are the re-injected SYN packets detected and printed by netdump.exe?

[jjxtra]

No errors from passthru.exe. Attempting your suggestion soon, will report back

[jjxtra]

@basil00 tests are completed. Expected packets are seen when running passthru and netdump with the expected source ip, dest ip and dest port. However running passthru.exe still causes rdp to fail with timeout.

Running netdump.exe by itself without passthru.exe allows RDP to succeed, but this is not a surprise due to the sniff flag in the netdump.exe application.

It appears something with pulling packets out and re-injecting them breaks RDP with NAT/RAS, not sure why...

[TimesliceTechnologies]

@basil00 I am the end user working with jjxtra and his application. It would seem helpful for me to provide some direct info on the affected systems. Details and netdump log below.

Hyper-V environment with two Win2019 VMs: BACKUP and VPN
BACKUP:
No public facing IP address
Has internal address 10.0.100.2
RDP is listening on port 20001

VPN:
Public IP address with RDP listening on port 10001
Internal address 10.0.100.1
RAS installed with NAT and Port forwarding
In RAS/NAT, port 20001 is forwarded to 10.0.100.2 (BACKUP) port 20001

Symptom:
Run on VPN:
passthru.exe "inbound and tcp.Syn"
Attempt to connect via RDP to BACKUP via VPN public IP, port 20001
RDP connection times out / unable to connect.
It appears nothing is listening on port 20001
RDP connectibility returns when we end passthru.
This may affect other forwarded ports / services and RDP is just an example.

Netdump log:
While passthru.exe "inbound and tcp.Syn" was running I executed:
netdump.exe "inbound and tcp.Syn" -400 > dumpWithPassthru.txt
dumpWithPassthru.txt

Fundamentally, it feels like there is some issue with RAS/NAT/Port forwarding.

[jjxtra]

@basil00 I'd be willing to pay to help get this figured out, please let me know if you have bandwidth for such a thing

[basil00]

My bandwidth is extremely limited these days.

Did you also check if the SYNACK was ever generated? It may be some weird NAT interaction, but I do not have any great ideas on what the problem could be.

[jjxtra]

@basil00 There are no syn ack for port 20001, but there are some syn ack on other ports. Curiously it's only the RDP traffic that is impacted. Regular http(s) calls and other calls still work fine.

Also, with passthru.exe NOT running, there are still no syn ack calls on port 20001.

[basil00]

Also, with passthru.exe NOT running, there are still no syn ack calls on port 20001.

You mean if only netdump.exe running there is no SYNACK? This would be very strange, since the WinDivert driver would not block the original packet at all.

[jjxtra]

@TimesliceTechnologies Can you confirm that just running netdump.exe by itself allows rdp or not?

[TimesliceTechnologies]

RDP works as expected when only Netdump.exe is running as I recall.
RDP fails however when running PassThru.
The log I uploaded to this thread was from Netdump when PassThru was running.
I did not upload a netdump log to this thread when passthru was not running.

[basil00]

If netdump still works then this is the expected behavior, although this does not help diagnose the problem with passthru and RDP.

Unfortunately, I cannot offer much help. Since the problem is protocol specific, it may the the interaction with WinDivert and some other firewall/driver/filter/etc installed on the system. The interaction with the NAT is another interesting clue, but I cannot see how that would cause the problem, since the filter is on the inbound path.