Ronan OBrien

Good question! While there may be a way to find this out from the Citrix logs - looking at this through the lens of NetScaler only - I would use HDX Insights on ADM which will provide me with a minimum of the IP address of the connection. This can be viewed in real time with the connection open. More info here: https://docs.netscaler.com/en-us/citrix-application-delivery-management-service/analytics/hdx-insight Best Regards, Ronan.

We recommend that you use NetScaler ADM side by side with your NetScaler - and it will help you from an operational and support perspective. Authentication issues can be reviewed in the Gateway Insight and/Or HDX Insight dashboard. https://docs.netscaler.com/en-us/citrix-application-delivery-management-service/analytics/gateway-insight

Hi Gersson, there may have been a typo there somewhere. You can find all models we offer ( physical and virtual) here: https://www.netscaler.com/content/dam/netscaler/documents/data-sheet/netscaler-software-form-factors-data-sheet.pdf https://www.netscaler.com/content/dam/netscaler/documents/data-sheet/netscaler-hardware-form-factors-data-sheet.pdf We would be more than happy to work with your partner to ensure you select the correct model for your business. Best Regards, Ronan.

Hi Mike, There is a session variable which the NetScaler uses to tie an inbound request to a successful authentication. In a HA scenario, this session information is shared with the HA partner so that in the event of a HA Failover where the secondary appliance becomes primary, the users requests will still be recognised as being authenticated. If this were not the case then after a HA failover, every single user would be forced to re-authenticate. Here are the answers to your specific questions: There are several types of cookie used in day to day operations.. e.g. persistence cookies, GSLB Persistence cookies, Authentication cookies, WAF cookies... The vulnerability you are referring to relate to the authentication session information. Q. Under what HA conditions are the cookies shared? A. Cookies are shared in HA and Cluster scenarios to make a failover event seamless for those accessing apps behind NetScalers. Q. Are they shared under a normal HA scenario? A. Yes, this is default behaviour, and part of what makes a pair of NetScaler more resilient. Q. And in a HA scenario where they are shared, where do you need to clear them? On all nodes? Just the primary? The secondary? A. Just the primary. The command will propagate to the secondary. Hope this helps, Kind Regards, Ronan.

Have you tried this KB article? https://support.citrix.com/article/CTX215481/error-failure-tcp-connection-successful-but-application-timed-out-on-netscaler Since NetScaler is a full secure reverse proxy, there are two conversations happening here. Client --> CS or LB VIP NetScaler --> Application Server. We are troubleshooting stage 2 - so it has nothing to do with the LB VIP or CS VIP Can you try changing the monitor to a basic TCP monitor? What is the result. Is there a service running on port 80 on the application server, and is this port open on the internal FW? If so, try creating a service which is port 80, HTTP and see if a HTTP Monitor works. If you can copy and paste the service configuration here that will also help us. Reasons for this sometimes is client cert auth turned on the service at the back end, where it is waiting for a certificate from NS, or some other SSL related issue, but first, the steps about should take the FW out of the equation. Ronan.

If there are different zones, with different servers in each zone, then perhaps this is a case for INC mode? In this way, you manually add a snip on EACH appliance. The SNIP doesnt float, and in each zone, you can set the default network gateway of the servers to the appropriate SNIP for that zone. Also - we try to avoid using USIP where we can, as you lose some protection and get no multiplexing benefits. I always ask *why* USIP is required, and often the need can be met with a header insertion or some rewrite actions...

en fe reputation add responder policy drop-all-malicious client.IP.SRC.IPREP_IS_MALICIOUS bind responder global drop-all-malicious 100 END -type REQ_DEFAULT The implications of this is that Each and every request that comes into the appliance that is HTTP will be evaluated. The sourceIP will be looked up in the IP rep list, and if it's there, the request will be silently dropped. It might be more appropriate to bind this to all internet facing VServers instead of a global binding. It's also nice to turn on logging. This would mean allowing customisable log messages, creating a specific log message for this protection, and then invoking it from the responder policy above. https://support.citrix.com/article/CTX200908/how-to-create-message-action-to-log-to-syslog-on-netscaler But the 3 lines above on their own will be sufficient to evaluate al inbound requests.

How to enable IP reputation in as few lines as possible, and the implications?