NSX - Firewall Policies

[rajeevsrikant]

Below is the simple NSX firewall policy

VM-A has some problem & recovery is done by replacing this particual VM with its clone.

What will happen to this firewall policy ?

[Sree]

What is the new naming convention for cloned VM ? Remember you cannot have duplicate naming for VM under same VC/ESXI . In your case going via firewall rule , you should unregister old VM and register cloned VM with correct naming convention to match with firewall policy.

[rajeevsrikant]

The VM created with cloning will have the same naming of the previous one.

My understanding is that , since old vM is deleted & the same VM is created with cloning it will generate new object ID.

Because of this the existing policy will not be able to find the VM & the policy will have error.

This will happen whenever the object ID of the VM changes & new object ID is created. This will have problem when static mapping is done.

Let me know your inputs.

[smitmartijn]

Your assumption is correct: if you are using a static mapping (including the VM by name in a list and including it in the rule), it will be mapped to its VM ID. The solution for this is to use Security Groups where you say the name of the VM should be in that group. That way, if you restore the VM with the same name, it will be included in the firewall rule.

It's a general rule that you shouldn't use VMs as static objects in rules, it tends to wreak havoc with things like backup & restore utilities.

[Sree]

For static rule ,Yes it is true . Behavior is expected for all VC objects - Host/VM/Datastores/Cluster etc. Removal of those objects and adding it again will create a new id.

[cnrz]

Does cloning or backup preserve the NSX tags of the VMs, i.e. if the VMs are cloned and restored from the Clone with a different name the firewall rules for the original VM apply to cloned VM? Similarly if a VM is backed up and later needs to be restored, could the NSX tags expected to be restored with the VM, or the tags reapplied manually?

It could be expected that even the restore does not carry the tags, if the tagging is dynamically applied the same tag, thus dFW rule could be applied to restored VM

[rajeevsrikant]

So in this case for the above policy, I will change as below.

Step -1 : Create a security group (SG-A) using dynamic membership with "VMname'" "start with" for VM-A

Step -2 : Create a security group (SG-B) using dynamic membership with "VMname'" "start with" for VM-B

Step -3 : Add the security group (SG-A) in the source & add (SG-B) in the destination.

Step -4 : Delete VM-A from source & delete VM-B from destination

Step -5:  Publish the rules

By doing this will there be any interruption or disconnection in the session.

My understanding is that there will be session disconnection & new session will be established.

Let me know

[cnrz]

Although the dynamic rule will be converted and applied to VM-A and VM-B, the rule-id  could be changed. It may not sync the previous tcp states, so current sessions may drop. Since same permissions applied bew sessions should be established as before

[rajeevsrikant]

Thanks.

Few clarifications.

1 - Since I am modifying the existing rule, how does the Rule ID changes. My understanding is that the rule id remains the same. Please confirm this.

2 - Since the current sessions will drop there will be disconnection & impact to the application - Let me know if my understanding is right.

      If this is true, what is the exact way to check the connection & see the session is  getting disconnected & getting re established.

[rutgerblommah]

Use security tags and security groups instead of VM objects in your firewall rules. This will solve your problem and is much more scalable.

/Rutger

[Thank71]

I believe You shoud set two SecurityGroups with "auto add"  based uppon vn-name, and replace VMs with SGs.

ciao

.