DMZ Gateway Technical FAQ

Below are some frequently asked technical questions about the DMZ Gateway.

Does DMZ Gateway modify the client’s packets?

DMZ Gateway effectively terminates the client’s TCP/IP session at the DMZ Gateway. The client data contained within the payload of the TCP/IP packet is transmitted to the server over the independently established TCP/IP connection between the server and DMZ Gateway. No modifications are required or performed on the actual payload data, but rather the payload is sent as is to the server. Thus, if the client is using HTTPS, then the HTTPS payload is streamed on through to the server. Unlike a network hardware bridge/router device, the DMZ Gateway does not "pass through" modified packets by changing the TCP/IP or frame layer headers. Instead, the DMZ Gateway reads in a buffer full of data from the client TCP/IP stream (~64KB) and then sends that data over the TCP/IP socket established earlier by the server (see step 4 above). The result is a set of completely different TCP/IP packets with different source and destination locations but containing the original payload. Keep in mind that the original (source) location (IP address) is known by the server as it was provided to the server earlier by DMZ Gateway (see step 3 above).

Does DMZ Gateway forward client connections to the server?

The DMZ Gateway does not forward client connections. Only the payload (data) is forwarded or passed through to the server.

How do the server’s listening ports affect DMZ Gateway?

EFT allows you to define two groups or sets of listening ports. When used with DMZ Gateway, the external listening ports (DMZ Gateway Internet facing) are specified in EFT Server’s administration interface on the DMZ Gateway tab. EFT’s second set of listening ports, defined on the Site’s Connections tab, are ONLY used for establishing internal listening ports (server-network facing) for each supported (and enabled) protocol. These sets of ports can be the same or different (even for the same protocol). When DMZ Gateway is NOT being used (i.e., the server is residing in the DMZ or is being used for internal, network-facing transactions), then only a single set of ports is used, defined on the Site’s Connections tab, for all incoming connections to EFT.

How is the PNC created and maintained?

Once configured to work with DMZ Gateway, the server (when running) will always attempt to initiate, maintain, and, if necessary, reconnect to DMZ Gateway’s PNC port. No further administrative action is required in the server to establish or maintain communication after the initial setup. From DMZ Gateway's perspective, if the PNC channel is broken, DMZ Gateway will refuse new (and existing) client connections until the server re-establishes a connection.

The server will “ping” the DMZ Gateway every 5 minutes. If a reply is not received within 10 seconds, the server considers the connection lost, severs the current connection, and then attempts to reconnect. DMZ Gateway also maintains its own awareness (ping/pong) of whether the server is connected. Every 30 seconds, DMZ Gateway determines whether it has received a pong message from the server since the last ping. If it has, it will ping again; if not, it drops the connection. This test allows it to free up ports if the server is not available (i.e., no longer responds to ping) and for error reporting. (Refer to the Knowledge Base article "How do EFT and DMZ Gateway Server communicate with each other?" for information about changing these defaults in EFT 6.2 and later and DMZ Gateway 3.0 and later.)

The PNC between the server and DMZ Gateway is not encrypted; however, the external client’s encrypted session will be streamed all the way through to the server, so only the intercommunications between the server and the DMZ Gateway are in the clear, not the client session (assuming they used a secure protocol such as SFTP or HTTPS). (Refer to DMZ Gateway Secure PNC for information about configuring a secure PNC.)

But won’t an insecure PNC be vulnerable to a man-in-the-middle attack?

In order to usurp the PNC connection, the attacker would need full control over the internal systems on which the server is running. This access would indicate a far greater threat to Confidentiality, Integrity, and Availability (CIA) already in place in your network. Keep in mind that the internal firewall should be configured to allow only outbound connections from the server to DMZ Gateway via the PNC port. If configured as such, then the ability to usurp the control connection doesn’t really gain the attacker much of an edge. Even if a connection were seized, the attacker would need to perform several other non-trivial steps, such as spoofing the server’s IP address*, reverse engineering the protocol, opening ports on the firewall, altering the routing table, etc.

*DMZ Gateway provides an optional whitelist for IP addresses that are allowed to connect to the PNC port. (Refer to DMZ Gateway Secure PNC for information about configuring a secure PNC.)

Isn’t DMZ Gateway just giving users a way to bypass the firewall without providing any security functionality or filtering?

The DMZ Gateway is not designed to replace firewalls or content-inspection devices. The DMZ Gateway’s main purpose is to allow network administrators to minimize the exposure surface area by allowing you to further lock down the internal firewall such that only outbound connections are needed, thus eliminating the need for inbound connections through your internal firewall to your directory server (for user authentication) or SQL/Oracle server (for transaction auditing). Furthermore, it eliminates the need to store file data in the DMZ. Essentially DMZ Gateway limits the attack vector to the server as opposed to multiple other internal servers. As far as filtering is concerned, it is important to note that DMZ Gateway does not replace any other sort of filtering mechanism, such as firewalls, web application firewalls, content inspection devices, and so on. DMZ Gateway is intended to work with and extend existing security mechanisms.

So then, any vulnerability in the server is essentially exposed to the Internet?

Assuming vulnerabilities exist then yes, those would be exposed to the Internet; however, the attack vector would be limited to attacks that could be accomplished over the network protocols that are proxied through the DMZ, as there would be no means for the attacker to establish inbound connections to the server directly, because of the EFT <> DMZ Gateway architecture.

What about Denial of Service attacks? Wouldn’t it be trivial to pump traffic all the way through the DMZ to where EFT resides?

EFT is a file transfer server. It is meant to handle anything you can throw at it over the various listeners. EFT includes a number of DoS and flood-prevention mechanisms to mitigate these sorts of attacks. This would be the same if you stood up EFT (or any other FTP server) in the DMZ and terminated connections there. If EFT Server designates one or more IP addresses as needing to be blocked, it will add those IP addresses to its own internal IP Access Rules list and communicate that list to DMZ Gateway. DMZ Gateway will subsequently block all external clients with blacklisted IP addresses on the access list.

If there is a change to EFT’s IP access rules, are the changes communicated immediately to the DMZ Gateway when those changes are applied?

Yes, IP address access policy changes (whether manually initiated or as a byproduct of an auto-ban) are automatically propagated to the DMZ Gateway (v3.0 and later).