Overview of Secure Relay nodes

Secure Relay is a way to exchange messages with trading partners via an agent with a port-forwarding service. The agent is deployed on a computer in your DMZ. This is secure because:

  • The Secure Relay master agent, hosted by Interchange control node, makes the connections between it and the Secure Relay router agent in the DMZ. The router agent does not initiate connections to your protected network.
  • Connections between the master agent and router agent are encrypted and mutually authenticated over TLS.
  • The multiplexed, persistent connection between the master and router support bi-directional message traffic. You can send or receive messages over the same connection.

Additional security can be engaged by using IP address whitelists in conjunction with Secure Relay. See Manage IP address whitelists.

The following figures illustrate configurations for trading messages via Secure Relay. Both figures depict a fail-over configuration with redundant Interchange nodes and Secure Relay router agents. If you elect to use DMZ zones, these configurations can be applied to each zone.

The following figure illustrates the reception of inbound messages via Secure Relay:


Figure showing a B2Bi SecureRelay failover configuration for inbound messages.

The following figure illustrates the sending of outbound messages via Secure Relay:


Figure showing a B2Bi SecureRelay failover configuration for outbound messages.

Types of secure connections

The master agent hosted by Interchange control node connects to the router agent and sets up two secure connections. These are the only connections between Interchange cluster hosts and DMZ hosts. The master agent sets up and manages port-forwarding rules for inbound connections. For each delivery exchange point configured to use DMZ nodes, the master agent tells the node to forward connections through the secure multiplex connection. An example of such a forwarding instruction is:

fwd sr1:4080 to te1:4080

In this example, it is not necessary for port 4080 to be open on the inner firewall because any connection to port 4080 on the DMZ node is forwarded through the multiplex connection to Interchange.

If additional Interchange nodes are started, these also connect to the DMZ node and set up the necessary forwarding rules for the exchange points they host. If running in cluster of multiple computers, make sure all instances of Interchange on all machines share the same common directory. The common directory is specified by the commonPath property in the filereg.xml file in the conf directory.

The earlier figures show the two types of encrypted connections the master agent makes to the router agent:

  • Administrative – The administrative connection is what the master agent uses to send port-forwarding rules to the router agent. Rules are sent dynamically to account for changes within Interchange (for example, a node starting or stopping). Once the connection has been established, the master agent sends requests and the router agent responds with the result of each operation.
  • Multiplex – The multiplex connection is the bi-directional channel through which e-commerce messages and receipts flow.

Both the administrative and multiplex connections are persistent, so long as Interchange server and router agent are running.

Certificates authentication keys and passwords

Before you can deploy a Secure Relay router agent node you must generate the set of keys, certificates and internal password used for mutual authentication between the master agent and router agents. The first time you add a node and every time you update the node or certificates you are prompted to repeat this task.

You can then deploy the DMZ node to the DMZ machines. The DMZ master agent and router agents automatically execute mutual authentication using the protected password and certificates. You do not need to re-enter the password to enable Secure Relay operation.

For details of procedures for generating certificates and passwords, see Add a DMZ node.

Certificate maintenance and alerts

You can repeat the certificate generation procedure at any time if you need to replace DMZ certificates. When you regenerate certificates you must delete, recreate and re-export the DMZ nodes.

An alert task is displayed in the Tasks panel of the Welcome page when the DMZ certificates are missing. You can click the task link to complete procedures for generating the DMZ certificates as described above.

Additionally, if DMZ certificates are missing, a new task link is displayed on the DMZ nodes page. If you have DMZ node management rights, this link redirects you to the page where you can provide the password. You must then complete the certificate generation procedure. See Add a DMZ node.

Certificates management for upgrades

When you upgrade from an earlier Interchange configuration that uses a DMZ, to Interchange 5.12, you must complete the following steps:

  1. Delete the existing DMZ nodes.
  2. Provide the certificate and key encryption password.
  3. Generate the certificates.
  4. Re-export each DMZ node.

System exports

When you create an entire system export, and import it into a another Interchange system, the connection between master agent and router agent is successful after you complete the following steps:

  1. Delete the existing DMZ nodes.
  2. Provide the certificate and key encryption password.
  3. Generate the certificates.
  4. Re-export each DMZ node.

Load balancing

A load balancer is required to distribute inbound connections among DMZ node ports. The difference, as compared to the load balancer sending connections directly to Interchange, results from the redundant connections between Interchange nodes and DMZ nodes. This requires each embedded server on each Interchange node to be represented by a unique port on each DMZ node. So instead of sending connections to only two locations (for example, te1:4080 and te2:4080) the load balancer sends connections to four locations (for example, dmz1:4080/4081 and dmz2:4080/4081). Connections to 4080 on either DMZ node are automatically forwarded to te1. Connections to 4081 on either DMZ node are automatically forwarded to te2.

FTP passive ports are accommodated using a variation on this scheme. When partners use passive FTP mode (the default for most modern FTP clients), connections come and go dynamically as GET, PUT and LIST requests are made. Only Interchange node that accepted the control connection from the partner is listening for passive connections associated with that partner FTP session. Each time a GET, PUT or LIST request is made, a temporary forwarding rule is dynamically sent to all DMZ nodes to ensure the partner's data connection is routed to the correct Interchange node, even if the load balancer sends it to a different DMZ node than the one that is proxying the control connection.

Specific information for configuring load balancers is provided in Configure load balancer or firewall.

Security features

Secure Relay nodes have the following security features:

  • Connections to the router agent are established by the master agent within Interchange.
  • Connections are encrypted. Authentication is mutual.
  • Forwarding is initiated and canceled in concert with the starting and stopping of the embedded server in the protected network. Forwarding is not permitted for an embedded server that is not running.
  • FTP passive ports are forwarded dynamically as the embedded FTP server assigns passive ports to clients. Forwarding is not permitted for a passive port that is not currently assigned to an FTP client.
  • The history of connections is written to the router agent’s log file.

Related topics

Related Links