Jump to content

Netscaler AAA behind proxy with TCP/SSL connection multiplexing


Recommended Posts

I have a setup requiring deployment of a reverse-proxy server in front of a Netscaler AAA protected website (ldap authentication). The reverse-proxy server is multiplexing established TCP connections to Netscaler and reusing SSL sessions for multiple clients.

 

The setup is working, but I'm not sure of the validity of the design from a netscaler perspective. Does Netscaler AAATM support multiple client connexions multiplexed in a single TCP / SSL session ? How can I use the X-Forwarded-For IP address forwarded by the reverse-proxy server as the client IP address instead of the proxy server address ? (logs generated AAATM report all authenticated clients with the proxy client IP).

Link to comment
Share on other sites

Hi!

 

TCP connections muliplexing is supported for  some type of services, and not all that is TCP.

Usually it is used to multiplex http connections.

 

you can find more info  here:

https://www.citrix.com/blogs/2012/03/08/connection-multiplexing-in-netscaler/

 

If the reverse proxy inserts X-Forwarded-For , then if you do not rewrite the http headers you should be able to see it on the server side.

Be sure Netscaler does not insert another X-Forwarded-For. If you do , you might have 2 http headers  X-Forwarded-Forand  you will see the proxy ip address and not the real client ip .

 

 

Thanks!

Link to comment
Share on other sites

Hi Mihai,

 

Connection multiplexing is working like a charm between Netscaler and backend servers and X-Forwarded-For header is forwarded to the backend servers.

 

The question is how does netscaler, and more specifically netscaler AAATM, behave when a proxy located in front of netscaler (ie : between client and netscaler VIP) multiplexes multiple client connections in the same TCP connection (ex : connection reuse capabily of Apache proxy).

 

Is netscaler able to identify that the HTTP requests are from two different clients (because they have different netscaler cookies or one of the client doen't have netscaler cookie yet for example) or does netscaler rely on TCP connection data to differenciate clients.

 

How can netscaler AAATM match an authenticated session with the real client IP available in the X-Forwarded-For header ? I can't find whre to tell AAATM to use this header to extract client IP ?

 

 

 

 

 

 

Link to comment
Share on other sites

Hi Sebastien,

 

you will have the answer in this post you have made. and it's not "working" because in rarely case netscaler use the information about another user instead of the right user.

 

https://discussions.citrix.com/topic/401939-netscaler-aaa-disable-ntlm-failback-for-negotiate-authentication-and-replace-it-with-ldap/

 

I' am available if you want to talk about it.

 

Regards,

Link to comment
Share on other sites

Hi Mathieu !

 

Thanks for the answer !! I had the same "in some case the session of user are sharing and a user have the information about the other user"  feeling during my tests but can't find any log of this session mismatch behavior. My only finding is that Netscaler seems to issue a TCP FIN packet when the connection is reused for another client.

 

I know that netscaler has been designed as a head of line device, but it cannot be excluded to have it accessed behind a proxy (security use cases) or reverse-proxy (CDN, ...). A simple Apache server would have better session handling than enterprise/platinium netscaler in this TCP multiplexing scenario if the "in some case the session of user are sharing and a user have the information about the other user" behavior is confirmed. It would also be a strong security issue.

 

Would you have some logs or traces files to share about this session handling issue on Netscaler ?

 

Could anyone from Citrix support or engineering confirm if there is a security issue when multiplexing TCP sessions for multiple clients in front of Netscaler ?

 

Regards,

 

Link to comment
Share on other sites

Hello,

 

I have the issue but to get log it was very difficult.

First I have found log because we use Citrix AAA as IdP and Wsfed federation. so I see on the log that the WsFed Request "xxxxxxxx" for account user@domain.com have the response with user2@domain.com

 

I have to made a wireshark trace also. And we found in the flow of the wsfed request that the tcp stream have more than one request.

 

the issue don't append many time. it's append ~ 0.05%.

 

When we set the maxreq to 1 on the lb service the issue don't append anymore and the performe stay the same. We have just to follow the free available port for SNIP/MIP and free availalble connexion for lb service

 

Regards,

Link to comment
Share on other sites

6 hours ago, Mathieu BRUSTON1709159739 said:

[....]

First I have found log because we use Citrix AAA as IdP and Wsfed federation. so I see on the log that the WsFed Request "xxxxxxxx" for account user@domain.com have the response with user2@domain.com

 

I have to made a wireshark trace also. And we found in the flow of the wsfed request that the tcp stream have more than one request.

 

the issue don't append many time. it's append ~ 0.05%.

[....]

 

 

Thanks for the maxreq = 1 workaround !!

 

However, this mix between user sessions is a huge security issue, even if it only appends ~ 0.05% !!

 

Could this behavior be linked with the SSLVPN component of the Netscaler AAA process which would "think" that a single user is behind a single TCP / SSL session as it would be in a VPN scenario ?

Link to comment
Share on other sites

I linked an auditing message action to the CS policy directing trafic to the LB vserver protected by Netscaler AAA (forms) to get more logs

 

When tcp multiplexing is enabled in front of netscaler HTTP.REQ.USER.NAME and HTTP.REQ.USER.SESSIONID report user login and netscaler AAA session. Cookie mismatch errors are reported by AAATM process.

 

When tcp multiplexing is disabled (maxreq=1 or disablereuse=on with apache) no values are reported anymore for HTTP.REQ.USER.NAME and HTTP.REQ.USER.SESSIONID. A new SSL session is negotiated for each http request

 

TCP or SSL session seems definitely taken into account for AAA session handling by netscaler. 

 

App access is working and session policy works for authentication on the kerberos protected app server.

 

Netscaler NSC_TMAA & NSC_TMAS SESSION cookies are forwarded by the browser in both scenarios.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...