(Caveat - this is based on CAG Version 4.2.3!!)
For some reason I would appear to have an Access Gateway that exists in a Customers DMZ and is configured to be attached to a Public IP Address of https://xxx.xxx.xxx.xxx
So it would be reasonable to assume that you could at least connect to the gateway and "see" at least the login page? or something at least?
Well for some reason I’m beginning to think that this unit is not displaying the web pages successfully.
If you try using telnet xxx.xxx.xxx.xxx 443 it will connect fine, but as soon as you try and call https://xxx.xxx.xxx.xxx with or without a :443 on the trailing end you get a big fat zip…. this always seems to end up with an Internal Server Error 500
Now I have been chatting to Gary (one of my Colleagues, just to check that I’m on the right planet 
and I KNOW that the AG needs to be able to Talk to the AAC across port 80, because in the Admin Tool where the option is to join the AG to the AAC farm you have a choice of either Secure or Unsecure (if you check the box the AG will check the AAC Server for a certificate and then connect over port 443, or alternatively if you leave the box unchecked then it will connect over port 80) this is also confirmed by the fact that once the AAC is successfully entered here it will display as xxx.xxx.xxx.xxx:80.
Curiously enough I have also found that when adding the AG to the AAC Farm it was typically not showing up in the AAC Console as per this CTX109197
Symptoms
Running discovery from an Advanced Access Control server does not find the Access Gateway appliance configured to work with the Advanced Access Control server.
I have also been trying to fathom out where it’s going wrong (or not??) in communications established from the AAC end of the chain. From the AAC I can initiate
telnet 10.x.xx.xx 443
telnet 10.x.xx.xx 9001
telnet 10.x.xx.xx 9005
But, telnet 10.x.xx.xx 80 keeps failing all the time
Now I’m looking at this pretty closely and it seems to me that when you use the "Server Administration Tool" to DEPLOY the Logon Points to the AG that this would need to be done across port 80? I can’t see it actually needing to be done as an admin function across 9001 or 9005? Besides we’ve already told it in the earlier paragraph above to establish comms across 80? So again this would appear to be the root of my issues that I cannot establish successful comms across port 80 from the AAC to the AG?
What I also find interesting about this is that by using the Admin Tool on the CAG (again,in the above paragraph..) and establishing that the CAG is joined to an AAC this appears to be successful? So perhaps it’s just an assumption that this succeeds?
Another issue that appears to be happening is that after the CAG has been running for a few hours(??) it looks like I am then unable to connect to the Web Admin Portal at https://10.x.xx.xx:9001 and this also appears to fail with an Internal Server Error 500 - however after going around to give the CAG a cold reboot it will now bust in to life - even while in this state it will still respond to pings and telnets as described above…..
I am now in the process of taking the AAC (It’s a VMware on ESX) and converting it to run under a VMware Workstation on a laptop. Then I will connect it via cable direct to the back of the Internal CAG Port and test from there. At least by doing this I can totally eliminate the communications path as a possible cause?
Ongoing Steps:
I’m going to try a number of ways to isolate what the issue is..
Run a copy of the AAC Server from VMware on a Laptop directly attached to the AG
Possibly run the AG up from a BartPE to verify connections
Reimage the AG with 4.2 and remove the 4.2.3?
In the meantime I would really appreciate confirmation as to whether or not AG -> AAC or AAC -> AG communications requires port 80?
It’s my belief that it does and this won’t work without it?
I take it no-one else has had issues with 4.2.3?
Solution:
Communications path between the AG and AAC was causing the fault. Outbound AAC -> AG was 5 hops using tracert, AG -> AAC was 3 hops (You’ll have to talk nicely to Security or Networks to get this clarified?)
Firewalls are:
Checkpoint on Nokia IPSO
Attached is a *.JPG that illustrates the relevant "Trace Routes", essentially what was happening was that the path TO the AG from the AAC was via 5 hops, however on the return the Router/Default Gateway that the Internal Interface of the AG was connected to knew of a shortcut that was only 3 hops AND as far as I am aware it was returning via a path where the Firewall Interface in question had no prior knowledge of the outbound SYN, so as far as it was concerned it was effectively illegal traffic, so it simply dropped it - does that make sense? This would appear to work somehow at a lower level for Ping, TELNET, etc. and even at an Application Level BUT only shortly after a cold reboot, after some indeterminate time it would fail at the Application Level and requests for HTTP/HTTPS traffic would get the Internal Server Error 500.
Once the Router/Default Gateway that the AAC is pointing to was updated with the correct information to be able to reach the AG in only 3 hops (the same as it’s apparent return path?) everything has burst in to life.
Once the paths are symmetrical ALL Issues are resolved
This also includes the adding of the AG to the AAC Farm, this now works without having to resort to Manually add the address of the Access Gateway by browsing to the GatewayConfigService.asmx as per CTX109197
The error on the Firewall was:
"TCP packet out of state" First packet isn’t SYN tcp_flags SYN-ACK
Loading ...