All Posts

Good evening, I've got an NSX Environment running on 4.1 (upgraded from 3.0 over the last year) and i wanted to take a look at NSX Federation and therefore deployed the global manager and added my l... See more...
Good evening, I've got an NSX Environment running on 4.1 (upgraded from 3.0 over the last year) and i wanted to take a look at NSX Federation and therefore deployed the global manager and added my local manager to the Location Manager. Since i had Identity Based Rules, Bridges and vRNI Data Collection active the GM told me that this needs to be removed which i successfully did. Now i'm sitting on the last message and don't know where to start so that i can finally import the local manager Data. The error i have in the GUI is: Unable to import due to these unsupported features: Multi Overlay Transport Zone.   gmanager.log says: errors=[com.vmware.nsx.management.gm.onboarding.exceptions.ConfigOnboardingException: Entity MULTI_OVERLAY_TZ_USE_COUNT at site HZ is not supported for configuration import on GM. Please delete entity MULTI_OVERLAY_TZ_USE_COUNT from the site HZ and try again. From what i've found with Google "Multi Overlay TZ Use" refers to having multiple Overlay Transport Zones on 1 Host Switch either within the Transport Nodes or Edges. But all my Host Transport Nodes and Edges are only having 1 Overlay Transport Zone for the Segments and 1 VLAN Transport Zone for Edge-Uplinks included (Single Subnet vTEP). Edge-Node:   ESXi-Host Transport Node Profile:     So that each Location have their own set of Overlay and VLAN TZs, which should be fine i guess. Unfortunately i can't find any information either on the Local Manager or on the Global manager how to delete that MULTI_OVERLAY_TZ_USE_COUNT entity. Could you help me, how to find that? Or do i need to actually seperate the Overlay Transport Zone and VLAN Transport Zone into seperate Switches? (Edge is using the VLAN Segments on the NSX activated ESXi-Hosts)   Thanks and best regards!
Thank you for your response. Is it safe enough to only limit IP addresses in the ESXi firewall?
The NSX DFW can't do firewalling of ESXi host vmk interfaces. However, there is a firewall native to ESXi that you can use - https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.... See more...
The NSX DFW can't do firewalling of ESXi host vmk interfaces. However, there is a firewall native to ESXi that you can use - https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-8912DD42-C6EA-4299-9B10-5F3AEA52C605.html.
Hi, As per the documentation it seems like it is possible to add a port range for translated ports when creating an NSX NAT rule, however, on doing so, it seems to fail Any help understan... See more...
Hi, As per the documentation it seems like it is possible to add a port range for translated ports when creating an NSX NAT rule, however, on doing so, it seems to fail Any help understanding what I may be doing wrong in the configuration would greatly be appreciated.   Thanks!
  • Hi
Starting with NSX version 4.1, many more certificates are visible in NSX. Those certificates have always been present on the platform, even in previous versions, but it was impossible to lifecycle ... See more...
Starting with NSX version 4.1, many more certificates are visible in NSX. Those certificates have always been present on the platform, even in previous versions, but it was impossible to lifecycle them. This document will help the reader understand the purpose of all the certificates part of the NSX platform. It will provide examples covering common certificate-related tasks an NSX administrator may tackle while administering NSX. To make these examples reproducible, they are presented in the form of bash scripts. We opted to use bash for maximum portability. The scripts mainly use curl to perform API calls to the NSX API and use the jq to process the returned JSON data structures. You must install jq on your system to run the sample scripts. You can use your system package manager (i.e., apt or homebrew) The scripts are provided for educational purposes only. You should perform your validations before leveraging them on production systems. The current doc applies to NSX version 4.1.1 and later  Note: copy and paste from the PDF doc will lead to formatting errors. All the scripts are available on GitHub for easy copy and paste: https://github.com/vmware-nsx/nsx_certificates_cookbook Author: NSX Product Team
You can export the security policies from the NSX U.I in CSV format 
Any one aware of any PowerCLI module or script to export NSXT DFW rule in csv format ? Appreciate any input.
Worked for me:   Rule Enforcement Status: Check if the rule's "Enforcement Status" is set to "Enabled." If it's disabled, the rule won't be applied.   Thx a LOT!
Troubleshooting issues with VMware NSX Distributed Firewall rules not applying as expected can be complex, but here are some initial steps to help diagnose and potentially resolve the issue: Verif... See more...
Troubleshooting issues with VMware NSX Distributed Firewall rules not applying as expected can be complex, but here are some initial steps to help diagnose and potentially resolve the issue: Verify Rule Order: Make sure that the rule order is correct. NSX Distributed Firewall processes rules from top to bottom. Rules higher in the list take precedence over rules lower in the list. Ensure that there are no conflicting rules that might be overriding the ones you want to apply. Check Applied Security Groups: Ensure that the security groups associated with your VMs are correctly mapped to the distributed firewall rules. If a VM is not in the expected security group, the rules won't apply. Logging and Monitoring: Enable logging for the distributed firewall rules. This can help you see if the rules are being hit and whether they are allowing or blocking traffic. The NSX Manager provides logs that can assist in troubleshooting. VM vNIC Placements: Verify that VM vNICs are properly placed on the correct NSX Logical Switch. If a VM has multiple vNICs connected to different logical switches, it may not match the intended firewall rule. Object Names and IDs: Ensure that the objects (such as security groups, logical switches, and VMs) referenced in your firewall rules use correct names or IDs. Typos or name changes can lead to rules not matching properly. Rule Enforcement Status: Check if the rule's "Enforcement Status" is set to "Enabled." If it's disabled, the rule won't be applied. NSX Manager Health: Monitor the health and status of the NSX Manager and related components. Any issues with NSX Manager can affect the proper functioning of distributed firewall rules. Packet Flow and Debugging: Use NSX packet flow and debugging tools to trace how packets traverse the network and the firewall rules they encounter. This can provide valuable insights into why traffic is not matching the expected rules. Upgrade and Patch Status: Ensure that you are running a supported and relatively up-to-date version of NSX. Sometimes, issues are resolved in newer versions or patches. Documentation and VMware Support: Consult VMware's official documentation, knowledge base, and community forums for specific troubleshooting steps related to your NSX version. If the issue persists, consider reaching out to VMware support for assistance. Remember that troubleshooting network and security issues can be complex, so it may take some time to identify the root cause. Document your steps, changes, and any error messages you encounter to help pinpoint the issue.
I've recently implemented VMware NSX in our data center for micro-segmentation and network virtualization, and I'm encountering an issue with the Distributed Firewall. I've defined a set of firewall ... See more...
I've recently implemented VMware NSX in our data center for micro-segmentation and network virtualization, and I'm encountering an issue with the Distributed Firewall. I've defined a set of firewall rules to control traffic between virtual machines, but it seems like some of these rules are not applying as expected. The traffic is not being blocked or allowed as per my rule set. Here are some details: All ESXi hosts are properly prepared with NSX, and the NSX Manager reports no errors. The logical switches, routers, and Distributed Firewall have been correctly configured. I've double-checked the rule set to ensure it's correct, and it includes the appropriate sources, destinations, and services. There are no conflicting security groups or rules. Can someone help me troubleshoot this issue? How can I go about diagnosing why some of the Distributed Firewall rules are not applying as intended? Any insights or suggestions would be greatly appreciated!
Yes, I'm talking about NSX-v, version 6.4.x. Currently I don't see a way to list all the typed-in commandline records from basic/privilege/configuration mode; it seemed that using the up and down ar... See more...
Yes, I'm talking about NSX-v, version 6.4.x. Currently I don't see a way to list all the typed-in commandline records from basic/privilege/configuration mode; it seemed that using the up and down arrow keys would be the fastest solution. The "show log" command(such as "show log appmgmt follow") didn't help. It only tells something look like services' status. Does anyone know?
Hi,  I am trying to set up some email alerting on my ALB appliances.  I have created some custom alert configs,  that trip when a pool member down event occurs.  The alert works fine,  but it takes a... See more...
Hi,  I am trying to set up some email alerting on my ALB appliances.  I have created some custom alert configs,  that trip when a pool member down event occurs.  The alert works fine,  but it takes around 2 minutes for it to show up under "all alerts" once it shows up under there then I get an email pretty quickly.  I need these alerts to be "real time" not 2 minutes after they occur.  Any ideas/thoughts on what I have misconfigured?   Thank you, Tony
Hi guys, Does anybody know how security policies sorting works (via REST API)? Through UI we can easily change the order of the policies, however through API we have the sequence number mechanism t... See more...
Hi guys, Does anybody know how security policies sorting works (via REST API)? Through UI we can easily change the order of the policies, however through API we have the sequence number mechanism to handle that. After some tests using REST API, I'm facing an odd behavior: 1. We have created a policy several times, using the same sequence number 2. On both UI and REST API, the policy appears in a different order from run to run Expected behavior: From run to run, we are expecting to have the policy on the same position (assuming that no other polices were added/updated/removed) We would like to know which is the criteria to order security policies with the same sequence number. Is there any possibility to change that behavior? Thanks. Regards.
Hello, I have an ESXi host with a public IP address, and it is connected to the vCenter via the public IP address. Given that I am unable to move the ESXi into a private network, I'm considering usi... See more...
Hello, I have an ESXi host with a public IP address, and it is connected to the vCenter via the public IP address. Given that I am unable to move the ESXi into a private network, I'm considering using VMware NSX DFW to enhance its security against ransomware. Would this solution suffice? Regards,
Correction on the Topology New2.   VIP is 10.0.0.5 and the interface on the LB/Gateway is 10.0.0.5 Not 10.0.06 and 10.0.0.3 Uploaded correction  
So the more i read up on it, this topology might be an option (Topology New2) Not exactly sure how to configure this yet, but sounds like the T1 Gateway acts as a service, not as an actual router.  ... See more...
So the more i read up on it, this topology might be an option (Topology New2) Not exactly sure how to configure this yet, but sounds like the T1 Gateway acts as a service, not as an actual router.   I just have to see how to deploy this. Does this look correct and how i should be configuring? Thanks
So I feel like NSX-T is more complicated then the old NSX.   Everything ive read so far indicates a T1 or T0 Gateway is need to use the NSX-T load balancers.   Ive attached what our current network... See more...
So I feel like NSX-T is more complicated then the old NSX.   Everything ive read so far indicates a T1 or T0 Gateway is need to use the NSX-T load balancers.   Ive attached what our current network topology looks like (Topology Current).  Very simple.  Thing is changing our Network Topology would be a big to do.   Ive also attached what looks to be an example of a new Topology thats needed.  But im 99% sure i cant IP it the way i have it in the picture.  I would need other IP Subnets, but the thing is we get the IPs from our Central networking team.   So the interfaces on the T1 Gateway would most likley have to be something like 10.0.1.2 and 10.0.1.3 Web Servers and Load Balancers would need to be changed to something like 10.0.1.5, 10.0.1.6 and 10.0.1.7 But this isnt realistic for us.  We have over 100 Vms, cant reIP all of them because of 3 load balancers.   I have to assume NSX-T has a way of doing this without adding the T1 gateway, or a way were i dont need to reIP everything. Hopefully im explaining things correctly, any help is appreciated    
Hello, yep been reading up on that, something else we will need to do, migrate to Advanced NLB as well. Does look like regular NLB is still supported for now  
I realize this doesn't directly answer your question, but VMware would generally recommend you migrate load balancing to NSX Advanced Load Balancer not the native NSX-T load balancer. VMware has anno... See more...
I realize this doesn't directly answer your question, but VMware would generally recommend you migrate load balancing to NSX Advanced Load Balancer not the native NSX-T load balancer. VMware has announced plans to remove the NSX native load balancer in favor of ALB in a future release: === Deprecation Announcement for NSX-T Load Balancing APIs NSX-T Load Balancer APIs would be marked as deprecated. This would apply to all APIs containing URIs that begin with /policy/api/v1/infra/lb- Please be aware that VMware intends to remove support of the NSX-T Load Balancer in an upcoming NSX-T release, which will be generally available no sooner than one year from the date this message was announced (December 16, 2021). NSX-T Manager APIs that are planned to be removed are marked with "deprecated" in the NSX Data Center API Guide. It is recommended that new deployments with NSX-T Data Center take advantage of VMware NSX Advanced Load Balancer (Avi) using release v20.1.6 or later. === (https://docs.vmware.com/en/VMware-NSX/3.2/rn/vmware-nsxt-data-center-32-release-notes/index.html#Feature%20/%20API%20Deprecations%20and%20Behavior%20Changes-Deprecation%20Announcement%20for%20NSX-T%20Load%20Balancing%20APIs) === VMware intends to deprecate the built-in NSX load balancer and recommends customers migrate to NSX Advanced Load Balancer (Avi) as soon as practical. VMware NSX Advanced Load Balancer (Avi) provides a superset of the NSX load balancing functionality and VMware recommends that you purchase VMware NSX Advanced Load Balancer (Avi) Enterprise to unlock enterprise grade load balancing, GSLB, advanced analytics, container ingress, application security and WAF. We are giving advanced notice now to allow existing customers who use the built-in NSX load balancer time to migrate to NSX Advanced Load Balancer (Avi). Support for the built-in NSX load balancer for customers using NSX-T Data Center 3.x will remain for the duration of the NSX-T Data Center 3.x release series. Support for the built-in NSX load balancer for customers using NSX 4.x will remain for the duration of the NSX 4.x release series. Details for both are described in the VMware Product Lifecycle Matrix. We do not intend to provide support for the built-in NSX load balancer beyond the last NSX 4.x release. === https://docs.vmware.com/en/VMware-NSX/4.0.1.1/rn/vmware-nsx-4011-release-notes/index.html#Feature%20Deprecation
Hello, we have been slow to migrate our NSX to NSX-T.  We finally got around to it but im missing something as our Edges cant migrate without adding a Gateway now.   We have a very simple setup, we ... See more...
Hello, we have been slow to migrate our NSX to NSX-T.  We finally got around to it but im missing something as our Edges cant migrate without adding a Gateway now.   We have a very simple setup, we only use NSX for Firewall and 3 Edge Network Load balancers.   We currently have no Virtual Gateway for the Edge NLBs and everything is working great. But when we use the migration tool for NSX-T, when it gets to the Edge migration its says we need to connect them to a Gateway or it will not Migrate them.   We have no cloud stuff.   Is the Gateway really necessary with NSX-T, or am i missing something silly? Can is skip the Edge migration, then just setup new Edges in NSX-t without a gateway, this would be a pain, but we could plan a maintenance window? Just doing simple Load balancing with the Edges If the gateway is needed, This adds a complexity to things that i need to research and learn Thanks for any input