In the last post, VMware NSX™ Distributed Firewall installation and operation was verified. In this entry, the FTP (file transfer protocol) ALG (Application Level Gateway) is tested for associating data connections with originating control connections – something a stateless ACL (access control list) can’t do.

An added benefit over stateless ACLs – most compliance standards more easily recognize a stateful inspection-based firewall for access control requirements.

To check ALG support for a particular NSX version, refer to the VMware NSX Administration manual. VMware NSX version 6.2 supports FTP, CIFS, ORACLE TNS, MS-RPC, and SUN-RPC ALGs. Do expect additional ALG protocol support with future versions of NSX.

Assuming a default firewall rulebase for simplicity, and a basic setup:

  • three ESXi vSphere 6.0 hosts in a cluster
  • NSX installed, with the NSX Manager installed on the first host 
  • two guest VMs running Centos: one running an FTP server, the other an FTP client

Simplified diagram, along with connections for the following test:

layout

Previously, an ESXi host command line was used to interact with the Distributed Firewall. Here, the NSX Manager Central CLI  – a new option with NSX 6.2 – is used. Slightly different incantations, but the same results can be had with either CLI. 

First, log into the NSX Manager via SSH. Once in, access to ‘show’ commands is available. Determine the cluster and VM names with ‘show cluster all’ and ‘show cluster <cluster name>’.

In the screenshot below, ‘ssh admin@nsxm’ ; ‘show cluster all’; then ‘show cluster domain-c26’ are executed. The cluster name is required to determine hosts in the domain.

1-cli

Above, host-32 runs the FTP server VM. Pull the filters on all vNICs for that host, while also verifying the Distributed Firewall is active with ‘show dfw host host-32 summarize-dvfilter’.

2-cli

Extracting the filter name from the results, we notice ‘nic-71375-eth0-vmware-sfw.2’. Which leads to the next command, ‘show dfw host host-32 filter nic-71375-eth0-vmware-sfw.2 rules’ to view the rulebase for the vNIC on the FTP server VM.

3-cli

Reviewing the default rules, test traffic for FTP should match the last rule – known in this CLI environment as rule 1001.

Separately, an FTP session starts on the FTP client (172.16.0.37) to the FTP server (172.16.0.36). Issuing ‘show dfw host host-32 filter nic-71375-eth0-vmware-sfw.2 flows’ command, both control and data connections are seen matching the default allow rule. It must be a Passive data connection! Both control and data are initiated Client to Server; with the second going from a high source port to a high destination port. This is the type of connection platforms without ALG support struggle with.

4-cli

While connected, a directory listing is issued, ensuring a data connection comes up.

10-ftp-before-PASV-a

Forcing the FTP client to use an Active data connection (ftp -A <hostname>) results in different flows, as seen with ‘show dfw host host-32 filter nic-71375-eth0-vmware-sfw.2 flows’.

5-cli

The data connection is indeed an Active one! It is initiated in a different direction (OUT versus IN in the screenshot, circled in red), and is from the FTP server’s source TCP port 20.

To make it a little interesting – add a rule to allow only TCP port 21 into the FTP server; along with a second rule to block anything else from the FTP client VM. 

To define, create a new service – but only chose TCP for the Protocol – as opposed to FTP. Specifying just destination port 21 for a rule should match the FTP control connection, but nothing else – giving precedence over the FTP ALG. 7-tcp-a

Place the new rule at the top of the rulebase, as first match wins; followed by a rule blocking all other connections initiated from the FTP client to the FTP server.

6-gui-a

The FTP control connection should succeed on the top rule; Passive data connections should fail on the second rule; and Active data connections should succeed on the default (last) rule.

Taking a look at the CLI version of the rulebase with ‘show dfw host host-32 filter nic-71375-eth0-vmware-sfw.2 rules’, we notice the new test rules are known as rule 1006, for the FTP control connections; and rule 1005 blocking the Passive data connection.

8-rules-a

Initiating a Passive FTP connection  – directory listings do not work anymore! As expected, it does not look like the data channel is coming up. Ctrl-C gets the prompt back.

9-ftpclient-after-PASV

Now a try with active FTP – all is well!

11-ftp-A-after-a

One final test – specifically calling out the FTP ALG in a rule instead of relying on a default allow rule. Update the top rule with FTP as the service to accomplish this.

13-cli-a

The rule corresponding to the change appears a little different on the command line. Notice ‘as ftp’ at the end of rule 1008, in addition to TCP port 21. There are also two associated lines added, to assist the FTP ALG.
To test, initiate two FTP sessions; the first Passive, with the second Active. View the flows for the FTP server VM vNIC. Both data connections are correctly associated with FTP rule (1008) instead of default rule (1001) before being allowed through to the FTP server VM.

14-cli-a

While most users are not aware of FTP’s nuances, it is used for file downloads – with either dedicated FTP clients or web browsers. In addition, it is a great protocol to show off more involved firewall processes, such as ALGs. While RPC services are not normally available from servers on the Internet – they do show up on internal networks; and VMware NSX Distributed Firewall has you covered on that front.

Interested in learning more about VMware NSX? The Hands on Labs are a great FREE resource, with numerous NSX labs, like HOL-SDC-1603 : VMware NSX Introduction. Need a 90 second introduction video to HoL – right here!

As Chris King previously mentioned, we have a lot of 2-day NSX Exploration classes underway – ask your VMware team if you are interested in attending. Maybe I’ll see you at one.