The first thing everyone does with NSX is try to create firewall rules between IP addresses. I consider this a mistake because the DFW can key off a lot better markers than IP addresses. Either way at some point you will want to use IP addresses in your rules. This post will describe how to setup firewall rules between IP addresses.
Setup:
I have two Linux machines each on their own subnet:
Linux1 – 172.16.1.10 – 172.16.1.0/24 network
Linux3 – 172.16.10.10 – 172.16.10.0/24 network
Routing is setup between the hosts so they can connect to each other. I would like to block all traffic except ssh between these subnets. We are going to assume that both of these networks exist in NSX.
NSX Setup:
First we have to set up an IP set in NSX Manager. This is suprisingly a set of IP addresses.
- Login to the vSphere web client
- Click networking and security
- Select your NSX Manager and expand it
- Select Manage -> grouping objects
- On the lower pane select IP Sets
- Press the green plus button to add a new set
- Setup each set as shown below:
Tale of multiple cities:
Here is where NSX gets interesting you have multiple ways to block access. First a little understanding of firewall constructs in NSX:
- Security Groups – these are groups of machines / constructs they can include IP sets, MAC sets, dynamic name based wild card information. They can contain whole datacenters or a single virtual machine. It can be very dynamic with boolean conditions.
- Security Policies – These are groups of firewall rules and introspection services. These are policies that are applied to security groups. Each of the firewall policies assume that they are assigned to one or more security groups. So your source or destination needs to be the policies assigned security group. The opposite side (source/destination) needs to either be a security group or any.
Remember we want the following rules:
- SSH between 172.16.1.0/24 and 172.16.10.0/24 should be allowed bi-directional
- Everything else between them should be blocked
Within these constructs there are a number of possible options for the firewalls:
- Option 1 – rules in this order
- Firewall rule allowing ssh between source: assigned policy group and destination: 172.16.10.0/24
- Firewall rule allowing ssh between source: 172.16.10.0/24 and destination: assigned policy group
- Firewall rule blocking any between source: assigned policy group and destination: 172.16.10.0/24
- Firewall rule blocking any between source: 172.16.10.0/24 and destination: assigned policy group
- Assign the security policy to 172.16.1.0/24
- Option 2 – Security Groups
- Firewall rule allowing ssh between source: assigned policy group and destination: assigned policy group
- Firewall rule blocking any between source: assigned policy group and destination: assigned policy group
- Assign the security policy to 172.16.1.0/24 and 172.16.10.0/24
- Option 3 – Two rules
- Rule 1
- Firewall rule allowing ssh between source: Assigned Policy group and destination: 172.16.10.0/24
- Firewall rule blocking any between source: Assigned Policy group and destination: 172.16.10.0/24
- Assign Policy to 172.16.1.0/24
- Rule 2
- Firewall rule allowing ssh between source: Assigned Policy group and destination: 172.16.1.0/24
- Firewall rule blocking any between source: Assigned Policy group and destination: 172.16.1.0/24
- Assign Policy to 172.16.10.0/24
First question anyone will ask is why would I not use option 2? It’s smaller and easier to read. It does accomplish the same goal. It does lack granularity in design. What if you had a third subnet 172.16.20.0/24 and you only wanted it to access 172.16.1.0/24. Option 1 would easily be able to do this, while option 2 would mistakenly open up 172.16.10.0/24. This is the heart of firewall design. Layer rules to create granularity. I am not a master of the firewall but I do have a few suggestions:
- Outbound firewall rules sound great but right away will kill you in complexity
- Protect the end points… apply rules to the destination (think apply rules to the web server instead of every PC) If you need to apply source rules do it on the destination
- Use naming conventions that describe the purpose of the rule Allow-SSH-Into-Production
- Consider using a DROP all on your default rule and then applying only allow rules in security groups
- Rules that are part of the default and not created in service composer don’t show up in the GUI so don’t use them beyond the default DROP apply everything as a security policy
Let’s do Option 1
- Return to networking and security and select service composer
- Select security groups and create a security group for each IP Set
- Repeat for the other subnet
- Click on security policies
- Create a new policy as shown below
- Now that you have it build your just need to apply it to a security group
- Click on the text of your Security Policy
- Select Manage -> Security Groups
- Click edit and add 172.16.1.0/24
Now your rules should work. You can test with ping and SSH. Using the same dialog’s you can create option 2 or 3. The same rules you use for firewalls on physical entities need to apply to DFW. You need to think before you create or you will be in firewall spawl.