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 Activator.
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 Activator. 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.
The following are guidelines for outbound and inbound traffic.
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 Activator. 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.
The following figure depicts a standard architecture for deploying Activator 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 Activator 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 Activator 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.
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 Activator 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://<machine>:4080/exchange/<routing ID>
https://<machine>:4080/exchange/<routing ID>
The local URL contains the internal name for the computer running Activator. You cannot change the local URL. If you installed Activator 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.
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 Activator 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 Activator.
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.
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.