Quickstart
  • 12 Nov 2021
  • 5 Minutes to read
  • Dark
    Light

Quickstart

  • Dark
    Light
  • New

Article Summary


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. 


ComponentDescription
NameA name to maintain a reference of the rule
SourceThe inbound "source" of incoming traffic
DestinationThe intended "destination" of inbound traffic, originating from behind your NSX
ServiceThis specifies unique ports and/or protocols to define. If left blank, the default is any port
ActionDefines 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. 

NamePurpose
Applied OnSpecifies Interface. Unless required, please leave the "Applied On" setting the same. This should show similar to SAU-NSX-ROUTING
Original Source IP/RangeThis 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/RangeThis 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 AddressOptional 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 PortOptional 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. 
DescriptionThis will appear in the rule lists. Recommended for keeping track of rules
EnabledEnables, or disables, the rule.
 


 

Destination NAT (DNAT)


On the pop-up window, there are a few options that need to be configured.
 

NamePurpose
Applied OnSpecifies Interface. Unless required, please leave the "Applied On" setting the same. This should show similar to SAU-NSX-ROUTING
Original IP/RangeThis 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
ProtocolIf you want to invoke NAT for specific TCP/UDP ports (or ICMP), you can select this. It is recommended to select Any
Original PortIf you select TCP/UDP for protocol, you can define the original port. 
ICMP TypeIf ICMP is selected in Protocol, this is available for selection. 
Translated IP/RangeThis 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 PortIf you select TCP/UDP for Protocol, you can define the translated port. 
Source IP AddressOptional value, you can invoke NAT only when receiving a request from this Source IP. 
Source PortOptional value, you can invoke NAT only when receiving a request from this Source Port. 
DescriptionThis will appear in the rule lists. Recommended for keeping track of rules
EnabledEnables, or disables, the rule. 
Enable LoggingEnables 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?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.
ESC

Eddy, a super-smart generative AI, opening up ways to have tailored queries and responses