we are facing with some difficulty. ACE configured for simple SSL offload, L4.pmap dst port mapping (VIP: 126.96.36.199:9015 rserver 188.8.131.52: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.
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?
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.
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.
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?!
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...
Cisco Documents are usually accurate, but when it came to the document
on Cisco APIC Signature-Based Transactions it was slightly off the mark.
This document is for those novices to API like me who cant seem to
figure out how to go about performing signat...