I'm not sure what you mean when you say "local client." Is this another VM on the same network on the same host? Is this another VM on a different host? Is this another server or desktop in the data center? Is it on the same network? "local client" doesn't describe anything meaningful to troubleshoot with.
Additionally you keep saying that you can't reach a VM after the reboot, and then say you can reach a VM after the reboot. Again, are these different VMs? Where are they located? Do you have more than one ESXi host or just one?
The best I can glean and tell you from this is that you rebooted your host and the network reachability state changed. My guess is that you have a single vSwitch with active/active NICs load balanced based on virtual port ID, and the pinning changed after the reboot. Again this would indicate a problem with the upstream switch configuration. My best guess: either the ports are configured differently instead of identically, the ports are in a port channel when they should not be, or the ports are attached to different switches and the switches have different configs for either the server ports or the upstream uplink ports.
In other words, if your ESXi host has 2 active ports that it can use for traffic for individual functions (VMs or vmkernel for management, vmotion, etc.), once a function is pinned to a port, it won't actively change unless there is a fault. If one of your ports is connected to a switch with a good config, and one is connected to a switch with a bad config (or one port has a good config and one has a bad config), then anything pinned to the good port will work and anything pinned to the bad port won't.
If you have access to the upstream switches I would verify the config (or get a network guy to verify the config). If not you can test this by:
1. Creating a new VMK port on this same network and assign an IP.
2. Edit the VMK port (not the vswitch itself), override the switch NIC teaming settings, and assign one NIC as active, one as standby, and apply the change.
3. Check reachability of the IP address
4. Edit the VMK port, assign standby NIC as active, active NIC as standby, and apply the change.
5. Check the reachability of the IP address
If it is reachable with one NIC active but not the other NIC, then you know which path is the problem.
Edit: again just to reiterate, testing from a VM on this same host on the same network won't validate anything because this traffic won't actually exit the ESXi host. It will be locally switched on the vSwitch. You will have to validate with something external, either on the same subnet or different subnet (preferably both).
