Firewall gateway support

A firewall gateway provides end-to-end connectivity options for environments with specific TCP/IP connection management policies. The firewall gateway can negotiate numerous firewall hops and supports network address translation. You can use a firewall gateway to configure network traffic so that it is always initiated from the more secure network zone, if two communicating components are in zones with different security levels.

A firewall gateway can be the most advantageous firewall configuration if any of the following conditions apply:

• A single TCP connection cannot span between product components. Example: communication between components requires crossing more than one firewall in an environment with a policy that does not allow a single connection to traverse more than one firewall.
• Connection requirements do not allow the default pattern of connections to the hub monitoring server. Example: agents fail to connect to a monitoring server in a zone with higher security than that of the agents; security policy allows a connection to be established from a more secure zone to a less secure zone, but not the other way around.
• Open firewall ports must be reduced to a single port or connection. The gateway can consolidate the ports into one. Example: agent failover and monitoring server assignment must be managed symbolically at the hub monitoring server end of the connection. Because gateway connections are made between matching service names, an administrator can change the failover and monitoring server assignment of agents by changing the client proxy bindings at the hub monitoring server.

To configure the firewall gateway, you must perform two tasks:

1. Create an XML document that specifies a set of zones, each of which contains at least one server (upstream) interface with one or more embedded client (downstream) interfaces. The XML document must be stored as a member of the rhilev.rte.RKANPARU library, and the member name must conform to z/OS® naming standards (no more than 8 characters).

   Here is an example of a gateway XML document, stored as the ZOSPROXY member of the RKANPARU library:

   000001 <tep:gateway xmlns:tep="http://xml.schemas.ibm.com/tivoli/tep/kde/"     
   000002  name="zOSproxy" threads="32">
   000003 <zone name="trusted" maxconn="512" error="ignore">
   000004 <interface name="zosproxy_upstream" role="proxy">
   000005 <bind ipversion="4" localport="pool2K" service="tems_pipe">
   000006 <connection remoteport="1920">127.0.0.1</connection>
   000007 </bind>
   000008 <interface name="zosproxy_downstream" role="listen">
   000009 <bind ipversion="4" localport="60902">
   000010 </bind>
   000011 </interface>
   000012 </interface>
   000013 </zone>
   000014 <portpool name="pool2K">20000-21023 21024-22047</portpool>
   000015 </tep:gateway>

   For reference information about the elements of the gateway XML document, see the XML document structure section of the Firewalls appendix to the IBM Tivoli Monitoring: Installation and Setup Guide.

2. In the KppENV member of the rhilev.rte.RKANPARU library, add a KDE_GATEWAY environment variable that references the XML document.
   Example:

    KDE_GATEWAY=ZOSPROXY