The AppGate works by creating an SSH encrypted tunnel from an AppGate SSH client to the AppGate server. All application traffic that is needed to be passed to back end application servers has to be redirected down the tunnel.
AppGate does this in a couple of ways, one being the use of port forwards.Port Forwards are local listeners which are setup on 127.0.0.x on the client machine by the AppGate client when a service is started.
For example, one IP Access component configured with a destination host of server1 (using a name which the AppGate server can resolve), protocol TCP, Destination port 80, local port 80 (The listener port to create on the client machine).
When the service is run on the pc within the AppGate client it knows how to create a listener on a free 127.0.0.x address and any traffic hitting this port to pass it up to the AppGate server through the encrypted tunnel. To get a web browser to use this port, look at the Access Details tab in the AppGate client (when connected) to see what the local listener IP address is set to. This method is not really feasible unless you are testing connections, so AppGate can redirect host names so that in the web browser you just type http://server1. To be able to do this the AppGate client must be able to modify the client pc's hosts file located in %windir%\system32\drivers\etc. This is done automatically as the server name is configured in the IP access component and the IP address with name is set into the AppGate server as a host (as in a previous post).
So make sure the hosts file is being written too, when logged into an AppGate client and you have started a service go and open the hosts file to see if you see anything that looks similar to:
127.0.0.2 server1 #Added by AppGate Client
You will also be able to ping the server name and get responses back from the correct 127.0.0.x address. The web proxy component basically does the same job as described above except the traffic is being captured by a proxy built into the AppGate server and filtered etc.
The other way the AppGate works is with an IP Tunneling driver installed on the client machine, this is where the AppGate server can give the client machine an IP address. This can be either part of the internal subnet or a different subnet which routing has been configured on the internal network to bounce the traffic for that subnet to the internal interface of the AppGate.
With IP Tunneling local ports are not used as packets are sent straight through the tunnel. This is done by the AppGate client entering routes on the local pc, however if one of the AppGate application firewall components is used (like web access, rdp access etc) then 127.0.0.x addresses are still used as that traffic needs to be sent to the AppGate's proxy.
A few things to check when troubleshooting connection problems are that name resolution is configured on the AppGate server for the server you want to connect too. That the web access component has a server name, the start url can be just / (if there is a index page configured on the web server). Make sure the AppGate client can modify the hosts file (Some Anti-Spyware or AV software stops this) and that it is creating the correct listener on 127.0.0.x (netstat -an and in the AppGate client preferences tick access details tab and check the 127.0.0.x address matches). Also check in the AppGate server's log to see if there are any errors, you could also enable the debug window in the AppGate client again under preferences, set the level to 10 and click open debug window to see if anything is going wrong with the client.