TechAgility

I’ve been keeping a track on this forum entry at Brian Maddens Site for some time as I have seen similar issues elsewhere.
http://www.brianmadden.com/forum/tm.aspx?m=50628&mpage=2

It makes very interesting reading, and thanks to mkools for all the very useful info ;-)) It still makes an interesting insight on the device?
I’m just wondering out loud how long it might take before someone has Netscaler running in vmware?

+++++++++++ Quote ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I managed to mount the CAG filesystem, they use lilo to boot the machine, check the lilo.conf, it has a line that says:
password="R35tr1tct3d*" (It’s even spelled the wrong way with an extra ‘t’)
Maybe that’s the same as the bios password, they didn’t even encrypt the filesystem so it might be worth to try
Anyway, there’s another line that says:
append="devfs=mount"
You can easily add acpi=off to this section and acpi will be disabled, so you get:
append="devfs=mount acpi=off"
I enabled SSH daemon on port 22 and did a reset on the root password (which was succesfull) and rebooted the CAG.
After that I could SSH into the appliance and logon. So when the CAG eats your memory again you can logon through SSH and check (using ‘top’) the process that is eating up your memory, it might get you somewhere.
Here are some screenies:

Here’s top which you can use to see which process is eating up your memory:

If you want to try some things let me know if I can be of any help.
I could write short instruction in order to get you in the box through SSH.

And how to get root access?

Ok here are the steps to get root xces to the CAG.
Please notice that I only tested this succesfull on a vmware image of version 4.2.0, but it should work for the appliance as well.
First step is to download a linux livecd, I used Ubuntu 6.06.1 LTS 32-bit intel version (check www.ubuntu.com).
Boot the appliance from that CD, when you see the ubuntu boot menu select the safe vga mode option, the livecd will now boot.
When it has booted, open a terminal (Accessoires > Terminal).
Enter: sudo passwd root
Type a new password for the Ubuntu rootuser.
Next, type: su , and enter the password just specified.
This step is optional and is done so that you don’t have to sudo all the time.
Ok, you are now root, create a directory in the root: mkdir /cag
After that, mount the cag partition to that directory, in the vm I had IDE disks, so I had to do: mount /dev/hda1 /cag, but the appliance is using sata disks so you might have to do: mount /dev/sda1 /cag
After that, when you do a cd /cag and ‘ls’ you should see the appliance data.
Next you need to chroot into the CAG environment to make the changes, type:
chroot /cag
Your prompt will now change in something like bash-2.05$.
Next run ’setup’, change the firewall settings from high to disabled.
Next, go to system services, deselect ‘iptables’, make sure sshd and xinetd are selected, and press quit to save changes.
Next, change the rootuser password.
type: passwd
Re-enter the password twice.
Next step is to run SSHD to generate the keys.
type: /etc/init.d/sshd start
I didn’t get any output, but when you do ls /etc/ssh you should see the keyfiles.
type ‘exit’ to leave the chrooted environment, next type: umount /cag
Reboot the appliance, download putty (search google for putty) and logon to the appliance, port 22, username root with the password you’ve just changed and you should get access.
Next you can change some lilo settings, e.g. disable acpi, you have to edit /etc/lilo.conf (as described above, add it to the append section of the kernel). You have to use vi to edit the file, if you don’t know vi you should read the manual, it can be a pain if you’ve never worked with it (man vi).
When you’re done editing, save the file and run: /sbin/lilo to update lilo and reboot the system (type reboot).
I guess that’s about it, all these steps are in my head so I might have forgotten something, let me know when you can’t get in and I will see if i can help you out.
One important thing:
When you change the duplex settings of the CAG, another lilo.conf is copied over the original one, so you will lose your settings made at that time! If you want to disable ACPI with all duplex modes, all lilo configurations are in the folder: /config and you have to edit them all.
Good luck!

Thanks again to mkools

written by dcaddick

(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

written by dcaddick

I’m just going through a proof of concept at a client’s site for an AG+AAC Implementation and I was looking at bringing the AG up to 4.2.2 as I heard there were a few critical patches, and interestingly enough the link to 4.2.2 from CTX108902 ends up pointing at a 4.2.3 Download??

BTW - Don’t forget to remove your existing Admin Tool and then download and install from fresh after upgrading the CAG!
(But you knew that didn’t you? 

The 4.2.2 lists these Known Issues and Issues Fixed:

Known Issue(s) in this Release

• User names that are configured on the Access Gateway are case-sensitive.

• If a user is not logged on as an administrator on a computer running Windows 2000 Professional, the Secure Access Client must be installed locally on the client computer and then started using the Web address of https://FQDN/citrixsaclient.exe, where FQDN is the address of the Access Gateway. The ActiveX applet does not have the rights to download the file to the normal file location. This does not happen on computers that are running Windows Server 2003 or Windows XP.

• If a user who is not logged on as an administrator connects using the Secure Access Client, applications such as Microsoft Outlook might occasionally lose the network connection.

• Dialup users do not receive WINS server assignments. To fix the problem, manually set the internal WINS address or use a Microsoft DNS server to set the domain to perform WINS lookups.(bz947)

Issue(s) Resolved in this Hotfix

1. The Access Gateway could experience a condition that causes the appliance to appear to be in a hung state when multiple servers running the Secure Ticket Authority (STA) are configured. (BUG23100)

Symptoms of this issue include:

• CPU utilization reaching near 100%

• Errors in the STA server log(s).

Applying this fix remedies the problem by ensuring that STA ticket renewal requests are sent to the session’s original STA.

2. A rare condition could occur where a file or a record would be improperly encoded causing the appliance to suspend processing. (BUG23099)
Symptoms of this issue include the following:

• New connections are not accepted

• User sessions are suspend

• Error messages that say destroy_session notification received

3. The Access Gateway experiences interoperability problems with some RADIUS servers because it sends the NAS-IP-ADDRESS as 0.0.0.0. The Access Gateway now sends the IP address configured for Interface 0 on the General Networking tab to the RADIUS server. (bz2212)

4. If more than 20 host names are configured in the preauthentication policy, the net6helper Active-X control fails, causing Internet Explorer to close. The content in the policy is checked to make sure there is enough space before filling the buffer. (bz2251)

5. If a file rule for end point resources is created and if the check boxes Require SSL Client Certificates and Enable Portal Page Authentication are selected on the Global Policies tab, the net6help Active-X control fails, causing Internet Explorer to close. (bz2322)

6. The DNS suffix size was limited to 127 characters. The suffix list size is now doubled to 254 characters. (bz2324)

7. The Secure Access Client displays an error message that some intermediate certificates are invalid. The server’s certificate chain could not reliably revalidate the intermediate certificates because it cannot be retrieved for the SSL session object. In this release, the certificate is not revalidated when the server’s certificate chain is using an OpenSSL session. (bz2435)

8. When an authorization request is made using LDAP, and the LDAP environment performs LDAP referrals, the SSL daemon on the Access Gateway resets. End users are disconnected from the Access Gateway and the SSL daemon is reset. (bz2517)

9. IP pooling does not allocate the number of IP addresses correctly. For example, if there are two IP pools, the first with a range of 192.168.2.1 through 192.168.2.5, the second IP pool cannot start with 192.168.2.6. The second IP pool has to start at 192.168.2.7. With this release, this is fixed. (bz2521)

10. The Access Gateway automatic update process removes the Advanced Access Control logon point, causing the Advanced Access Control to stop functioning. With this release, the Access Gateway resets the desktop Web address when the client upgrades. (bz2560)

11. When an HTTP host header is missing, it causes the server process to experience a fatal error if this is the first request made to the Access Gateway as part of a new Advanced Access Control session. Host headers are required for HTTP 1.1 requests (see RFC 2616) and the connection is responded to with an HTTP 400 request.
Host headers are not required for HTTP 1.0 connections. Connections of this type are handled correctly, which can include Web browsers connecting through a proxy server. (bz2599)

12. Internet Explorer stops functioning when logging onto the Access Gateway using Advanced Access Control. The LogonPoint page is returned to the user when an error occurs. (bz2684)

The 4.2.3 lists these Known Issues and Issues Fixed:

Known Issue(s) in this Release

· When a user session is terminated, the session log fills ups (TT23539)

· Domain logon scripts are slow to launch (TT23509)

· The Access Gateway fails after manually synchronizing with a Network Time Protocol server (TT23690)

· Secure Access Client transmitts UDP packets to the Access Gateway during the VPN connection (TT23723)

Issue(s) Resolved in this Hotfix

written by dcaddick