Communication between Integration Server and DMZ
General architecture
A DMZ server is basically a separate Integration Server, on which, for security reasons, only the required communication services, such as FTP or SMTP, are executed. The firewall between the DMZ server and the internet only allows the required ports and protocols.
Communication between the DMZ server and inner Integration Server (in the intranet) is executed via a proprietary protocol of Lobster, the Message Service. A penetration from the outside is thus prevented. The Message Service is an HTTP-tunnelled protocol that uses TCP/IP exclusively. See also section General Configuration.
A firewall between the DMZ server and the inner Integration Server is also required. It must grant communication on the specified Message Service port (usually 8020, but can be configured) in both directions. In addition, HTTP requests and responses are also passed through in both directions, so the HTTP port (usually 80, but can be configured) must also be open.
For maximum security needs, the Message Service can also be configured in pushback mode. In this case, the connection is always established from the inner server and no incoming connections from the internet are required.
If a maximum message size is specified or files should be sent/provided via the DMZ server, those files need to be copied from the internal system to the DMZ server. In order to do this, the firewall needs to be configured to allow for FTP or SFTP connections between inner and DMZ server.
Using the DMZ in the GUI
In a profile
The checkbox via DMZ (only visible if DMZ exists) needs to be set in an Input Agent (phase 1) or a Response (phase 6) respectively. Note: The checkbox is only visible if a DMZ server is available. However, if the following option is present in the configuration file ./etc/startup.xml, it will still be displayed.
...<Set name="ignoreDMZSettings">true</Set>...CloudStorage (Input Agent Cron)
FTP/FTPS/SFTP (Input Agent Cron)
X.400 (Mail)
Response AS2
Response AS4
Response CloudStorage
Response Fax
Response FTP (FTPS, SFTP)
Response HTTP(S)
Response X.400
In a channel
If the option "Invisible to DMZ is not set, settings of the communication channel are replicated to the DMZ server.
If the option is set, the data of this channel is not passed to the DMZ server. The channel will then not exist on the DMZ server. This can be used to define channels, which should not be accessible externally and only be used internally.
In Module "ASM"
Transmission Type AS2
Transmission Type FTP
Transmission Type Fax
Transmission Type OFTP
Transmission Type X.400
Communication scenarios
Partner sends data to via DMZ
See the following diagram for an FTP example.
(1) The partner sends files to the DMZ server via FTP.
(2) The DMZ server creates a message containing the file content and the FTP information (login data, home directory, ...) and sends it to the inner Integration Server. A matching profile for the data is searched for, which then processes the data. Note: Also see the note on the pushback mode.
(3) A response message that the data has been processed is sent to the DMZ server.
(4) If the payload is larger than configured in parameter "streamingSize" (see section Parameters), the data is fetched from the DMZ server via FTP and processed. The connection is established by the inner server.
Fetching partner data via DMZ with cron job
See the following diagram for a cron job of type "FTP".
(1) A request message is sent to the DMZ server: Fetch files via FTP (with login data, home directory, ...).
(2) The FTPService of the DMZ server carries out the transfer.
(3) The DMZ server sends a response message to the inner Integration Server: The files have been transmitted. Please pick them up.
(4) The files are fetched from the DMZ server via FTP and processed. The connection is established by the inner server.
Sending file to a partner via DMZ using a Response
See the following diagram for a file transfer using FTP.
(1) A file is transferred into the DMZ directory, using the FTPService. The connection is established by the inner server.
(2) A request message is sent to the DMZ server: Send the file to the partner via FTP (including login data, home directory, ...).
(3) The DMZ server transfers the file to the partner.
(4) The DMZ server sends a response message to the inner Integration Server. The file has been transferred. Note: Also see the note on the pushback mode in section Interaction Lobster data and DMZ.
Providing data for partner on DMZ
See the following figure for a transfer using FTP.
(1) A file is stored into the DMZ directory using the FTPService. The connection is established by the inner Integration Server.
(2) The partner picks up the file there.
Note: The MessageService is not needed in this case.
Kubernetes/Docker environment
If you are running a DMZ server in a Kubernetes or Docker environment, you can set the system property "-Dhub.datawizard.enableDmzIpResolving=true". This will force the DMZ server URL to always be resolved, instead of just using the initial (and possibly no longer valid) IP of the DMZ server. You must set the system property on the inner Integration Server, or on the Node Controller and all Working Nodes if you are using Load Balancing.