ooooooiiii im back.
So this rears its ugly head again.
I use torguard VPN. Like most VPNs it intentionally increases its interface metric to ensure traffic goes over the VPN as to prevent leaks.
No harm no foul. Until of course, I try to use multiplicity to wake on lan. Once again, everything can wake the other pc's on the lan fine EXCEPT multiplicity.
I went through a bunch of troubleshooting with the torguard support and it boiled down to it being a problem with this software. What is it doing differently than basically everything else? I can ping other pc's, i can seamless to other pc's, I can wake other pcs from any app even the most rudimentary EXCEPT this when ANY other adapter has the same or higher metric than my ethernet adapter.
Can we not force this to stop trying to send from whatever has the highest metric and/or ignore virtual adapters? it should be sending the broadcast via the physical adapter same as everything else uses?
The only fix for this is now is on your end this time. Nothing they or I can do. I can change the interface metric and get it working again, but id have to do it EVERY time i used the vpn as each time you disconnect and re-connect it re pumps up its interface metric for the aforementioned reasons.
As it sits, im just dealing with it for now. Ive been only using my vpn situationally but was considering using it full time. Cant really do that now. Just wanted to bring it to your attention. It shouldnt be trying to send via virtual adapters, its the only software ive tried and i have at least a half a dozen i can use real-time right now and list that work fine under the circumstances that this wont.
Everything else has been rock solid with it ever since though. Love it, and would love to see this fixed. its cumbersome and honestly (please dont take offense) it feels amateur (the bug. the software is incredibly comprehensive). If i was a developer and I took pride in my work (i wish i was, man did i pick the wrong career path) and I saw that everyone elses software not only worked, but did things a certain way - id probably assume there was a reason for that and follow suit.
Of course, being wholly ignorant of the goings on under the hood - there could be a legitimate reason for the deviation.
Still im the case study proof that it presents issues, and have examples of several reproducible circumstances in which it does so.
If you have any questions, will obviously be around. Dont hate me for being critical, you get paid to fix bugs right 
Contrary as it may seem, i truly do love the software, hence wanting to see it improve. (unless its EoL then squash my dreams)
Worst part is it has become evident that the behavior surrounding this wake on lan debacle had forced me to disable automatic metric handling for just about every adapter and jostle things about when that was a hacky workaround for what appears to be a deviation from the norm or bug on your side.
In a perfect world with the app receiving a small update to address the incorrect selection of network adapter to broadcast from, i could set them all back to automatic and let windows put things back as they should be. No idea though, never had to mess with it before.
