Hi all,
We have a big issue since we have upgraded NSX from version 6.1.3 to 6.1.5.
I get a bug following this steps:
. In vSphere Client -> NSX, create a new Virtual Switch
. In Distribute Firewall, create a rule to deny traffic between two IPs. Example: source: any, destination: any, service: any, Action: reject, AppliedTo: the new virtual switch
. Connect two VMs to the virtual switch and you can ping each other (this is wrong because of the firewall rule)
. Publish ANY change on Distribute Firewall (could be not related with our rule. Example change another rule's name), and the rule starts to work.
Additional steps:
. Remove the Firewall rule
. Remove the VMs from the virtual switch
. Recreate the Firewall rule with AppliedTo: the virtual switch (again empty)
. Connect the VMs and ping each other. Again, the rule is not working.
. Publish ANY change on Distribute Firewall and the rule starts to work.
NSX version 6.1.3 and 6.2.0 both work correctly. But I can't downgrade to 6.1.3 nor upgrade to 6.2.0. Upgrade to 6.2.1 involves the upgrade of several other components.
I'm using the following versions:
. NSX 6.1.5
. vCenter Version 5.5.0 Build 2414847
. ESXi, 5.5.0, 2718055
Please, any ideas?
Thanks a lot,
D.
It's seems to be a bug of NSX 6.1.5 and there is no fix for this yet. There are some workarounds but none of them applies to my "fully automated" environment.
We need to wait for a fix or upgrade to NSX 6.2.1 which requires to upgrade several components as well.
D.
I'm not sure I follow. You say you create a rule, add VMs to a switch and it doesn't work as intended. Then you publish the rule and it works. Seems fine to me. Maybe I am just reading it wrong.
At any rate, have you gone through any of the DFW CLI commands to see if rules are being applied appropriately? If not try these (from the host the VM is on):
vsipioctl getfilters -f nic-37315-eth0-vmware-sfw.2 –s
vsipioctl getrules -f nic-37315-eth0-vmware-sfw.2
vsipioctl getaddrsets -f nic-80431-eth0-vmware-sfw.2
vsipioctl getspoofguard -f nic-80431-eth0-vmware-sfw.2
vsipioctl getflows -f nic-80431-eth0-vmware-sfw.2
It's seems to be a bug of NSX 6.1.5 and there is no fix for this yet. There are some workarounds but none of them applies to my "fully automated" environment.
We need to wait for a fix or upgrade to NSX 6.2.1 which requires to upgrade several components as well.
D.
Can you provide the specifics of the bug? I see a lot of 6.1.5 and am not really following your original post. I would like to have the details in case I come across this.
Hi Jacob,
I think that this steps are very specific:
. In NSX create a new Virtual Switch
. In Distribute Firewall, create a rule to deny traffic between two IPs. Example: source: any, destination: any, service: any, Action: reject, AppliedTo: the new virtual switch
. Connect two VMs to the virtual switch and you can ping each other (this is wrong because of the firewall rule)
. Publish ANY change on Distribute Firewall (could be not related with our rule. Example change another rule's name), and the rule starts to work.
In other words, if you create a Virtual Switch and create a Distribute Firewall rule with "AppliedTo" pointing to the newly created Virtual Switch (with no VMs connected) and after that connect some VMs, the firewall rule has no effect on the VMs.
D.
I think the confusion lies in when you talk about publishing the rule. When you do mention publishing, you say it works, which to me is how it is intended. I'm going to assume you mean a 2nd change and publish is required to get things working properly. I would be interested to what the host is telling you in regards to what the rule is supposed to be doing. This may also exist in 6.2.
Jacob,
This is a bug of version 6.1.5 and NSX 6.2.0 works correctly. I've check this out with VMware NSX experts on a call.
I found this bug in the following scenario:
. I've setted up two virtual wires one as a DMZ and the other as Application
. In Distribute Firewall I add a rule pointing to DMZ to deny access to Application virtual switch.
. Then, I add some VMs to both DMZ and Application virtual wires and realize that DMZ VMs could access Application VMs.
This happens with version 6.1.5. The same test on version 6.2.0 works correctly. In fact, it works correctly on version 6.1.3 also.
D.