topic Problem in SSL SSO sessions in Application Networking

Problem in SSL SSO sessions

taufeeqrauf — Fri, 17 Jun 2011 05:19:02 GMT

Hi All,

I am new to ACE and for last few weeks trying to configure it for server load balancing with session persistance. Her is the scenario

Client are using their cerificate to login into SSL server. Based on client certificate serial number, email address and values in Subject fields the server decides which options they can access and what particular set of data and images they can view and manipulate. It is going on for last two years. Recently we plan to increase the capacity and have introduce ACE 4710 in between. I have used below configuration

access-list TRAFFIC-IN line 8 extended permit ip any any
access-list TRAFFIC-IN line 16 extended permit icmp any any
access-list TRAFFIC-OUT line 8 extended permit icmp any any
access-list TRAFFIC-OUT line 16 extended permit ip any any

probe https HTTPS_Probe
interval 15
faildetect 2
passdetect interval 60
ssl version all
open 1
probe icmp ICMP_Probe
interval 15
faildetect 2
passdetect interval 15

rserver host ClearWebAWT01
ip address 172.16.4.63
inservice
rserver host ClearWebAWT02
ip address 172.16.4.64
inservice
rserver host ClearWebAWT03
ip address 172.16.4.61
inservice
rserver host ClearWebAWT04
ip address 172.16.4.62
inservice

serverfarm host Clearing-Server-Farm
probe ICMP_Probe
rserver ClearWebAWT01
    inservice
rserver ClearWebAWT02
    inservice
rserver ClearWebAWT03
    inservice
rserver ClearWebAWT04
    inservice

parameter-map type connection HTTPS_Clearing_Connection_Parameter
set timeout inactivity 28800
parameter-map type ssl PARAMETER-MAP-CLEARING
session-cache timeout 1200
queue-delay timeout 1

ssl-proxy service SSL-CLIENT
ssl advanced-options PARAMETER-MAP-CLEARING
ssl-proxy service SSL_SERVER
key Clearing.cer
cert Clearing.cer
ssl advanced-options PARAMETER-MAP-CLEARING

class-map match-all NachWeb
2 match virtual-address 172.16.4.10 any
class-map type management match-any remote_mgmt_allow_policy
201 match protocol snmp any
202 match protocol https any
203 match protocol icmp any
204 match protocol ssh any

policy-map type management first-match remote_mgmt_allow_policy
class remote_mgmt_allow_policy
permit

policy-map type loadbalance first-match NachWeb-l7slb
class class-default
serverfarm Clearing-Server-Farm

policy-map multi-match int4
class NachWeb
    loadbalance vip inservice
    loadbalance policy NachWeb-l7slb
    loadbalance vip icmp-reply active
    connection advanced-options HTTPS_Clearing_Connection_Parameter

service-policy input int4

interface vlan 4
ip address 172.16.4.5 255.255.255.0
access-group input TRAFFIC-IN
access-group output TRAFFIC-OUT
service-policy input remote_mgmt_allow_policy
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.4.1

The problem starts if more than one server are servicing the client request. The session starts to time out and client requires to login again and again.

Any suggestion with working example would help me in guiding to right direction.

TIA,

Taufeeq

Problem in SSL SSO sessions

asharmav — Thu, 14 Jul 2011 20:48:12 GMT

Hi Taufeeq,

If you still need assistance you can open a case with Cisco PDI Help desk. @ www.cisco.com/go/pdihelpdesk

Regards

Abijith Sharma V S

Problem in SSL SSO sessions

Marko Leopold — Fri, 15 Jul 2011 06:47:30 GMT

Hello Taufeeq!

I can't see any stickyness in your configuration. Unless your webservers aren't syncing each other, you need to stick on the same server i guess.

Cheers,

Marko

Problem in SSL SSO sessions

taufeeqrauf — Fri, 15 Jul 2011 08:14:44 GMT

Hi Marko,

Thanks for suggesting stickyness. I have tried stickyness configuration before and its works perfectly for clear traffic (unencrypted) but problem start when I tried to stick encrypted traffic without using SSL termination and initiation. Please refer another example below. The session starts to timeout and sometime client stick to same server and sometime it starts a new session and they have to login again.

access-list ACL line 10 extended permit ip any any
access-list ACL line 20 extended permit icmp any any

probe https HTTPS_Probe
interval 15
faildetect 2
passdetect interval 60
ssl version all
open 1
probe icmp ICMP_Probe
interval 15
faildetect 2
passdetect interval 15
probe tcp TCP:443
port 443
interval 5
passdetect interval 10
connection term forced
open 3

rserver host ClearingServer1
ip address 172.16.2.61
inservice
rserver host ClearingServer2
ip address 172.16.2.62
inservice
rserver host ClearingServer3
ip address 172.16.2.63
inservice
rserver host ClearingServer4
ip address 172.16.2.64
inservice

serverfarm host SSLFARM
probe ICMP_Probe
rserver ClearingServer1
    inservice
rserver ClearingServer2
    inservice
rserver ClearingServer3
    inservice
rserver ClearingServer4
    inservice

parameter-map type ssl Clearing-PM-1
session-cache timeout 1200
queue-delay timeout 1
parameter-map type generic SSLID_PARAMETER_MAP
set max-parse-length 70

sticky layer4-payload SSL-GROUP
serverfarm SSLFARM
response sticky
layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST)"

class-map match-any SSL-C1
2 match virtual-address 172.16.98.100 tcp eq https
3 match virtual-address 172.16.98.100 tcp any
class-map type management match-any remote_mgmt_allow_policy
201 match protocol snmp any
202 match protocol https any
203 match protocol icmp any
204 match protocol ssh any

policy-map type management first-match remote_mgmt_allow_policy
class remote_mgmt_allow_policy
permit

policy-map type loadbalance generic first-match GPPMATCH
class class-default
sticky-serverfarm SSL-GROUP

policy-map multi-match CLIENT-SSL
class SSL-C1
    loadbalance vip inservice
    loadbalance policy GPPMATCH
    appl-parameter generic advanced-options SSLID_PARAMETER_MAP

interface vlan 98
description Upstream VLAN_98 - Clients and VIPs
ip address 172.16.98.10 255.255.255.0
access-group input ACL
access-group output ACL
service-policy input remote_mgmt_allow_policy
service-policy input CLIENT-SSL
no shutdown

ip route 0.0.0.0 0.0.0.0 172.16.98.1

Any suggestion how to use stickyness in encrypted traffic.

TIA,

Taufeeq

Re: Problem in SSL SSO sessions

Marko Leopold — Fri, 15 Jul 2011 08:41:11 GMT

Two more questions. Do you use NAT in your network or do you see the ip-address of the client? And do you use the serverfarm for unencrypted traffic as well?

Problem in SSL SSO sessions

Ahmad Basel Jaber — Fri, 15 Jul 2011 11:19:21 GMT

Hi Taufeeq,

It all depend on your servers' behavior. You need to understand how the clients are actually communicating with the servers with full detail of this communication.

Please explain more this communication, including the URLs the clients will be requesting and the server behavior as a response for these request.

Best regards,

Ahmad

Problem in SSL SSO sessions

taufeeqrauf — Fri, 15 Jul 2011 12:13:38 GMT

Yes I am seeing live IP of clients. Server farm is not using any unencrypted traffic.

End to end encrypted traffic is a requirement.

Client is using certificate to login into server using simple https://my.server.live.ip. This Live IP is mapped on Netscreen Firewall redirecting 443 port to ACE VIP as given in above configuration. The ACE sees 443 request on VIP from certain IP redirect it the next avaiable IP in serverfarm. The ACE also stores SessionID of encrypted traffic in its sticky database. The server request client certificate details and using details in its certificate and checking credentials from authentication database allowed them to login into site. All subsequent communication needs to be with same Web instance. I think that I am not getting same sessionID for subsequent request and ACE is enable to stick the client to same web instance instead it redirect the request to any server IP that is next in line to serve request.

Problem in SSL SSO sessions

Ahmad Basel Jaber — Fri, 15 Jul 2011 13:43:13 GMT

Hi Taufeeq,

Based on your description, the only way to stick the client is using source IP address stickiness. I would recommend to give it a try and see if it fixes your issue.

Note: sniffing the traffic at the client PC using wireshark will show you exactly if the client is using different SessionID.

Note: The SessionID could be changed in SSLv3, so this could be your main issue.

Best regards,

Ahmad

Problem in SSL SSO sessions

taufeeqrauf — Tue, 19 Jul 2011 08:45:35 GMT

Source IP address resolves the problem however, clients coming from proxy stick to same server is their any way through which they can be load balance?

Problem in SSL SSO sessions

Ahmad Basel Jaber — Tue, 19 Jul 2011 09:23:29 GMT

Hi Taufeeq,

You need to start thinking about SSL termination to avoid having huge number of clients (which thet are coming through proxy server) sticking to same server.

I dont think of any other way, unless you need to creat multiple VIPs pointing to multiple servers, and configure your nomal clients to use one VIP and the proxy server to use another one.

Best regards,

Ahmad