Communication between Integration Server and DMZ‌

General architecture


images/download/attachments/135168570/DMZ-version-3-modificationdate-1740043178485-api-v2.png


A DMZ server is a separate Lobster 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 Lobster_data 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 Lobster_data 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 Lobster_data should send/provide files 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 Route (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 Route AS2

  • Response Route AS4

  • Response Route CloudStorage

  • Response Route Fax

  • Response Route FTP (FTPS, SFTP)

  • Response Route HTTP(S)

  • Response Route 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 Lobster_data via DMZ‌‌


See the following diagram for an FTP example.

images/download/attachments/135168570/4-version-3-modificationdate-1740043193414-api-v2.png

(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 Lobster_data. Lobster_data searches for a matching profile for the data and processes it. Note: Also see the note on the pushback mode in section Interaction Lobster_data and DMZ‌ .

(3) Lobster_data sends a response message to the DMZ server that the data has been processed.

(4) If the payload is larger than configured in parameter streamingSize (see section Parameter‌s), Lobster_data fetches the data via FTP from the DMZ server and processes it. The connection is established by the inner server.

Lobster_data cron job fetches partner data via DMZ‌


See the following diagram for a cron job of type FTP.

images/download/attachments/135168570/3-version-3-modificationdate-1740043206494-api-v2.png

(1) Lobster_data sends a request message 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 Lobster_data: The files have been transmitted. Please pick them up.

(4) Lobster_data fetches the files via FTP and processes them. The connection is established by the inner server.

Lobster_data sends file to a partner‌ using a Response Route via DMZ‌‌


See the following diagram for a file transfer using FTP.

images/download/attachments/135168570/1-version-3-modificationdate-1740043218872-api-v2.png


(1) Lobster_data transfers a file into the DMZ directory, using the FTPService. The connection is established by the inner server.

(2) Lobster_data sends a request message 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 Lobster_data. The file has been transferred. Note: Also see the note on the pushback mode in section Interaction Lobster data and DMZ‌.

Lobster_data provides data for partner on DMZ‌‌


See the following figure for a transfer using FTP.

images/download/attachments/135168570/2-version-3-modificationdate-1740043234153-api-v2.png


(1) Lobster_data stores a file in the DMZ directory using the FTPService. The connection is established by the inner 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.