The firewall gateway feature enables additional end-to-end
connectivity options for use in environments with specific TCP/IP
connection management policies.
The firewall gateway is capable of negotiating multiple firewall
hops and network address translation (NAT). It also allows you to
configure network traffic so that it is initiated from the more secure
network zone.
The Firewall Gateway provides the following functionality:
- Gateway instances interoperate over a single physical relay connection.
Logical connections are multiplexed over the relay. The origination
direction of the relay connection is configurable to match enterprise
firewall transit requirements.
- Relay support enables a logical connection to span multiple firewall
zones. Each relay instance can optionally provide access to the upstream
management network. Multiple relays can be chained to provide seamless
hops across multiple zones.
- Proxy support provides a transparent interface to IBM® Tivoli® Monitoring
components. Server proxy components reside downstream and listen for
inbound connections. Client proxy components reside upstream and make
connections to services on behalf of downstream endpoints.
- All ports used by gateway instances are configurable. Port pooling
is available to constrain client proxy connections to designated port
values.
- Multiple failover addresses can be configured for all gateway
connections.
NAT alone is not a reason to use the firewall gateway, which is
content-neutral and can proxy any TCP connection. In most cases,
NAT processing is handled by the PIPE protocol (IP.PIPE or IP.SPIPE),
which can be used without the firewall gateway. Use the gateway when
you have any of the following scenarios:
- A single TCP connection cannot be made to span between IBM Tivoli Monitoring
components An example would be that there are multiple firewalls between
these components and a policy that does not allow a single connection
to traverse multiple firewalls.
- Connection requirements do not allow the IBM Tivoli Monitoring
default pattern of connections to the hub monitoring server. An example
here would be agents residing in a less-secure zone connecting to
a monitoring server residing in a more-secure zone. Security policy
would only allow a connection to be established from a more-secure
zone to a less-secure zone, but not the other way round.
- You must reduce open firewall ports to a single port or connection.
For example, rather than opening the port for every system being monitored,
you would like to consolidate the ports to a single “concentrator”.
Connection requirements do not allow the IBM Tivoli Monitoring default pattern
of connections to the hub monitoring server.
- You must reduce open firewall ports to a single port or connection.
You must manage agent failover and monitoring server assignment symbolically
at the hub monitoring server end of the gateway. Because gateway
connections are made between matching service names, an administrator
can change the failover and monitoring server assignment of downstream
gateway agents by changing the client proxy bindings next to the hub
monitoring server.
In the context of firewalls, the server and client relationship
can best be described in terms of upstream and downstream.
Those entities that open a socket to listen for requests are at the
upstream or server end. Those entities connecting to the server are
at the downstream or client end. Using one or more relay configurations,
logical connection requests flow from a listening downstream server
proxy interface, and terminate in an outbound connection from an upstream
client proxy interface to a listening server. Intermediate relay configurations
consist of an upstream relay interface containing at least one downstream
relay interface.