Cannot access vSphere Web Client on secondary management VMkernel with overridden default gateway

[MarcLaf]

I can't seem to figure out what is causing this problem as documentation does not cover it directly.

If I add a new VMKernel adapter and enable Management service, and this adapter is on a network that requires a different default gateway than the default tcp/ip stack, I can override it in the VMKernel settings. Once I do this, I can ping this new IP address but none of the management services are available (ie accessing the IP for web client doesn't work, testing with CURL to ports 443 or 902 fail). 

The Firewall on the ESXi host has not been changed (default allows all IP ranges).

I cannot modify the IP/VLAN via DCUI because it's greyed out (I assume this is due to the use of a Distributed vSwitch?).

It makes no sense that ping works but the other ports do not. Is there something unique about the management services that ignore the override default gateway property?

I also tried creating a custom TCP/IP stack with the new gateway but found that you cannot assign system services (ie management) to a custom stack.

[ManlioFrizzi]

Hello,

does this help you https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-networking/GUID-44CAFD7C-6352-4993-A461-A27EE1C7D940.html

Manlio

[MarcLaf]

Hi @ManlioFrizzi, thanks for the reply. Unfortunately, that's for vMotion and not for management. I had to do another workaround to get this all changed and could not do this method for the reasons listed in my original post. 

[ManlioFrizzi]

- Did you adjust the MTU on vSwitch0, vmk0, or anywhere else? I have seen very similar behavior when the MTU is increased for jumbo frames, especially when a step is missed and/or not all network devices have jumbo frames enabled. 

- Did you check VLAN configuration?

------------------------------
------------
Manlio
PMP®-PMI, Azure & AWS certified, VCP34562019/21 DCV VCAP5DCD, vExpertx10, RHCVA
------------------------------

[MarcLaf]

Hi @ManlioFrizzi

No, MTU was never changed (it was always 1500). And yeah VLAN configs were all correct. It was definitely a weird incident.

I eventually got this all figured out via different method so this case isn't relevant anymore (other than for curiousity).