Forum Discussion
BDunbar_8799
Nimbostratus
NimbostratusBring Order out of Chaos
My LTM network just grewed like Topsy. What I'd like to do is bring some order to it, and reduce costs.
Note: this might not be very advanced as some network designs, but it the most advanced thing I've tried to in LTM. So far.
See topsy-as-is.jpg, in topsy.zip
This is a grossly simplified diagram of the LTM as it currently is.
* All users are inside the organization.
* Servers are a mixture of IIS, Apache, Oracle AS.
* Not all have SSL certificates, but most do, or need to have them.
Problems.
* We use an IP address for each virtual server/pool/application. We don't have a scarcity of IPs, but we'd like to conserve them. Because restacking subnets is a chore and we'd like to avoid that time-sink.
* Each application gets their own SSL certificate. This gets expensive.
* Last, and least, it's awkward to look at a dozen virtual servers, keep their configurations straight, in the GUI.
Where I'd like this to go.
See topsy-to-be.jpg, in topsy.zip
* A single VIP. This looks pretty straightforward.
* A single SSL certificate for all applications. When I talked to Thawte about this they referred me Sales, who tried to up-sell me on what their enterprise portal, and stressed there would be all kinds of Problems using a wildcard Cert. Is there another way to accomplish this?
* A single rule to route the traffic to the appropriate pool. What I'd like is a rule that I can put in place, then leave alone, adding pools behind it for the traffic to go to. Thoughts?
4 Replies
- The_BhattmanHi BDunbar,
I certainly think you can collapse this a bit more. However, I think the key to simplify would be the wildcard cert if so you can use foo.* bar.*, etc. This could collapse the the design into at least 2 virtuals (one for HTTPS and the other HTTP) but using the same IP address. What kind of problems would there be with the wildcard certs in your environment?
Bhattman 
BDunbar_8799"What kind of problems would there be with the wildcard certs in your environment? "
The sales man from Thawte claimed that with a wild card cert users who access
foo.company.com
Will encounter an error loading the certificate telling the end user there is an common name mis-match and throwing up the caution flag, asking if they want to continue.
This might be acceptable in our dev environment, but not in Training or Production.- BDunbar_8799What kind of problems would there be with the wildcard certs in your environment?
I reviewed my notes from the conversation we had. The problem is this ....
Users of a particular application have been told they can refer to the application in the URL as 'blah' where the fully qualified domain is 'blah.company.com'. Many of them open IE type 'blah' and they're at the login page. They like this, as opposed to opening a bookmark, or finding the link on our corporate inranet page.
So the problem is that a wildcard (*.company.com) would not cover 'blah'.
On the other hand, the owner of that application has already said that SSH is important and while it would be nice to preserve the 'blah' functionality, if we can't do it then .. oh well. 
L4L7_53191I'm not sure this will be a problem. If the cert covers *.company.com, blah.company.com should match. If a user simply types in 'blah' in their browser, the client will do a domain suffix search and append company.com (presumably, you can set it up this way if not).
-Matt
