ACE SSL session handling

[jonagyula]

Hi al,

   we are facing with some difficulty. ACE configured for simple SSL offload, L4.pmap dst port mapping (VIP: 1.1.1.1:9015 rserver 2.2.2.2:8011)

  The client establishes the SSL successfully, but the next should be, that the server starts the conversation after the conn. establishment. The issue is, that after the SSL handshake, with the lack of further data from the client side, the ACE does not creates the server backend (clear) TCP session.

   Without SSL this works flawlessly, coz ACE does not act as TCP endpoint, just forwards (NAT/PAT), and the server starts the conversation.

Could the ACE forced to open the backend TCP to the rserver, without any triggering input from the client side?

This shoud be sw update, binary transfer, no further details of the tcp content.

TIA

Regards:

jonagy

[Kanwaljeet Singh]

Hi Jonagy,

So you mean to say that unless client sends some GET request or initiate any traffic after SSL handshake, ACE doesn't open any connection at the back end? Do you have any pcaps to support this behavior? I don't understand why server should start communication. It's always the client which should request something and server shall reply with the content. Do you have something different here?

Regards,

Kanwal

[jonagyula]

Hi

  I know, weird that server starts the conversation, but unfortunately I have no influence on the client or the server.

   i had some pcap, and also tried to decrypt with the relevant server (ACE) key/cert, but we could not derive useful detail, just the silence...

   Maybe the 'show conn' of the ace shows the best of the issue. Since this is in a test context, there are no excessive communication in it, it is rahter simply to follow the conns, which shows what I mentioned above. ACE terminates the SSL successfully, and nothing happens, just later the timeout from the client.

In the 'show conn' output clearly appears the client-ACE SSL (verified by src/dst IP and port) . The only outgoing ACE-rserver connection, is sourced from the ACE interface address (going to the specified IP/port on the rserver) is probably the relevant health probe. The client's conn should be sNATted, since this is an 'one armed' mode, but no conns apperars with the source IP address from the relevant pool.

jonagy

[Kanwaljeet Singh]

Hi Jonagy,

Do you have Layer 7 parameters for this? ACE needs to see GET request or whatever you have told the ACE to look up at L7, for it to take a LB decision and open a backend connection. ACE should see the client request before it can open the backend connection.

Now i am not sure what would ACE do if there is no L7 involved here. But one thing is sure that ACE keeps the connection proxied during SSL. I would check more regarding this and get back to you.

Regards,

Kanwal

[jonagyula]

no, just this:

policy-map type loadbalance generic first-match pmap-backend-hubpx-pos-apxd
  class class-default
    serverfarm SF-hubpx-pos-apxd
 

policy-map multi-match pmap-frondend-hubpx-pos-apxd-SSL
  class POS-VIP-hubpx-pos-apxd-SSL
    loadbalance vip inservice
    loadbalance policy pmap-backend-hubpx-pos-apxd
    loadbalance vip icmp-reply
    ssl-proxy server ECS-SSL
    nat dynamic 5 vlan 264

and of course, nat-pool 5 under int vl 264.

Ok! thanks for your views, I just wanted to be confirmed, wether is  that normal behaviour if the ACE in the absence of GET (or any other starting message, since it it's not http) from the client, implies that the ACE does not starts the backend, rserver TCP connection?!

thanks

gyula