When setting up an AppGate system, the most common problem is to get any surrounding firewalls to allow the necessary traffic.
All application traffic from the client to the AppGate server will go through the SSH tunnel. On the AppGate server it will be decrypted and travel onwards as clear text.
The AppGate Security Server is by default using port 22 for incoming connections for SSH2. This port number can be changed and other ports can be added using the AppGate Console.
The AppGate Security Server also acts as a web server to allow for downloading of the various clients, the AppGate Applet and the Java Web Start files. The web server listens on port 80 by default. This can be changed from the configuration files. The web server can also be configured for HTTPS/SSL and will then normally listen on port 443.
If the AppGate server is connected on a DMZ, the firewall rules must allow for the clients to reach the SSH port (22) and for the web server port 80 and/or port 443 (SSL).
From the AppGate server to the application servers the traffic will be using the normal application port numbers and protocols. Therefore, any firewall in between must allow for the application data to flow accordingly.
When the Port Forward method is used, the source IP address of the traffic to the application server will be the IP address of the AppGate server.
If IP tunneling is used, the source IP address of traffic going to the application servers will be an address from the configured IP tunneling address pool.
The AppGate Security Server can use one or more Ethernet interfaces. The AppGate server can have one or more IP addresses on each interface. It will normally not forward traffic between interfaces. In terms of routing, the following should be considered.
If one of the interfaces is connected to the Internet, or possibly any large routed internal network with many IP networks, it is probably a good idea to use the default route for that interface. It is only possible to define one default route for the whole AppGate server.
Additional routes may be added as static routes for any interface.
It is possible to use the AppGate server as a simple firewall and let it forward normal non-encrypted traffic between interfaces. This can be useful to allow for traffic from a protected application server to reach the outside. In this case, static routing entries are probably needed on the application server and on the hosts it is communicating with. Those static routes should point to the AppGate server as the gateway.
There are two approaches when defining an IP tunneling address pool.
Use a new IP subnet that is not part of any of the other connected IP networks.
This will require routers in the network to know about this new subnet and route traffic for it to the AppGate server.
Use a part of an IP subnet that is directly connected to one of the interfaces.
The AppGate server will issue Proxy ARP packets on this interface for all the IP addresses defined in the IP tunneling address pool.