HA deployment of IAG, using CLB

I spent the last couple of days in Wakefield, helping out a reseller with a high available deployment of Celestix WSA appliances using Celestix Load Balancers. Thanks for the company David!! :)

We started by configuring the Celestix Load Balancer (also known as CLB), after configuring the solution we were informed that the internet lines would be a number of weeks away, and we would not know whether the IPs that would be provided would be either external internet facing IP addresses, or NAT'd internal addresses. Why would this be an issue?

Well the customer wanted four IAG portals to be created, and as each portal would have to be created on both appliances. With the CLB in front of the IAG appliances, the way the IP addresses are presented will impact on how to deploy the solution.

If the addresses are external facing, we would need 12 external IP address, three for each portal (one on each appliance, and one for the virtual IP). If the addresses are NAT'd, then there would only be a need for one external address as the virtual IP on each portal.

We only configured one IAG appliance, and then backed up and restored the configuration on the second IAG appliance. Obviously the IP addressing needs to be changed, and the certificate information to be modified, but that was pretty much it.

We were deploying OWA, Sharepoint, Citrix, Mapped Drives, File Access, RDP and an IIS based intranet site.

From an authentication perspective, we looked at AD, AD & HOTPin, AD & Vasco Middleware (RADIUS) and just HOTPin. As expected the authentication methods were straight forward and I got a chance to use HOTPin a bit more. We configured HOTPin on the primary box, and had the secondary box referencing the primary box. You only have to allow port 10000 access between the appliances, and using local administration credentials is fine. The only pain was HOTPin not scanning AD correctly in subtrees, which means each OU would need to be defined when importing users, but I'll let Celestix know about that.

We also encoutered the Java issue, so that was resolved using the fix from one of my previous blog posts.

We can only complete the deployment, once we know how the IPs will be presented.... which will also impact the way we can balance the load (do we use DSR or not, VRRP, Loopback adapter configuration, etc, etc).... Let's see!

Straight forward POC....?

A trip to Brimingham was on the cards today, but I'm going in blind!

I didn't manage to speak to the end user before this proof of concept, but I was pretty confident that I could deal with most situations.

Luckily we were deploying OWA, Citrix, Sharepoint and RDP sessions.

It all went swimmingly and the only difference was that we were using an external IP address directly on the appliance, instead of using a DMZ. This was fine until....

We tried to deploy an additional trunk for third parties/contractors, and this was where using two external IP addresses on the NIC (one as an aliase) we came unstuck.

The box would only hold one external IP address, and would not release it correctly to allow access for the other trunk.

Previously when I have deployed a similar solution, we were using DMZ addresses, so that seemed like the logical solution.

Once the firewall was configured correctly within the DMZ with the correct NAT rules, it worked perfectly!

Multiple URLs with IAG

Thanks to my hosting provider Titan Internet , I have a very comprehensive statistics package which shows the top search phrases that leads people to this blog.

One of the phrases recently was:"IAG allow several URL"

In short yes, IAG will allow multiple URLs, where each URL will access a different trunks.

So you will be able to host a number of URLs and trunks, all with a different look and feel, as well as different authentication methods. There are some limitations, such as File Access can only be configured once, and not to different shares for different trunks.

So you could have the following:

Company wide remote access

URL: https://iag.mycompany.com

Authentication: AD & HOTPin

Endpoint Protection: Machine must be running AV software

Applications: OWA, SharePoint, CRM, File Access & Terminal Server

Technical Support remote access

URL: https://tech.mycompany.com

Authentication: AD & VASCO

Endpoint Protection: Machine must be a member of the domain

Applications: OWA, SharePoint, CRM, File Access, Terminal Server & RDP access to servers

Auditor Access

URL: https://audit.mycompany.com

Authentication: Local Users & RADIUS

Endpoint Protection: Machine must be running AV software

Applications: Accounting database (authorisation by user account)

Partner Access

URL: https://partner.mycompany.com

Authentication: Novell

Endpoint Protection: None

Applications: Intranet Access (authorisation by user account)

The granularity is there for a number of different portals, and each one can have a different look and feel, with a different URL.

Have fun trying this!!!