Firewalls and proxy servers

Many organizations have firewalls to prevent unauthorized access to their computer networks. A firewall is a server placed outside of a network. The firewall intercepts all inbound connections from the Internet, allowing only authorized users to connect to a server on the organization’s network. In addition, a firewall may limit the outbound connections you can make.

It is likely you or your partners have firewalls to guard against unauthorized connections. You must take firewalls into account when configuring Interchange.

Moreover, your network may require outbound HTTP messages to the Internet to go through a proxy server on your network. On rare occasions, the messages you send may have to go through a proxy server on your partner’s network.

Caution    Message trading can fail if firewalls or proxy servers are not considered when configuring Interchange. This is a common issue for new users. Consult with your network administrator if you need help with firewalls or proxy servers.

The following figure shows where a firewall or proxy server could be located in proximity to your or your partner’s network.

Figure showing example example proxy server locations, near your local network and near your partner's network.

The following are guidelines for outbound and inbound traffic.

  • Outbound – As a general rule, your firewall must be configured to allow outbound HTTP traffic on the port you specify in the URL for your partner (for example, 4080). Your partner's firewall must be configured to allow inbound HTTP traffic on the port you specify.
  • In highly secure environments you may want to set up firewall rules that only allow outbound HTTP traffic on this port to the IP address of your partner. However, this imposes a firewall maintenance burden on you if your partner's IP address changes or if you add partners. The same applies to your partners if they choose to configure their firewalls to allow inbound traffic only from specific IP addresses.
  • Inbound – The firewall considerations for inbound traffic are similar to those for outbound traffic. You can allow blanket inbound traffic on a particular port such as 4080 or you can specify per-partner firewall rules based on the IP address of each partner who connects to you. Specifying partner-specific firewall inbound firewall rules provides a high level of protection against denial-of-service attacks. As with partner-specific outbound firewall rules, however, it imposes a firewall maintenance burden if the partner’s IP address changes or if you add partners.
Note   If your software license supports DMZ nodes, your configuration can be different. See Secure Relay DMZ nodes.

As part of normal operation, the operating system's socket layer dynamically allocates a local port for each outbound connection you make. This requirement is a fundamental part of socket-based protocols such as Telnet, FTP and HTTP. It is not specific to Interchange. For example, if an outbound connection is made to an HTTP host on port 4080, the operating system allocates a dynamic port for the client's end of the connection. This can be seen by running the netstat -an command on the client after the outbound connection is established. If your firewall is so strict that it checks the ports in each packet that passes through it, you must configure the firewall to allow packets containing dynamic ports associated with local addresses. These are typically in the range of 49152 to 65535 with most operating systems, but on some systems the range is 1024 to 65535. These dynamic ports are associated only with outbound connections. It is not necessary to allow new inbound connections on these ports.

Related topics

Interchange in a firewall environment

The following figure depicts a standard architecture for deploying Interchange in an environment where firewalls are present. To maintain document and back-end security throughout the entire process, we recommend placing the transport servers in a demilitarized zone (DMZ) and Interchange in the data layer. A DMZ is the area between an organization’s trusted internal network and an untrusted, external area such as the Internet.

If you place Interchange in the DMZ, take precautions to move the decrypted documents out of the DMZ to a secure location. You can accomplish this any number of ways. The method usually depends on your back-end needs and choice of integration options.

Figure illustrating a standard B2Bi deployment with firewall. FTP, HTTP and email endpoint servers are located in the DMZ. The B2Bi trading engine resides behind the firewall in the protected network.

Related topics

Editing URLs to allow for firewalls

If you use the embedded HTTP or HTTPS inbound transport in your community, you may have to make sure your partners have the right URL. This is because the URL Interchange uses may not be the one your partners need to send documents to you through your company’s firewall or load balancer or both.

When you configure the embedded HTTP or HTTPS inbound transport, the default local URL is in the following format:

http://< cluster machine s >:4080/exchange/<routing ID>

https://< cluster machine s >:4080/exchange/<routing ID>

The local URL contains the internal name (cluster machines) for the computer running Interchange. You cannot change the local URL. If you installed Interchange behind a firewall or load balancer, you must make sure your partners have the correct public URL to send you documents. Values such as the host, port and path in the public URL may be different than the internal values because of remapping performed by the firewall or load balancer.

Depending on your transport, your partner needs a URL in the following format:

http://<fully qualified domain name or IP address>:4080/exchange/<routing ID>

https://<fully qualified domain name or IP address>:4080/exchange/<routing ID>

You may have to contact your company’s firewall administrator to obtain the correct public URL.

You can change the URL for partners on the transport maintenance page of the user interface. After confirming the URL is correct, you can export your community profile for your partner to import as a partner profile. The external URL is contained in the partner profile.

A similar consideration applies to embedded FTP servers. You must specify the external public host and port in the server settings.

Related topics

Getting a partner’s external connection details

If you must send documents via HTTP or FTP, contact your partner to determine the correct external host, port and path (if applicable) for connecting to the partner’s server. If your partner uses Interchange 5 or later, the partner may already have provided the correct public URL in the profile the partner sent you to import as a partner on Interchange.

Ask the partner for the external name or IP address and port number for each transport protocol you intend to use.

From the Partners page, select the partner and open the maintenance page for the transport for sending messages to the partner. Make sure the URL for sending is correct on the Settings tab. Enter a user name and password to connect if required.

Related topics

Proxy servers

If your network requires all outbound HTTP traffic to navigate a proxy server to access the Internet, you can enable this for the community. For more information see HTTP outbound proxy.

Related topics

Related Links