CLDAP packet corrupted when Proxmox Windows VM tries to join AD Domain

[jbanham]

Hi folks,

We're doing some testing to explore migrating to Proxmox and have run into a strange issue that I can't seem to find any other discussions of. Hoping that someone in this excellent community can help to get me pointed in the right direction!

PROBLEM DESCRIPTION: Windows Virtual Machines deployed on Proxmox (tested with Win10, Win11, and WinSrvr2022) are unable to join an Active Directory domain (running outside of Proxmox). Lots of good troubleshooting info on these forums and elsewhere helped me to confirm that all relevant networking, dns, and security configurations were accurate and Wireshark traces show that the CLDAP packets leaving the Proxmox server and destined for the AD server are becoming malformed (and thus AD never answers).

ADDITIONAL DETAILS:

• Proxmox v8.3.0
• Active Directory running on Win Srvr 2019
• Windows VMs deployed outside of Proxmox (ie VMWare) can join the domain without issues
• Ubuntu VMs deployed on this same Proxmox host are able to successfully join the domain (although traces show that they use a simpler LDAP process with no CLDAP involved)
• Traces on the Windows VM show that the CLDAP packets are formed correctly when they leave the VM NIC
• Only when the packet traverses the Proxmox host does the issue occur - it happens when using Proxmox SDN networking (with or without SNAT) as well as when just building a simple Windows VM with the standard Proxmox vmbr0 interface of the host.

Here is a screenshot of the trace of the relevant packet when it leaves the Windows VM (and everything looks good):



The expected response is that one of the Active Directory Domain Controllers will respond with an LDAP searchResEntry packet and the AD join process then takes place. We don't see any response back from AD and it appears to be because when this same CLDAP packet traverses the Proxmox host on it's way out, there is some corruption of the packet (at least I think this is what the trace is telling me) Only the first 2 of the 4 assertions in the original CLDAP packet appear and then Wireshark notes the failed assertion/recursion depth issue:



As mentioned above, there don't appear to be any problems with networking, firewall rules, or DNS entries (the process works fine for an Ubuntu vm) but fiddling around with everything I can think to try to change has not yielded any other useful info or troubleshooting ideas. I'll be very grateful for any advice, ideas, or guidance that anyone might have!

 

[bbgeek17]

Hi @jbanham , welcome to the forum.

While this is outside of our area of expertise - Storage, diagnosing strange SMB/CIFS/AD behavior definitely scratches a familiar itch.

You’re correct that there are multiple network layers which the packet traverses. My first suggestion would be to capture traffic at multiple layers simultaneously:
- Inside the VM
- On the VM’s virtual port
- On any bond or team interface
- On the physical NIC
- And most importantly, at the Domain Controller itself

When reviewing the suspect packet, don’t rely solely on a protocol dissector. While useful, dissectors can be buggy or misinterpret edge cases, as your screenshot suggests. Instead, compare the raw byte/hex content directly across captures.

Also, check whether the packet length is identical at each capture point. From your screenshot, the packet is 211 bytes, so it’s unlikely to be fragmented, but it’s still worth confirming.

If I were in your shoes, I’d be most interested in whether the packet reaches the DC unmodified. That will quickly narrow down where the issue might be introduced.

PS also, ensure you have proper VIRTIO drivers installed in windows. You won't be the first person to run into an edge case between NIC and it's firmware.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[TC_Tecnet]

Which Networking stack are you working with out of the 5 options? You mentioned migrating so are these VMs running vmxnet3?

 

[jbanham]

Hi @jbanham , welcome to the forum.

While this is outside of our area of expertise - Storage, diagnosing strange SMB/CIFS/AD behavior definitely scratches a familiar itch.

You’re correct that there are multiple network layers which the packet traverses. My first suggestion would be to capture traffic at multiple layers simultaneously:
- Inside the VM
- On the VM’s virtual port
- On any bond or team interface
- On the physical NIC
- And most importantly, at the Domain Controller itself

When reviewing the suspect packet, don’t rely solely on a protocol dissector. While useful, dissectors can be buggy or misinterpret edge cases, as your screenshot suggests. Instead, compare the raw byte/hex content directly across captures.

Also, check whether the packet length is identical at each capture point. From your screenshot, the packet is 211 bytes, so it’s unlikely to be fragmented, but it’s still worth confirming.

If I were in your shoes, I’d be most interested in whether the packet reaches the DC unmodified. That will quickly narrow down where the issue might be introduced.

PS also, ensure you have proper VIRTIO drivers installed in windows. You won't be the first person to run into an edge case between NIC and it's firmware.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

Thanks very much for the feedback and advice! I don't yet have access to get traces on the AD server (we're an academic institution and things move slowly in the summer!) but I'll pursue that route. The idea about the VIRTIO drivers had me thinking that had to be it as my Windows VMs were all using the E1000 NIC. Unfortunately a clean build of a Win11 machine with the latest VIRTIO drivers installed and selected as the NIC did not show any change in the problem behavior - CLDAP packets all look the same in the traces leaving the Proxmox host. I'll keep plugging away and advise on anything new I can figure out!

 

[jbanham]

Which Networking stack are you working with out of the 5 options? You mentioned migrating so are these VMs running vmxnet3?

Thanks for the question! - I just responded to an earlier reply on the thread. I had been using the E1000 NICs and tried a clean build of a Windows 11 VM with the latest VirtIO drivers and the problem did not clear. I'm not having any luck trying to hot-swap the NIC to try the other 3 NIC types but I'll do a fresh build with each if necessary and see if anything changes.