08-09-2010 05:48 AM
Hello there,
I'd like to know how the ACE modules handles the traffic re-encrypted and sent to the servers in a SSL end to end scenario.
What I mean is:
the ACE terminates SSL requests for the clients and then encrypts the traffic to load balanced servers.. how is this handled?
Do the ACE initiates a one-to- one client-server encrypted connection or could it establish and
maintain a sort of ssl tunnels to the servers? (keeping the sessions low in number)
I did some research but no precise info could be found.
Any information would be apreciated.
Thanks
Solved! Go to Solution.
08-10-2010 09:31 AM
Hello Silk-
The "TCP Server Reuse" feature is what you are describing. It is documented here:
One thing to understand - TCP reuse does not allow more than one client to use a connection in the same moment of time. A single client makes a connection on the front end, a connection is made on the as well. After the client sends a FIN or RST, ACE closes the connection on the front end and leaves the connection open on the . It builds a pool of connections that it keeps open with TCP-Keepalives.
When a new client connection comes in, ACE tries to match the connection to one in the pool. If there is a match, ACE completes the handshake on the front end and maps it to the back end connection (the GET or whatever the request is would be send over the back end connection immediately after the 3 way handshake.)
If the connection did not match, ACE would open a new connection on the back end. The match is based on parameters in the SYN packet like TCP options, MSS, etc.
As this pertains to SSL, ACE would keep the back end SSL connection open (just a bit further than the 3 way handshake as referenced above of course.)
Regards,
Chris Higgins
08-09-2010 04:13 PM
Hello Silk,
End to End SSL is one to one.
Here is an example of how you set it up:
parameter-map type ssl PARAMMAP_SSL
version TLS1
rehandshake enabled
rserver host Server1
ip address 172.16.35.1
inservice
rserver host Server2
ip address 172.16.35.2
inservice
server host Server3
ip address 172.16.35.3
inservice
serverfarm host SSLFARM
rserver Server1 443
inservice
rserver Server2 443
inservice
rserver Server3 443
inservice
ssl-proxy service SSLTerm
key key
cert certificate
ssl-proxy service SSLInit
ssl advanced-options PARAMMAP_SSL
class-map match-all SSLVIP
2 match source-address 172.16.36.50 255.255.255.255 tcp eq https
policy-map type loadbalance first-match SSLPolicy
class class-default
serverfarm SSLFARM
ssl-proxy client SSLInit
policy-map multi-match ALL
class SSLVIP
loadbalance vip inservice
loadbalance policy SSLPolicy
loadbalance vip icmp-reply
ssl-proxy server SSLTerm
Regards,
Chris Higgins
08-09-2010 10:24 PM
> End to End SSL is one to one.
...so I get no real server offloading with this scenario? Can't the ACE de/multiplex sessions?
(I don't really need configurations, just tech capability news)
EDIT: I think what I need is the TCP Reuse feature, could it reuse SSL connections
initiated from the ACE to the servers (in the ssl end to end environment)?
Thanks
08-10-2010 09:31 AM
Hello Silk-
The "TCP Server Reuse" feature is what you are describing. It is documented here:
One thing to understand - TCP reuse does not allow more than one client to use a connection in the same moment of time. A single client makes a connection on the front end, a connection is made on the as well. After the client sends a FIN or RST, ACE closes the connection on the front end and leaves the connection open on the . It builds a pool of connections that it keeps open with TCP-Keepalives.
When a new client connection comes in, ACE tries to match the connection to one in the pool. If there is a match, ACE completes the handshake on the front end and maps it to the back end connection (the GET or whatever the request is would be send over the back end connection immediately after the 3 way handshake.)
If the connection did not match, ACE would open a new connection on the back end. The match is based on parameters in the SYN packet like TCP options, MSS, etc.
As this pertains to SSL, ACE would keep the back end SSL connection open (just a bit further than the 3 way handshake as referenced above of course.)
Regards,
Chris Higgins
08-10-2010 11:03 AM
Ok, thank you very much for the insights
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: