Restrict access to a VIP(?)

[martinlynch]

Here is a summary of my configuration:

I have a rule (VIP2 in the diagram) on a CSS11501 (with SSL H/W) that loadbalances the user/browser connections (shown in RED) via an Apache reverse proxy server pair, across servers S1 & S2. These user/browser connections get authenticated.

The challenge:

Another type of connection now wants to target these same servers S1 and S2 but this is a connection from a server (shown in GREEN) that cannot be authenticated. We also want to loadbalance this connection so we want it to target a VIP on the CSS. In order for servers S1 and S2 to differentiate between the user/browser based connections and this new Server based connection, we want it to target a different VIP and associate a different Source NAT address with it. That way, the S1 & S2 servers know which is the server connection and do not apply the authentication they apply for the user/browser based connections.

The problem: The issue is that the S3 server's SNAT address (assigned by the CSS) is being used by the application to identify the S3 connection and the danger is that anything can target this new VIP, get Source NAT'd to the same ip address and masquerade as S3 which is a big problem as there is no authentication on this connection.

Question 1: is there any way to dictate the Source NAT address that is used, based on the source address of the client?

Question 2: is there any other way to restrict access to this new VIP, without using ACLs? If ACLs seems like the only option here, are there any gothas here. I remember enabling ACLs on a CSS many years ago and it was not straight forward so the idea of using ACLs makes me anxious. Is there a significant performance hit on the CSS?

Question 3: could I avoid ACLs by considering another mechanism such as:

authenticating the server S3 at the CSS by enabling client authentication on the CSS, forcing server S3 to present a certificate (assuming that is possible at S3), decrypting its traffic and then loadbalancing it to S1 & S2. If this seems viable, what type of certificate would I need? Could I avoid obtaining one via a CA?

Sorry about the long-winded explanation and thanks in advance for any help or advice offered.

Regards,

MArtin.

[Christopher Miles]

Hi Martin,

Question1: You can specify any VIP in a source group ( even a specific IP for just this client ).. the problem I see with doing this is that you would have allowed the first syn packet through before you decided to drop it on the return .. If I have understood you correctly, I would think this might work, but doesn't sound the most secure way..

Question 2:  You are correct in saying the CSS behaves differently. The CSS will apply a "deny all" rule to all circuit vlans when the "acl enable" command is entered. You therefore need to make sure that all traffic you wish to pass to and through the box is permitted ..

see url ( this is old but the same thinking still applies ) http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a008009451d.shtml

Question 3: Yes you could enable ACLs and restrict access to this particular VIP and as you have pointed out you could enable the client authentication if this is a SSL connection. This would mean the client would need to produce a client certificate that the CSS would validate. No certificate and the CSS will not allow the connection.  You can use a self signed certificate on the CSS ( I think these are only valid for 30 days...  )

see url

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.10/configuration/ssl/guide/terminat.html#wp999318

cheers,

Chris