按照 NSX 的最佳实践，在部署 NSX 时需要划分三个集群：管理集群、Edge 集群及生产集群，但在一些小型环境下并没有太多硬件资源支撑这样的部署，通常会选择将管理虚拟机、NSX 虚拟机与业务虚拟机运行在同一个集群中，这种情况下必须将管理虚拟机加入 NSX DFW 白名单，否则就会出现标题中的问题：vCenter 网络被 NSX DFW 阻断。之后 vCenter 便无法登陆，也无法改回防火墙规则。
小型部署的正确操作
小型环境部署 NSX 微分段后，第一部操作始终是将管理虚拟机加入 NSX 白名单中。
NSX 6.3.x 及之前版本配置方式：
打开vCenter，进入“网络与安全“，点击页面左下角的 NSX managers
选中左侧的 NSX managers，会出现可用 NSX manager，点击对应的 NSX manager，找到”管理>排错列表“
将 vCenter 加入到右侧列表中，点击完成即可。
NSX 6.4.x 及之后配置方式：
打开vCenter，进入“网络与安全”配置，点击“防火墙配置>排除列表添加”
将 vCenter 加入到右侧列表中，点击完成即可。
恢复方式1：使用 REST API
NSX 几乎所有的操作全部都能通过 REST API 来执行，每个 NSX 标准文档库中都会包含 API 手册：
调用 REST API 需要安装一个 REST Client，笔者推荐使用 Postman，当然也可以选用自己熟悉的工具，比如 Python、curl、浏览器插件（Chrome 建议用 YARC、FireFox 建议用 RESTClient）。
下面以 Postman 为例介绍如何通过 API call 清除 DFW 配置（此操作会删掉所有防火墙策略！慎用），让 vCenter 复活。
1、打开 Postman，配置认证信息
认证类型：Basic Auth
填写 NSX manager 的用户名和密码，点击 Update Request
完成后在 Headers 中会自动出现 Authorization 字段
2、新增Key：Content-Type
在后面的 Value 中输入：application/xml
配置完成后结果
3、通过 API 查看并删除防火墙策略
在网址栏选择 Get 操作，填写以下内容，点击 Send
Https://NSX-Manager-FQDN/api4.0/firewall/globalroot-0/config
可以看到返回的结果是 XML 格式的防火墙规则，表明 API call 正常，可以继续进行下一步
将网址前面的 GET 改为 DELETE，再次点击 Send
返回的 Body 为空，状态为** 204 No Content**，代表操作顺利执行
此时，NSX 所有防火墙规则已被清除，vCenter 应该能够顺利登陆，打开 vCenter>网络与安全>防火，可以看到防火墙恢复成出厂设置了…
恢复方式2：使用命令行
第二种恢复稍微复杂点，需要先找到 vCenter 运行在哪台 ESXi 主机，再通过 SSH 登陆，运行一些命令来修改 vCenter 虚拟机网卡的防火墙策略。这种方式优点是不会影响已创建的防火墙策略。
1、分别登陆每台主机的 Web Client，找到 vCenter 所在主机
2、开启主机的 SSH 服务，并登陆
| 3、输入summarize-dvfilter | more，找到 vCenter 虚拟机的网卡，记录 name信息 |
4、查看关联到此网卡的防火墙规则
执行命令行vsipioctl getrules -f nic-22278151-eth0-vmware-sfw.2，记录下图中红色标注的内容
5、运行 /etc/init.d/vShield-Stateful-Firewall stop，此操作会防止主机从 NSX Manager 获取最新防火墙规则
6、使用下列命令清空已有的防火墙规则：
vsipioctl vsipfwcli -Override -f nic-22278151-eth0-vmware-sfw.2 -c "create ruleset domain-c141;"
（红色部分填写第三步及第四步查出来的内容）
清除完成后 ruleset domain-c141 变为空
7、测试 vCenter 网络，修改防火墙规则**
此时 vCenter 的通信应该已经恢复，需要登录 vCenter，修改原来设置错误的那条防火墙规则，点击发布
此时立即返回主机，启动 vShield-Stateful-Firewall 服务
/etc/init.d/vShield-Stateful-Firewall start
长 ping vCenter，会发现网络会暂时中断，之后自动恢复，表示主机已经接受了新的防火墙规则
-全文完-
参考资料 ：
https://kb.vmware.com/s/article/2079620