Edge Nodes in NSX-T 3.1 are available as Virtual Machines and Bare Metal Edges. When you deploy a Virtual Edge Node using the embedded deployment function in NSX-T, you can choose between 4 sizes - Small, Medium, Large and Extra Large. In this article, I'm trying to collect information about the different sizing options, what they are intended for and how to resize Edge Nodes.
When you want to use the same public IP address for multiple websites, you have to leverage the SNI extension. Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) protocol which allows a client to indicate which hostname it wants to connect to. This allows a server to present specific certificates on the same IP address and hence allows multiple secure (HTTPS) websites to be served by the same server.
The NSX-T Load Balancer supports SNI Certificates on a single Virtual Server (IP Address) with different Server Pools in the backend. This article explains how to configure SNI-based Load Balancing with 3 different secure HTTPS Websites on a single IP Address with the NSX-T 3.1 Load Balancer.
Read More »How to configure Multiple TLS Certificates with SNI in NSX-T Load Balancer
When you try to import a Let's Encrypt SSL Server Certificate in NSX-T, the following error message is displayed:
Error: You have 1 Error(s)
Certificate chain validation failed. Make sure a valid chain is provided in order leaf,intermediate,root certificate. (Error code: 2076)
While writing the Getting Started with NSX Advanced Load Balancer Integration in VMware Cloud Director 10.3 guide, I came across a couple of issues. In this article, I'm going through those issues explaining what I did to solve them.
With the NSX Advanced Load Balancer integration in Cloud Director 10.2 or later, you can enable SSL offloading to secure your customer's websites. This article explains how to request a Let's Encrypt certificate, import it to VMware Cloud Director and enable SSL offloading in NSX-ALB. This allows tenants to publish websites in a secure manner.
Read More »SSL Load Balancer in VMware Cloud Director with NSX-ALB (AVI)
In the Getting Started with NSX Advanced Load Balancer Integration in VMware Cloud Director 10.3 Guide, I've explained how to enable "Load Balancing as a Service" in VCD with dedicated Service Engines. With this Service Engine deployment model, each Edge Gateway is statically assigned to a dedicated NSX-ALB Service Engine Group. That means, for each EGW you create in VCD, you have to create a Service Engine Groups, which consists of multiple Service Engines (Virtual Machines).
Service Engine Groups can also be deployed in a shared model. Shared Service Engine groups can be assigned to multiple Edge Gateways. In this deployment model, a single Service Engine (Virtual Machine) can handle traffic for multiple customers. For obvious security reasons, and to prevent problems with overlapping networks, VRFs are used inside the SE to fully separate the data traffic.
This article explains how to use Shared Service Engine Groups in VMware Cloud Director 10.3.
Read More »Shared Service Engine Groups in VMware Cloud Director with NSX Advanced Load Balancer
When you are using NSX-T as network backend for VMware Cloud Director, you can't use the Native Load Balancer included in NSX-T. Since Cloud Director 10.2, the NSX Advanced Loadbalancer (ALB), previously known as AVI Vantage Platform, has been integrated to allow customers to create Self-Service Load Balancers.
This article explains all steps required to integrate NSX ALB into VMware Cloud Director.
Read More »Getting Started with NSX Advanced Load Balancer Integration in VMware Cloud Director 10.3
Since VMware has introduced vSphere with Tanzu support in VMware Cloud Director 10.2, I'm struggling to find a proper way to implement a solution that allows customers bidirectional communication between Virtual Machines and Pods. In earlier Kubernetes implementations using Container Service Extension (CSE) "Native Cluster", workers and the control plane were directly placed in Organization networks. Communication between Pods and Virtual Machines was quite easy, even if they were placed in different subnets because they could be routed through the Tier1 Gateway.
With Tanzu meeting VMware Cloud Director, Kubernetes Clusters have their own Tier1 Gateway. While it would be technically possible to implement routing between Tanzu and VCD Tier1s through Tier0, the typical Cloud Director Org Network is hidden behind a NAT. There is just no way to prevent overlapping networks when advertising Tier1 Routers to the upstream Tier0. The following diagram shows the VCD networking with Tanzu enabled.
With Cloud Director 10.2.2, VMware further optimized the implementation by automatically setting up Firewall Rules on the TKC Tier1 to only allow the tenants Org Networks to access Kubernetes services. They also published a guide on how customers could NAT their public IP addresses to TKC Ingress addressed to make them accessible from the Internet. The method is described here (see Publish Kubernetes Services using VCD Org Networks). Unfortunately, the need to communicate from Pods to Virtual Machines in VCD seems still not to be in VMware's scope.
While developing a decent solution by using Kubernetes Endpoints, I came up with a questionable workaround. While I highly doubt that these methods are supported and useful in production, I still want to share them, to show what actually could be possible.
Read More »Direct Org Network to TKC Network Communication in Cloud Director 10.2
When you are running an NSX-T backed VMware Cloud Director, your customers might have the requirement to implement a remote access VPN solution. While Client VPN was possible with NSX-v, it is completely missing in NSX-T. This article explains how a customer can implement a Client VPN solution based on WireGuard. The implementation is fully in the hand of the customer and does not need any VCD modification or Service Provider interaction.
Wireguard is not part of VMware Cloud Director but can be installed easily on a Virtual Machine in the tenant's network. The following diagram shows the environment that is used throughout the article.
Read More »Client VPN with WireGuard in VMware Cloud Director backed by NSX-T
This article explains how to set up Firewall Rules in NSX-T that allow users to only access specific domains. In many high-security environments, outgoing traffic is filtered using a firewall. When you want to access an external service, you usually create IP-based firewall rules. In some cases, you don't know which IP addresses hide behind a domain. This is where domain filters come in handy.
While this feature has been available in NSX-T for a while, it was limited to a predefined set of domains. With the Release of NSX-T 3.1, you can finally define your own FQDN lists.
In this example, I'm going to set up NSX-T Distributed Firewall to only allow access to www.virten.net and reject all other domains.
Read More »Filter specific Domains (FQDN) with NSX-T Distributed Firewall