New year, new tasks. NSX-T has always been known as a flexible solution to deliver microsegmentation and security in many layers. This should not be new to anyone. Before I commence into the topic and the joyful magical world of FQDN rules, let me tell a story.
Some years ago I had a client who had the root domain zone – the dot – added on the domain controllers. All clients, workstations and servers were all using these DNS servers and when any of them asked for resolution of a record that DNS was not aware about, DNS query failed. By adding the root zone, it will not ask any other server ever. This was giving a layer of “security” probably a false one to the client, but worked. And as time was passing they decided to consume Office 365 and that is where this DNS setup was blown out of the water. Not just you need to add a dynamically changing set of IPs to a given – or multiple – name, but without any notification it can change at any time. Imagine that you need to create a firewall rule that is allowing communication towards those continously changing IP addresses.
NSX-T is there with layer 7 options this FQDN thing was limited up to version 3.1 as they were there, but FQDNs were build in and there was no option to add own addresses.
But it is gone, in 3.1 you can add anything you want!
How to do it?
- Obviosuly need to add the wanted FQDN/URL to the inventory.
It is pretty easy to do by navigating to “Inventory -> Context Profiles -> FQDNs” where all bult-in entires live. For the sake of this article I’ll show this by deloying a VM in Azure and generating traffic to that. This host is server.newman.cloud.
2. A Context profile is needed that will consume the FQDN we created just before.
3. Creation of the distributed firewall rules.
Let me explain them one by one:
- Rule ID 2: this is the default rule, which drops all packets that have no matching rule somewhere above.
- Rule ID 9192: rule is important as NSX uses DPI to determine the IP for a requested URL and it needs to get that. This rule must be above the actually filtering rule. In my example I allow both TCP and UDP DNS, your implementation might need only UDP.
- Rule ID 9193: this is where we actually allow – you can disallow too – that from a group – that contains my test virtual machine – HTTP/HTTPS ports will be allowed towards the earlier defined FQDNs/URLs.
Applied to is something I will not discuss here, I am limiting the scope of this rule to the required range.
Testing
By the book, http://server.newman.cloud will be available and show an IIS welcome page. I’ll try to browse https://blog.99999.hu too which is expected not to be working.
All good so far. Let’s allow *.99999.hu just to see if that will start working or not.
Give it a go again.
Cool, it loads. But what happens if I need to allow SSH or RDP towards an FQDN? Clearly the rules I created above will not allow that as in the Service field HTTP/HTTPs are allowed which are TCP80 and 433, while RDP uses TCP3389 by default. When trying to connect, nothing happens.
To make it work, we can tweak the existing rule.
After tesing again it works.
All good, but hold for a second. It does the job but also giving a little headache. As if I change the RDS used port on the server from 3389 to 80, I will be able to RDP to the server still. As rule allows port but not the port+protocol combo. To straighten this a new Context profile should be created:
- HTTP/HTTPS – we have this already – by defining services HTTP/HTTPS and App ID HTTP/SSL.
- RDP where we wull hade RDP as Service defined and RDP as App ID too.
Something like this shown the first context profile.
The ruleset looks like this after the change. Separate rules requires as while multiple Services can coexist in a single rule, only one Context profile is allowed.
If the protocol through port 80 will not be HTTP/SSL it will not work, just as if something else is flowing to port 3389 other than RDP it will not be allowed.
Summary
At this point I have no information that if App ID and Domain (FQDN) combo is supported in a context profile together as official documentation does not stat it is supported or not supported. Tested and works, but may not be supported indeed. Anyway simply FQDN based filtering accompanied with ports are ok for sure.
