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
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.
|| 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.
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.
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.
Activator in a firewall environment
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.
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
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:
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
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.
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
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
Ask the partner for the external name or IP address and port number for each transport
protocol you intend to use.
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.