Welcome back!!! We are at Part 2 of the blog series on TLS SNI Virtual Service hosting in NSX Advanced Load balancer. In Part 1, we discussed about the current SNI application hosting without ALB and the ALB pre-requisite configurations – vSphere cloud account, IPAM profiles, DNS virtual service, DNS profile, DNS delegation and application certificates. If you missed it, you can read it here:
Now let’s migrate the hosting of our SNI enabled intranet and finance applications to NSX ALB. We achieve this using Parent – Child virtual services by selecting SNI as the Virtual Hosting Type.
Note: We will not make any configuration changes on the web servers, instead configure ALB hosting as front end to work with the existing web servers hosting configuration.
Let’s get started:
Parent Virtual Service
The parent virtual service holds the virtual IP (VIP), service port and the network (TCP/UDP) profile. It is normally configured with a wildcard cert as a catch-all VS for any traffic not matched by the child virtual services. The parent VS is front-end to all connection requests from the clients and handles the initial SSL/TLS negotiation until the phase reaches SNI matching where the child VS will be selected and the request will be forwarded. The child VS will present the correct certificate to the client.
Parent and Child VS is enabled by selecting the ‘Virtual Hosting Type’ as SNI. Virtual Hosting Type will be available once the option ‘Virtual Hosting VS’ is checked.
For the Parent VS, the option for VIP address is available and we select the VIP network from the IPAM profile for auto VIP assignment (because we already added IPAM profile to the cloud account).
An Application domain name has to be specified for the VS. The DNS suffix comes from the DNS profile attached to the cloud account. A dynamic DNS entry for this application domain name will get auto created in the DNS virtual service.
The tls certificate selected is the wildcard cert for the domain *.avi.vxplanet.local
We don’t have a backend server pool for the parent VS. We will instead do an URL redirect to land on the blog page – https://vxplanet.com for any requests that is served from the parent VS. This is done via an HTTP request policy.
Child Virtual Service 1 – Intranet Application
The Child virtual service doesn’t have a VIP or a service port field, instead only an application domain name and will point to the Parent virtual service. This application domain name is used by the SNI clients to place as the host header in the HTTPS request to access the intranet application.
Similar to Parent VS, the Child VS is enabled by selecting the ‘Virtual Hosting Type’ as SNI. Virtual Hosting Type will be available once the option ‘Virtual Hosting VS’ is checked. The application domain name is the intranet FQDN which is intranet.avi.vxplanet.local. A dynamic DNS entry will be auto created in the DNS virtual service.
The pool members of the Intranet virtual service are Web01 and Web02 – both listens on port 443
If you remember the web hosting configuration in Part 1, the intranet application has SNI enabled on the Web servers to match the website hostname as intranet.vxplanet.local. The SNI application name that we created on the Child VS in ALB is intranet.avi.vxplanet.local. We are not making any changes to the backend applications, instead we will enable TLS SNI from NSX ALB to the backend servers and do a host header rewrite to the SNI hostname configured on the Web servers – intranet.vxplanet.local. The pool configuration is shown below:
The backend web servers are attached to the AppNet portgroup, hence we select it as the placement network so that so that service engines can plumb in the data nics on the port group.
The tls SAN certificate for intranet is selected. This is a single domain SAN cert which we created in Part 1.
At this moment, we should see both the Parent VS and the Intranet Child VS up and running.
Note : We are not sharing the Service Engine Group (SEG) of the DNS Virtual Service that we created in Part 1.
Child Virtual Service 2 – Finance Application
Now we create the finance child VS, following the same procedure as Intranet child VS.
The application domain name on the Finance child VS is finance.avi.vxplanet.local. The SNI hostname configured on the backend web servers is finance.vxplanet.local. As earlier, we enable TLS SNI from ALB to the backend web servers and do a host header rewrite to the SNI configured on the web servers.
The pool members of the Finance virtual service are also Web01 and Web02 – both listens on port 443
The tls SAN certificate for finance is selected. This is a single domain SAN cert which we created in Part 1.
We should see the finance child VS up and running.
We also see that the DNS host records for the parent and child VS’es are auto created in the DNS Virtual Service.
Request Header Analysis
Now let’s connect to the Finance application. Clients connect to the child VS on finance.avi.vxplanet.local, AVI does a host header rewrite of the client request’s host header to finance.vxplanet.local which is then SNI matched with the website hostname configured on the web servers.
As you can see, the request landed on Web01 with the host header as finance.vxplanet.local
Now let’s create a static host entry in the AVI DNS for blog.avi.vxplanet.local to point to the application VIP. As it doesn’t match the SNI hostname of the child VS, the request will be handled by the parent VS. As parent VS is configured with a wildcard cert, client see no browser certificate errors for blog.avi.vxplanet.local. Remember, we did a 301 redirect on the Parent VS for all traffic, hence the client gets redirected to our public blog site https://vxplanet.com
AVI sets the ‘Location header’ in the response to client to achieve the redirect.
Now let’s check the application access – Client should be able to load the Intranet, Finance and Blog pages.
Rewriting Location Headers
In scenarios where a server redirect is send back to the client like content switching policies in a child VS, the location header is set in the server response and the client will redirect to the entry in the location header which may fail. For eg: in the below scenario, I enabled a content switching policy on the intranet child VS, so that https://intranet.avi.vxplanet.local/livenews will be forwarded to a separate server pool. ALB does a host header rewrite and the request reaching the backend server will have the host header as intranet.vxplanet.local and URI /livenews. The backend server set the location header as https://intranet.vxplanet.local/livenews which is send back to the client. This is not desired and we will do a location header rewrite to fix this.
The client URL redirects to https://intranet.vxplanet.local/livenews and depending upon access security configuration, client may or may not connect to the website.
Let’s configure an HTTP response policy on the Intranet child VS to rewrite the location header to the original host header passed by the client – ie, intranet.vxplanet.local -> intranet.avi.vxplanet.local
Now we should see the response location header getting rewritten correctly and the client is able to access the intranet-Livenews page.
Let’s wind up, I hope this article was informative.
If you have any comments / suggestions please reach out to me or leave a comment below, my contact details are available in the About page.
Thanks for reading!!!
Continue reading? Here is the other part of this series:
VxPlanet 