The DMZ Gateway is designed to reside in the demilitarized zone and provide secure communication with EFT Server behind intranet firewalls without requiring any inbound firewall holes between the internal network and the DMZ.

Peer Notification
EFT Server establishes peer notification channels with DMZ Gateway, and DMZ Gateway sends all data only through these channels. The peer notification channel (PNC) acts as a proxy for all transmission through DMZ Gateway; the result is that EFT Server behaves just as if it were in the DMZ, but it is actually safely behind the internal network firewall. The peer notification channel replaces the traditional inbound socket connection method for socket communications. EFT Server and DMZ Gateway communicate over a peer-notification channel using a proprietary protocol. Requests for client connectivity to DMZ Gateway are forwarded to EFT Server; EFT Server then opens connections to DMZ Gateway using a raw socket connection; the DMZ Gateway then pipes all data to the internal server using this socket without any translation. Thus, if the client is using HTTPS, then HTTPS traffic goes over that pipe.

There is no forwarding of client requests. The port that EFT Server and DMZ Gateway use to communicate with each other (4500 by default) is used for PNC communication and EFT Server -> DMZ Gateway sockets for the brokering of client connections. EFT Server specifies which ports on DMZ Gateway are used for the various protocols. For exampleyou could use port 21 for plaintext in the backend EFT Server using local traffic, but configure DMZ Gateway to listen to port 2112 for FTP traffic. You could also enable ports and protocols on the backend server, but disable them on DMZ Gateway.

After restart or settings change, EFT Server determines whether a DMZ Gateway is configured. If so, EFT Server tries to establish a connection. After it connects, EFT Server assumes that DMZ Gateway exists and works correctly. In case of any error (e.g., connection refused, connection reset by peer, PNC protocol error) EFT Server reconnects.

It does not matter whether such errors occurred during connection initialization or later when transfers are taking place. That is, any connection error or PNC protocol error causes EFT Server to remove any existing connection objects and attempt to create a new PNC connection. This allows EFT Server to be independent of DMZ Gateway configuration. EFT Server starts working with DMZ Gateway as soon as DMZ Gateway is running and configured properly. EFT Server polls DMZ Gateway using the Connect() function while trying to maintain the PNC connection in a proper state. Any error causes a reconnect.

Client Impersonation
DMZ Gateway performs client impersonation, which means it replaces EFT Server's socket IP addresses and port settings with values taken from the connecting client socket. None of the sockets created through DMZ Gateway have the DMZ Gateway IP address and port; instead, all sockets created through DMZ Gateway have the IP address and port of the client connection. All information stored in logs or shown in the Administrator status pane have the actual connecting client IP addresses and ports.

Authentication is delegated to the backend EFT Server, as if the client were logging in directly to EFT Server from the internal network. DMZ Gateway essentially acts as a Layer 3 router and simply routes data from the client to EFT Server. Shown below is the general sequence. This sequence assumes that EFT Server has already established the Peer Notification Channel (PNC) to the DMZ Gateway.

Client makes socket connection to DMZ Gateway.

DMZ Gateway sends notification message to EFT Server using PNC.

EFT Server opens a new outbound connection to DMZ Gateway.

DMZ Gateway "glues together" the client socket with the EFT Server socket established in step 3.

DMZ Gateway routes data between client and EFT Server.

Client and EFT Server proceed as if the client were connected directly to EFT Server.

DMZ Gateway Packet Forwarding
DMZ Gateway is not a network hardware device like a bridge/router, so it does not "pass through" modified packets. The DMZ Gateway application (at the application layer) reads in a buffer full of data from the client TCP/IP stream (~4KB) and then sends that data over the server TCP/IP socket. They are completely different TCP/IP packets, with different source and destination locations. The headers, therefore, are different; depending upon the routes, the packet fragmentation, window size, and so on might be different, however, the payload is NOT changed at all.