Cette rubrique contient des informations pour comprendre et dépanner le pare-feu distribué VMware NSX 6.x .

Problème

  • La publication de règles du pare-feu distribué échoue.
  • La mise à jour de règles pare-feu distribué échoue.

Cause

Vérifiez que chaque étape du dépannage ci-dessous est correcte pour votre environnement. Chaque étape fournit des instructions ou un lien vers un document afin d'éliminer les causes possibles et de prendre une mesure corrective si nécessaire. Les étapes sont classées dans l'ordre le plus approprié afin d'isoler le problème et d'identifier la bonne résolution. Après chaque étape, réessayez de mettre à jour/publier les règles du pare-feu distribué.

Solution

  1. Vérifiez que les VIB de NSX sont correctement installées sur chaque hôte ESXi du cluster. Pour ce faire, sur chaque hôte ESXi du cluster, exécutez ces commandes. 
    # esxcli software vib list | grep vsip
esx-vsip                       6.0.0-0.0.4744062  VMware  VMwareCertified   2017-01-04 

# esxcli software vib list | grep vxlan
esx-vxlan                      6.0.0-0.0.4744062  VMware  VMwareCertified   2017-01-04
    À partir de NSX 6.3.3 avec ESXi 6.0 ou version ultérieure, les VIB esx-vxlan et esx-vsip sont remplacés par esx-nsxv. 
    # esxcli software vib list | grep nsxv
esx-nsxv                       6.0.0-0.0.6216823  VMware  VMwareCertified   2017-08-10
  2. Sur les hôtes ESXi, vérifiez que le service vShield-Stateful-Firewall est en cours d'exécution.
    Par exemple : 
    # /etc/init.d/vShield-Stateful-Firewall status

vShield-Stateful-Firewall is running
  3. Vérifiez que le bus de messages communique correctement avec NSX Manager.
    Le script de surveillance lance automatiquement le processus et le redémarre s'il se termine pour une raison inconnue. Exécutez cette commande sur chaque hôte ESXi du cluster.
    Par exemple : 
    # ps | grep vsfwd

107557 107557 vsfwd /usr/lib/vmware/vsfw/vsfwd

    Au moins 12 processus vsfwd doivent être en cours d'exécution dans la sortie de commande. Si un nombre inférieur de processus (seulement 2 dans le cas le plus probable) est en cours d'exécution, vsfwd ne fonctionne pas correctement.

  4. Vérifiez que le port 5671 est ouvert pour les communications dans la configuration de pare-feu.
    Cette commande indique la connectivité VSFWD avec le broker RabbitMQ. Exécutez cette commande sur des hôtes ESXi pour voir une liste de connexions depuis le processus vsfwd sur l'hôte ESXi vers NSX Manager. Vérifiez que le port 5671 est ouvert pour les communications sur l'un des pare-feu externes sur l'environnement. De plus, il doit y avoir au moins deux connexions sur le port 5671. Il peut y avoir davantage de connexions sur le port 5671, car des machines virtuelles NSX Edge sont déployées sur l'hôte ESXi et elles établissent également des connexions avec le broker RMQ.
    Par exemple : 
    # esxcli network ip connection list |grep 5671

tcp         0       0  192.168.110.51:30133            192.168.110.15:5671   ESTABLISHED  10949155  newreno  vsfwd
tcp         0       0  192.168.110.51:39156            192.168.110.15:5671   ESTABLISHED  10949155  newreno  vsfwd
  5. Vérifiez que VSFWD est configuré.

    Cette commande doit afficher l'adresse IP de NSX Manager. 

    # esxcfg-advcfg -g /UserVars/RmqIpAddress
  6. Si vous utilisez un profil d'hôte pour cet hôte ESXi, vérifiez que la configuration RabbitMQ n'est pas définie dans le profil d'hôte.
    Consultez :
  7. Vérifiez que les informations d'identification RabbitMQ de l'hôte ESXi sont désynchronisées avec NSX Manager. Téléchargez les journaux de support technique de NSX Manager. Après avoir rassemblé tous les journaux de support technique de NSX Manager, recherchez dans tous les journaux les entrées semblables à ce qui suit :
    Remplacez host-420 par l'ID d'hôte de l'hôte suspect. 
    PLAIN login refused: user 'uw-host-420' - invalid credentials.
  8. Si ce type d'entrée est trouvé dans les journaux de l'hôte ESXi suspect, resynchronisez le bus de messages.

    Pour resynchroniser le bus de messages, utilisez l'API REST. Pour mieux comprendre le problème, collectez les journaux immédiatement après la resynchronisation du bus de messages. 

    HTTP Method : POST 
Headers , 
Authorization : base64encoded value of username password
Accept : application/xml
Content-Type : application/xml
Request:

POST https://NSX_Manager_IP/api/2.0/nwfabric/configure?action=synchronize

Request Body:

<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
<resourceId>{HOST/CLUSTER MOID}</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>
  9. Utilisez la commande export host-tech-support <host-id> scp <uid@ip:/path> pour rassembler des journaux de pare-feu spécifiques de l'hôte.
    Par exemple : 
    nsxmgr# export host-tech-support host-28 scp [email protected]
Generating logs for Host: host-28...
  10. Utilisez la commande show dfw host host-id summarize-dvfilter pour vérifier que toutes les règles de pare-feu sont déployées sur un hôte et appliquées aux machines virtuelles.
    Dans la sortie, module: vsip indique que le module DFW est chargé et en cours d'exécution. name indique le pare-feu exécuté sur chaque vNic.

    Vous pouvez obtenir les ID d'hôte en exécutant la commande show dfw cluster all pour obtenir les ID de domaine du cluster, puis la commande show dfw cluster domain-id pour obtenir les ID d'hôte.

    Par exemple : 
    # show dfw host host-28 summarize-dvfilter

Fastpaths:
agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter
agent: ESXi-Firewall, refCount: 5, rev: 0x1010000, apiRev: 0x1010000, module: esxfw
agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath
agent: dvfilter-generic-vmware-swsec, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-switch-security
agent: bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: vdrb
agent: dvfg-igmp, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfg-igmp
agent: vmware-sfw, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: vsip

Slowpaths:

Filters:
world 342296 vmm0:2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979 vcUuid:'3f 43 54 76 8f 54 4e 5a-8d 01 59 65 4a 4e 99 79'
 port 50331660 2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979.eth1
  vNic slot 2
   name: nic-342296-eth1-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  vNic slot 1
   name: nic-342296-eth1-dvfilter-generic-vmware-swsec.1
   agentName: dvfilter-generic-vmware-swsec
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Alternate Opaque Channel
 port 50331661 (disconnected)
  vNic slot 2
   name: nic-342296-eth2-vmware-sfw.2 <======= DFW filter
   agentName: vmware-sfw       
   state: IOChain Detached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
 port 33554441 2-vm_RHEL63_srv_64-shared-846-3f435476-8f54-4e5a-8d01-59654a4e9979
  vNic slot 2
   name: nic-342296-eth0-vmware-sfw.2<========= DFW filter
   agentName: vmware-sfw    
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  11. Exécutez la commande show dfw host hostID filter filterID rules.
    Par exemple : 
    # show dfw host host-28 filter nic-79396-eth0-vmware-sfw.2 rules
 
ruleset domain-c33 {
  # Filter rules
  rule 1012 at 1 inout protocol any from addrset ip-securitygroup-10 to addrset ip-securitygroup-10 drop with log;
  rule 1013 at 2 inout protocol any from addrset src1013 to addrset src1013 drop;
  rule 1011 at 3 inout protocol tcp from any to addrset dst1011 port 443 accept;
  rule 1011 at 4 inout protocol icmp icmptype 8 from any to addrset dst1011 accept;
  rule 1010 at 5 inout protocol tcp from addrset ip-securitygroup-10 to addrset ip-securitygroup-11 port 8443 accept;
  rule 1010 at 6 inout protocol icmp icmptype 8 from addrset ip-securitygroup-10 to addrset ip-securitygroup-11 accept;
  rule 1009 at 7 inout protocol tcp from addrset ip-securitygroup-11 to addrset ip-securitygroup-12 port 3306 accept;
  rule 1009 at 8 inout protocol icmp icmptype 8 from addrset ip-securitygroup-11 to addrset ip-securitygroup-12 accept;
  rule 1003 at 9 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1003 at 10 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1002 at 11 inout protocol udp from any to any port 67 accept;
  rule 1002 at 12 inout protocol udp from any to any port 68 accept;
  rule 1001 at 13 inout protocol any from any to any accept;
}

ruleset domain-c33_L2 {
  # Filter rules
  rule 1004 at 1 inout ethertype any from any to any accept;
  12. Exécutez la commande show dfw host hostID filter filterID addrsets.
    Par exemple : 
    # show dfw host host-28 filter nic-342296-eth2-vmware-sfw.2 addrsets 

addrset dst1011 {
ip 172.16.10.10,
ip 172.16.10.11,
ip 172.16.10.12,
ip fe80::250:56ff:feae:3e3d,
ip fe80::250:56ff:feae:f86b,
}
addrset ip-securitygroup-10 {
ip 172.16.10.11,
ip 172.16.10.12,
ip fe80::250:56ff:feae:3e3d,
ip fe80::250:56ff:feae:f86b,
}
addrset ip-securitygroup-11 {
ip 172.16.20.11,
ip fe80::250:56ff:feae:23b9,
}
addrset ip-securitygroup-12 {
ip 172.16.30.11,
ip fe80::250:56ff:feae:d42b,
}
addrset src1013 {
ip 172.16.10.12,
ip 172.17.10.11,
ip fe80::250:56ff:feae:cf88,
ip fe80::250:56ff:feae:f86b,
}
  13. Si vous avez validé toutes les étapes de dépannage ci-dessus, mais que vous ne pouvez pas publier des règles de pare-feu sur les machines virtuelles hôtes, exécutez une synchronisation forcée de niveau hôte via l'interface utilisateur de NSX Manager ou via l'appel API REST suivant. 
    URL : [https:]https://<nsx-mgr-ip>/api/4.0/firewall/forceSync/<host-id>
HTTP Method : POST 
Headers , 
Authorization : base64encoded value of username password
Accept : application/xml
Content-Type : application/xml

Solution

Remarques :

  • Vérifiez que VMware Tools est exécuté sur les machines virtuelles si des règles de pare-feu n'utilisent pas d'adresses IP. Pour plus d'informations, consultez https://kb.vmware.com/kb/2084048.

    VMware NSX 6.2.0 introduit la possibilité de découvrir l'adresse IP de la machine virtuelle en utilisant l'écoute DHCP ou l'écoute ARP. Ces nouveaux mécanismes de découverte permettent à NSX de mettre en application les règles de sécurité basées sur l'adresse IP pour les machines virtuelles sur lesquelles VMware Tools n'est pas installé. Pour plus d'informations, consultez les notes de mise à jour de NSX 6.2.0.

    DFW est activé dès que le processus de préparation de l'hôte est terminé. Si une machine virtuelle n'a pas du tout besoin d'un service DFW, elle peut être ajoutée à la liste d'exclusion (par défaut, NSX Manager, les instances de NSX Controller et les passerelles ESG sont automatiquement exclus de la fonction DFW). Il est possible que l'accès de vCenter Server soit bloqué après la création d'une règle Refuser tout dans DFW. Pour plus d'informations, consultez https://kb.vmware.com/kb/2079620.

  • Lors du dépannage du pare-feu distribué VMware NSX 6.x avec le support technique VMware, les éléments suivants sont requis :
    • Sortie de la commande show dfw host hostID summarize-dvfilter sur chaque hôte ESXi du cluster.
    • Configuration du pare-feu distribué dans l'onglet Networking and Security > Pare-feu > Général (Networking and Security > Firewall > General) et clic sur Exporter la configuration (Export Configuration). Cela exporte la configuration du pare-feu distribué au format XML.
    • Journaux de NSX Manager. Pour plus d'informations, consultez https://kb.vmware.com/kb/2074678.
    • Journaux de vCenter Server. Pour plus d'informations, consultez https://kb.vmware.com/kb/1011641.