U.Ho

How do you measure your ping? Ping is actually latency and it's always against some destination server. Latency is increased by any active device between your NIC and the destination server, and thus the issue could well be in any of them. You can get a latency value for any layer 3 device between your NIC and the destination server by running a traceroute. I say "a value" because they're not always accurate since ICMP responses are not a priority to network devices. So, back to it. How do you measure your ping?

Ok that's a bad quote but can't be arsed to fix it. Have you tried .\username? (that's dot backslash) This is something I use at work to connect to remote machines with local credentials although it actually picks your localhost as domain.

Have you tried to replicate the issue with an empty or nearly empty drive? That might get you either the answer or a way past this particular suspicion. Also, if you're thinking it's a drive indexing issue, how come is this posted in a networking forum?

LACP works for up to 16 ports. Throughput with LACP is going to vary, since one conversation will always be carried out through one port. In order for you to benefit from 4 ports you need at least 4 clients accessing the server at all times with more than half of the bandwidth of one connection.

It's no use guessing. ipconfig /all shows your default gateway, which is your router's IP address. If you don't have one, try rebooting your router in case it's in a knot or two.

Any antivirus softwares? Avast? Have you tried uninstalling that? It's not a "known issue" per se but might be worth a try.

Why did you connect the ESX in a wan port? Is it in a different network than your VPN clients? Can you connect to the windows server network via your LAN (or the network where your VPN clients are)? Can we have some IPs so it's easier to picture the layout?

Based on the info you have given, this looks like a server issue, not a network issue. We don't currently have any grasp on your network and how it does or should function except for the virtualized portion in the ESXi which is very simple if you didn't do anything to it.

Ok. By "lan activity" I mean do you use your LAN? Do you for example have a file storage server or do you stream much to your other computers? Basically with internet connections your bottle neck is always the ISP connection. That's unless you're paying for over 1 Gbps connection where your LAN starts to come into play. It's likely that you do not have over 1Gbps internet connection so in order to benefit from the two LAN ports speed-wise you would have to be doing something heavy inside your home network. My guess is you don't need it. And if you don't know what I'm talking about, I know you don't need it.

But you actually did watch the video or else you wouldn't have known this: I think we still need more input from the op. What are his goals network-wise? Is he just connecting to internet or does he have some LAN activity going on?

Before you do, if you have windows 10, you could try uninstalling the network adapter drivers and rebooting the computer. That will reinstall the drivers and it might fix the issue if it's driver related. A windows reinstall will do the same but with a lot more work. Do you have working computers in the network? Did you check the router DHCP settings?

Well, the issue seems to be that you don't get an IP address from the router at all. The IP 169.254.x.x is a link-local address and you having that indicates you don't get an IP from DHCP. Try checking the router settings and make sure you have DHCP enabled and a proper IP pool that is also not fully leased. Then on the host machine you can either unplug and re-plug the ethernet cable and/or do a ipconfig /release followed by ipconfig /renew in command prompt. This forces a DHCP renegotiation when DHCP is available.

Did you ever check where the spikes originate at? Router? ISP? Host? And how did you do that?

You need a remote connection of some sort. If you want to use windows command line remotely, I don't even know if there's a possibility for that. Remote desktop connection is what I would go for in this case, or if you need multiple connections at once, maybe VNC or something. Might try even NetOP, though that's old and clunky. These are all protocols to get you to the desktop of the windows machine. From there you can always open cmd if you really need to type in your commands...

That's right. Of course you'd need to be able to sniff some traffic of the network in order to interrupt it. Depending on the security of the wifi network, it could kinda be a prerequisite to actually be connected to it in order to do anything meaningful though. I've done some exercises where I would record some of the traffic, find a login negotiation, take the password hash and decrypt it with rainbow tables (or just plain bruteforce but that can be slow) and then, when actually connected I would send some modified packets to do this or that. Mind you, this was in a controlled environment where I didn't actually attack anyone else than myself. Now, the first part of recording the traffic does require monitor mode if I understood this correctly. Never thought of wifi modes when I was doing this...