Quickstart
- 12 Nov 2021
- 5 Minutes to read
- Print
- DarkLight
Quickstart
- Updated on 12 Nov 2021
- 5 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
This guide is intended to help you get familiar with the NSX-V Firewall, a VMware-powered dual-homed redundant firewall solution.
Logging In
Our team will provision your NSX Firewall, and provide you with a unique login once complete. Login via the URL you are provided by our team, such as:
https://vcd.servercontrol.com.au/tenant/cid-12345-example-company-pty-ltd
You'll be taken to a login prompt, where you will need to provide the username and password also provided to you.
Accessing the Firewall
Once you've logged in to your unique client environment, you'll need to access the firewall's management interface, which is managed entirely through your web browser.
Firstly, select your VDC (virtual data centre) which is where your NSX edge resides:
Once this loads, select Networking, then Edges.
You should see the NSX firewall in the table. Select the firewall by clicking it:
Finally, select Services to load the management window to make any required changes:
From here, you have a variety of options, such as Firewall (for firewall rules), NAT (Network Address Translation - only used for networks that have been configured to support this) along with a few other features which we will not cover in-depth in this article.
Managing Firewall Rules
Firewall rules can be managed through the Firewall tab of the web interface section.
Typically, the firewall will be pre-deployed with a few rules that are maintained by the firewall to remain highly available. These are often called vse and high availability and can be left unchanged. You can toggle viewing these rules with the toggle button:
There is also an explicit default rule called the default rule for ingress traffic which defines the default action for traffic that doesn't match any of the rules above it. This is typically Deny by default, which means all traffic not meeting the rules above this rule are denied. If required for troubleshooting purposes, you can edit this to Accept to allow all traffic (not recommended for long-term use)
To add a new firewall rule, select the + icon.
A new line will be created. Enter a name for the rule, then provide further details as required.
| Component | Description |
| Name | A name to maintain a reference of the rule |
| Source | The inbound "source" of incoming traffic |
| Destination | The intended "destination" of inbound traffic, originating from behind your NSX |
| Service | This specifies unique ports and/or protocols to define. If left blank, the default is any port. |
| Action | Defines whether the rule matches and accepts, permitting the traffic, or denies, denying the traffic. |
Firewall Rule Example (Routed Network)
Here is an example of a network, and a firewall rule that we want to create (this will apply to a ROUTED network only. If your servers use an internal IP range, you will need to review the below NAT section of this guide).
Permit all incoming traffic on Port 80 and Port 443 to a server on a Public IP behind our NSX, which has been assigned and configured on the webserver.
Behind the scenes, your 203.0.113.20 IP is routed within our network to reach your NSX firewall, which then processes the firewall rule.
Once you are happy with the rule, you must Save Changes.
You may also need to create an explicit "Allow Out" rule to ensure your services can reach out to the Internet. Here's an example that allows anything initiated from the Web Server out to the Internet:
It is typically best practice to perform a review of what ports need to be allowed OUT from the server and only permit these, to ensure your rules are as secure as possible.
Firewall Rule Example (NAT Network)
Here is an example of a "NAT" network:
In this scenario, there are multiple IPs assigned to the NSX itself, which can be considered as a "pool", so that you can use IPs as required. The Web Server has an internal IP of 192.168.123.45 on the 192.168.123.0/24 network.
We'll use the same rule as for a routed network, as we intend to use 203.0.113.20 as the "Public IP" of the webserver:
There are a few additional steps here to ensure that NAT is configured correctly, but for now, the firewall rule is sufficient. We'll cover this in detail below.
Managing NAT Rules
Continuing from the NAT network above, we want to translate Public IP 203.0.113.20 to Private IP 192.168.123.45. This can be done in the NAT tab of the NSX.
We'll need two different types of rules for this:
Source NAT (SNAT)
On the pop-up window, there are a few options that need to be configured.
| Name | Purpose |
|---|---|
| Applied On | Specifies Interface. Unless required, please leave the "Applied On" setting the same. This should show similar to SAU-NSX-ROUTING |
| Original Source IP/Range | This will be the Private IP of the server you wish to be NAT'd for outbound communications. Using our example we can use 192.168.123.45 |
| Translated Source IP/Range | This will be the Public IP of the server you wish for the NAT to use. Using our example we can use 203.0.113.20 |
| Destination IP Address | Optional field. If you only want to apply SNAT when targeting a particular Destination, provide an IP here. Otherwise, this is not required and can be left blank. |
| Destination Port | Optional field. If you only want to apply SNAT when targeting a particular Destination Port, provide a Port number here. Otherwise, this is not required and can be left blank. |
| Description | This will appear in the rule lists. Recommended for keeping track of rules |
| Enabled | Enables, or disables, the rule. |
Destination NAT (DNAT)
On the pop-up window, there are a few options that need to be configured.
| Name | Purpose |
|---|---|
| Applied On | Specifies Interface. Unless required, please leave the "Applied On" setting the same. This should show similar to SAU-NSX-ROUTING |
| Original IP/Range | This will be the Public IP of the server you wish for the NAT to use. Using our example we can use 203.0.113.20 |
| Protocol | If you want to invoke NAT for specific TCP/UDP ports (or ICMP), you can select this. It is recommended to select Any. |
| Original Port | If you select TCP/UDP for protocol, you can define the original port. |
| ICMP Type | If ICMP is selected in Protocol, this is available for selection. |
| Translated IP/Range | This will be the Private IP of the server you wish to be NAT'd for inbound communications. Using our example we can use 192.168.123.45 |
| Translated Port | If you select TCP/UDP for Protocol, you can define the translated port. |
| Source IP Address | Optional value, you can invoke NAT only when receiving a request from this Source IP. |
| Source Port | Optional value, you can invoke NAT only when receiving a request from this Source Port. |
| Description | This will appear in the rule lists. Recommended for keeping track of rules |
| Enabled | Enables, or disables, the rule. |
| Enable Logging | Enables logging for the DNAT rule. |
Here is what both rules look like in the list:
You will need to select Save changes for this to be applied.
With these rules now in place, your Web Server should have outbound connectivity to the Internet, and show with a source IP of the Public IP (check this on http://myip.mysau.com.au). Inbound requests made to the Public IP should translate to the Private IP. Make sure you have applicable firewall rules for the Public IP!
If you have any questions regarding NSX rules, please contact our Support team via the MySAU portal (www.mysau.com.au) and we can assist you.
Was this article helpful?