Elver's Opinion: Restoring NSX from Old Backup

(Quick note: I wrote this blogpost back in October 2016 just before my son was born, so this one felt thru the cracks...but better late than never)

Taking a quick timeout from slacking (in blogging that is) to write up what happens to NSX Security when restoring from an old NSX MGR backup. Please have a read on the last two blogs, found here and here, if you don’t know why I’m writing this blog.

Starting off where we left off, I confirmed that I can ping between VMs ServerApp01 and ServerApp02 and then created a backup (I think this is Backup6) to save my starting position.

I then created a Security Group to include all ServerApp VMs and a Security Policy to not allow pings, and applied the Security Policy to the Security Group.

Trying to ping again failed:

Looking at the Traceflow output, we see that Rule 1006 is blocking the ping, which matches the rule to drop pings (following are a series of CLI commands to get the filter name for ServerApp01)

nsxmgr-a.piratas.caribe> show dfw host host-88
Datacenter: Santo Domingo
Cluster: COM-A1
Host: com-a1-esxi02.piratas.caribe
No.  VM Name             VM Id     Power Status
1    ServerApp01         vm-1067   on
2    ServerWeb01         vm-251    on
3    External Access-0   vm-1097   on
nsxmgr-a.piratas.caribe>

nsxmgr-a.piratas.caribe>  show dfw vm vm-1067
Datacenter: Santo Domingo
Cluster: COM-A1
Host: com-a1-esxi02.piratas.caribe
VM: ServerApp01
Virtual Nics List:
1.
Vnic Name      ServerApp01 - Network adapter 1
Vnic Id        50364fa1-372a-d312-6ee3-e0ecc727646d.000
Filters        nic-44950-eth0-vmware-sfw.2
nsxmgr-a.piratas.caribe>  show dfw host host-88 filter  nic-44950-eth0-vmware-sfw.2 rules
ruleset domain-c318 {
  # Filter rules
  rule 1006 at 1 inout protocol icmp icmptype 8 from addrset ip-securitygroup-12 to addrset ip-securitygroup-12 drop;
  rule 1003 at 2 inout protocol ipv6-icmp icmptype 136 from any to any accept;
  rule 1003 at 3 inout protocol ipv6-icmp icmptype 135 from any to any accept;
  rule 1002 at 4 inout protocol udp from any to any port 68 accept;
  rule 1002 at 5 inout protocol udp from any to any port 67 accept;
  rule 1001 at 6 inout protocol any from any to any accept;
}

ruleset domain-c318_L2 {
  # Filter rules
  rule 1004 at 1 inout ethertype any from any to any accept;
}

nsxmgr-a.piratas.caribe> show dfw host host-88 filter  nic-44950-eth0-vmware-sfw.2 stats
rule  1006: 7 evals, in 0 out 5 pkts, in 0 out 420 bytes
rule  1003: 2 evals, in 0 out 0 pkts, in 0 out 0 bytes
rule  1003: 0 evals, in 0 out 0 pkts, in 0 out 0 bytes
rule  1002: 2 evals, in 0 out 0 pkts, in 0 out 0 bytes
rule  1002: 1 evals, in 0 out 0 pkts, in 0 out 0 bytes
rule  1001: 2 evals, in 6 out 5 pkts, in 392 out 664 bytes
rule  1004: 5 evals, in 7 out 11 pkts, in 456 out 1130 bytes
nsxmgr-a.piratas.caribe>

Next, I did a backup of NSX MGR’s current configuration (Backup7???) and restored the previous backup before the Security Group and Security Policies were created. Sure enough checking Service Composer I can verify that the Security Group and Security Policy I created earlier are gone (as was to be expected) and the rules are gone from ServerApp01. The rules are gone because when NSX MGR comes back online after the restore, the ESXi hosts will flush all the old rules they have and receive updated rules from (the restored) NSX MGR. I’m also able to ping again.

Elver’s Opinion: I think this wraps up all cases of what happens when restoring NSX Manager from a copy that is missing configs. Although I didn’t cover what happens to the NSX Edge directly, I did cover the Control VM; the result will be similar.

Elver's Opinion

Tuesday, October 25, 2016

Restoring NSX from Old Backup - Impact on Security

No comments:

Post a Comment