In another post I explained we use NAT to make Wake On LAN (WOL) work. WOL has successfully worked for the last few months. Our SCCM administrators use ‘right-click-tools’ to wake machines, this worked fine until a project was started to utilize Zero-Touch installations. SCCM has a feature to schedule a WOL and reinstall a client. When scheduled computers would sometimes not wake up when the SCCM build-in tool was used.
We had three scenarios on our hands:
- NirSoft WakeMeOnLan always works.
- WOL, as implemented by SCCM Right click tools, works.
- SCCM build-in WOL works most of the time.
So, why doesn’t the Microsoft implementation of WOL function and how is it different?
A packet-capture on the firewall taught us that some of the WOL traffic was being dropt with four different reasons:
When you google that last error you will find a page explaining that: if you use NAT and two sessions are identical the session will be dropt because you can’t override an existing session. See: https://live.paloaltonetworks.com/t5/Learning-Articles/Session-setup-fails-due-to-session-hash-collision-error/ta-p/70539
This brings the question: are the session used by Microsoft identical? A packet-capture shows that yes, WOL session created by Microsoft ‘s implementation in SCCM can be seen as identical. Every request uses the same source port and, because it’s a targeted broadcast, the same destination IP:
NirSoft WakeMeOnLan uses a different source port for every WOL request:
Right-click-tool uses a different source port for every WOL request:
I’ve tested some other WOL tools but Microsoft is the only one not using source port randomization. We have yet to find a final solution but will probably just continue to use right-click-tools.