Dynamic Address Groups—Information Relay from NSX Manager to Panorama

To enforce security policies in a VM-Series and NSX integrated data center, Panorama must be able to obtain information on the changes in the virtual landscape. As new virtual machines are deployed, changed, or deleted, the NSX Manager informs Panorama of IP addresses added, removed from security groups on the NSX Manager. Panorama in turn then, pushes this information to the VM-Series firewalls. Dynamic address groups referenced in firewall policies match against this information to determine the members that belong to the group. This process allows the firewall to enforce context-aware security policy, which secures traffic to and from these virtual machines. For details on dynamic address groups, see Policy Enforcement using Dynamic Address Groups.
The following diagram illustrates how the information is relayed from the NSX Manager to Panorama.
NSX_Panorama_DAG_concept.png
To understand this process, let’s trace the information update sent from the NSX Manager to Panorama when a new server is added to a security group. Use the elements highlighted within the output in each phase of this example, to troubleshoot where the process failed.
  1. To view the updates in real-time, log in to the Panorama CLI.
  2. Verify that the request from the NSX Manager is routed to the web server on Panorama.
    To check the webserver-log on Panorama during an NSX Security Group update, use the following command:
    admin@Panorama> tail follow yes webserver-log cmsaccess.log 
    127.0.0.1 - - [Wed Dec 03 14:24:11 2014 PST] "POST /unauth/php/RestApiAuthenticator.php HTTP/1.1" 200 433 
    127.0.0.1 - - [Wed Dec 03 14:24:11 2014 PST] "PUT /api/index.php?client=wget&file-name=dummy&type=vmware/vmware/2.0/si/serviceprofile/serviceprofile-1/containerset HTTP/1.0" 200 446 
    If your output does not include the elements above, check for routing issues. Ping the Panorama from the NSX Manager and check for ACLs or other network security devices that might be blocking the communication between the NSX Manager and Panorama.
  3. Verify that the request is parsed by the PHP daemon on Panorama.
    1. Enable debug using the following URL: https://<Panorama_IP>/php/utils/debug.php
      enable_debug.png
    2. From the CLI, enter the following command to view the logs generated by the PHP server:
      admin@Panorama> tail follow yes mp-log php.debug.log 
      [2014/12/03 14:24:11] 
      <request cmd="op" cookie="0604879067249569" refresh="no"> 
        <operations xml="yes"> 
          <show> 
            <cli> 
      ... 
         <request> 
            <partner> 
              <vmware-service-manager> 
                <update> 
                  <method>PUT</method> 
                  <type>update</type> 
                  <username>_vsm_admin</username> 
                 <password>4006474760514053</password> 
      <url>/vmware/2.0/si/serviceprofile/serviceprofile-1/containerset</url> 
                  <data><![CDATA[ 
      <containerSet><container><id>securitygroup-10</id><name>WebServers</name><description></description><revision>8</revision><type>IP</type><address>10.3.4.185</address><address>10.3.4.186</address><address>15.0.0.203</address><address>15.0.0.202</address></container></containerSet>]]></data>
      </update>
              </vmware-service-manager>
            </partner>
          </request>
        </operations>
      </request>
  4. The information is processed by the Management server on Panorama.
    1. Enable debugging on the management server using the following command:
      admin@Panorama> debug management-server on debug
    2. Enter the following command to view the logs generated by the configd log:
      admin@Panorama> tail follow yes mp-log configd.log
    3. In the output check that the update was relayed from the PHP daemon to the management server daemon.
      2014-12-03 14:24:11.143 -0800 debug: pan_job_progress_monitor(pan_job_mgr.c:3694): job-monitor: updated 0 jobs……2014-12-03 14:24:11.641 -0800 debug: recursive_add_params(pan_op_ctxt.c:158): > 'url'='/vmware/2.0/si/serviceprofile/serviceprofile-1/containerset'
      2014-12-03 14:24:11.641 -0800 debug: recursive_add_params(pan_op_ctxt.c:158): > 'data'='
      <containerSet><container><id>securitygroup-10</id><name>WebServers</name><description></description><revision>8</revision><type>IP</type><address>10.3.4.185</address><address>10.3.4.186</address><address>15.0.0.203</address><address>15.0.0.202</address></container></containerSet>'
      2014-12-03 14:24:11.641 -0800 Received vshield update: PUT /vmware/2.0/si/serviceprofile/serviceprofile-1/containerset
      Received dynamic address update from VSM: 
      <request cmd='op' cookie='0604879067249569' client="xmlapi"><operations xml='yes'><request>
          <partner>
              <vmware-service-manager>
                  <update>
                      <method>PUT</method>
              <type>update</type>
      <username>_vsm_admin</username>
      <password>4006474760514053</password><url>/vmware/2.0/si/serviceprofile/serviceprofile-1/containerset</url><data><![CDATA[
      <containerSet><container><id>securitygroup-10</id><name>WebServers</name><description></description><revision>8</revision><type>IP</type><address>10.3.4.185</address><address>10.3.4.186</address><address>15.0.0.203</address><address>15.0.0.202</address></container></containerSet>]]>
      </data></update>
    4. Look for the list of IP addresses and security group tags.
      2014-12-03 14:24:11.646 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3721): ip: 10.3.4.185
      2014-12-03 14:24:11.646 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: WebServers-securitygroup-10
      2014-12-03 14:24:11.646 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3721): ip: 15.0.0.202
      2014-12-03 14:24:11.646 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: WebServers-securitygroup-10
      pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: DomainControllers-securitygroup-16
      2014-12-03 14:24:11.647 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3721): ip: 15.0.0.201
      2014-12-03 14:24:11.648 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: SQLServers-securitygroup-11
      2014-12-03 14:24:11.665 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: SharePointServers-securitygroup-13
      2014-12-03 14:24:11.665 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3721): ip: 10.3.4.187
      2014-12-03 14:24:11.665 -0800 debug: pan_cfg_mongo_sel_ip_taglist_by_tag_rev(src_cms/pan_cfg_mongo_tables.c:3738): tag: SharePointServers-securitygroup-13
      ...
    5. Finally, verify that the update was relayed from the management server daemon to the managed firewalls.
      Send to device: 007900002079 [UNREG: 0; REG: 2] with dynamic address update : <request cmd='op' cookie='0604879067249569' target-…. <register>
      <entry ip="15.0.0.203">
        <tag>
      <member>WebServers-securitygroup-10</member>
        </tag>
      </entry>
      <entry ip="10.3.4.186">
        <tag>
      <member>WebServers-securitygroup-10</member>
        </tag>
      </entry>
      </register>

Related Documentation