cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1615
Views
0
Helpful
9
Replies

Problem in SSL SSO sessions

taufeeqrauf
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

9 Replies 9

asharmav
Level 1
Level 1

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

Marko Leopold
Level 1
Level 1

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

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 

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?

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

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.

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

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?

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