DNS/AD issue causes misery at the NSX level

[rikherlaar]

NSX for vSphere: recovering from Distributed Firewall vCenter lock-out | Telecom Occasionally

An excellent paper still , I'd also like to add that it's a good idea to move your DNS/AD servers out of harms way if you decide to play around with SG and Firewall rules - losing these systems proofs very dangerous and your mileage may vary if you inadvertently isolate these services from vCenter and NSX mgr.

vCenter is getting really upset and reloading it makes things only worse - so best to avoid this situation at all price.

regards

Rik

[NealeC · Accepted solution]

Hello Rik,

Just like your workload NSX manager, you should create a logical separation of this from your control plane NSX manager, dependent on your design of course.

Like most of vSphere, ESXi, VCSA etc. NSX is no different and relies heavilly on your DNS infrastructure being present, configured correctly and accessible.  Your post doesn't really explain what issue you encountered but you should start from an any-any status and layer on the rules for the DFW or ESG that you require, always keeping your breakglass root/local accounts handy until you've completed testing.

Again any iLO/IMM/RiB/CIMC connectivity should be excluded from firewalls to ensure you have Out of Band Management access in the event of a DR.

As for AD integration, NSX manager 5.5 suffers from the same issues ESXi did, despite not sharing the same kernel, as they share the same implementation of LikeWise borrowed from the linux Kernel to join computers to AD.  However they don't follow the windows model and require more permissions over a larger set of Computer Account object attributes and so delegating full control is a more operations practical approach allowing you to join your host/nsx manager to AD whilst maintaining delegated control/administration.

As with almost all vSphere infrastructue "it's the DNS" is often the answer to what was the problem.

[rikherlaar]

Dear Chris,

Appreciate your guidance ..thx much.

I'm normally totally aware of how to go about defining and deploying DFW rules but we all have bad hair days I reckon. The reason the mistake was made doesn't really matter that much here, we were goofing around trying to get Palo-Alto integration at version 7.1.1 to work and the use of zones/service profiles caused some confusion with the PAN expert as nothing got redirected - at which point a too drastic measure was taken.

If PAN would not have been installed, there'd be a way to deploy NSX API's from the NSX mgr and restore the default rule again -from there on we'd  be able to restore the last known working rule set and so on. (alas a chicken and egg story too long to bore you with)..

It's a lab so we have no designated Mgmt Cluster or Edge Cluster etc...still I am very annoyed that I managed to screw things up so badly with a single mistake ...so wanted to ;

1> vent my anger (for sawing off the branch I sat on)

2> Understand if it's normal that w/o DNS and AD the whole works becomes very unstable ...(apparently it does)

3> Learn a lesson or two besides flogging myself for being an incidental dumbo 😉

[NealeC]

Rik,

Come here and vent all you want.

We're here to help 🙂