[Error modifying SDX instances Please provide valid MAC address for LA]

Just came back across this recently - it isn't fixed in 13.0-58.30!

[DNS content switching / conditional forwarding]

Has anyone come up with a way to selectively forward DNS queries to differing name servers in a way that is usable by ADC itself?

 

I have a customer with a split-brain DNS scenario and want to configure in such a manner that SSL Forward Proxy requests for origin servers on the internet go to public DNS resolvers, whilst ADC has use of internal nameservers for internal lookups e.g. KDC

 

There's no option to configure SSL Proxy vServers to use a distinct forwarders as there used to be when using cache redirection vServers, so you're stuck with whatever is set as a name server for the entire system.

 

I can't select a CS DNS vServer as a nameserver either.

 

The only way forward I can think of is to configure Content Switching for DNS (https://support.citrix.com/article/CTX205898) on a separate ADC instance and configure that IP address as a nameserver on the SSL Forward Proxy instances.

[Error modifying SDX instances Please provide valid MAC address for LA]

I get the same problem with 12.1-53.12

 

This is a real pain.  You can't modify an existing SDX Instance in any way - even just something simple like renaming it or increasing memory.

 

MAC Address Mode is default.

 

Seem to have found a workaround --> in the edit Instance page, try Deleting the LA data interfaces, and then re-adding with the required VLAN tags.  You will need to do this for all of them.

[TCP MSS anomaly on Netscaler 11.1-52.13]

Thankyou Prem.

 

This is very helpful.

 

Are you able to also confirm if it is acceptable to write all 16 values in the range below 1460, providing there is no intention to enable Jumbo Frames support?  This provides extra granularity.

 

Neil

[TCP MSS anomaly on Netscaler 11.1-52.13]

Thankyou Prem

 

Can you advise if Citrix supports customisation of the MSS table as per the link I posted?  I have been experimenting with a much more granular list of MSS values tailored for the network path MTUs and wish to know if this is something Citrix would support in production.

 

Neil

[TCP MSS anomaly on Netscaler 11.1-52.13]

I have done some further testing and identified that this issue appeared in 11.1-52.13 and has persisted in 53.11.  Earlier 11.1 releases and 11.0, 10.x aren't affected.

 

Its easy to reproduce the problem if you set your client side interface MTU to between 1362 and 1369 then observe Wireshark whilst initiating a TCP connection which is likely to result in full-size frames being returned by the Netscaler, such as a HTTPS handshake.

 

When the client sends a TCP SYN with MSS between 1322 and 1329 the Netscaler chooses the MSS value 1330 from its table and then replies with packets which exceed the client MSS, showing as frames of size 1384 in Wireshark.  When reproducing this with Wireshark and a custom interface MTU the "oversized" packets are recieved by Windows, but if its the network path rather than the client interface MTU which lies in this range then the reply packet from the Netscaler is instead dropped by the intermediate router, the Netscaler ignores any resulting ICMP 3,4 packet and the connection times out.

 

Anyone thinking of rolling these later 11.1 versions should pay attention to this issue as it will affect client connections over VPNs where the path MTU lies in the 1320-1330 range.

[TCP MSS anomaly on Netscaler 11.1-52.13]

I've been troubleshooting a bizarre problem in which VPN connected users are unable to reach an internal HTTPS website via Netscaler.

 

It looks like a bug in Netscaler's TCP implemntation.  From looking at traces, the following is happening when the client initiates the HTTPS handshake:

1. Client sends TCP SYN with MSS=1327 (determined by client-side VPN virtual adapter)
2. Netscaler sends TCP SYN+ACK with MSS=1330
3. TCP handshake completes succesfully and Client Hello is received by Netscaler
4. Netscaler responds with certificate chain, forming multiple segments of MSS 1330 with DF bit set
5. These are too big for the VPN tunnel, and cannot be fragmented, so the Cisco ASA (VPN concentrator) responds to the Netscaler with ICMP type 3,4 (fragmentation needed) and Next Hop MTU=1327
6. Despite receiving ICMP 3,4 messages, Netscaler continues sending oversized segments which client does not receive.
7. Client connection hangs and eventually times out

From reading this document - noting it is intended for Telco customers and carrying the caveat of requiring Citrix support to change the values - it would appear that Netscaler uses only 8 MSS values which is required to support its implementation of SYN cookies.  When establishing a TCP connection, the send MSS used by the Netscaler will be chosen from this table either by matching or rounding down to the next value.

 

The preset MSS table values in 11.1-52.13 are

 

9176,9156,8192,7168,6144,4196,3072,2048,1460,1440,1330,1220,956,536,384,128

 

(presumably the first 8 exist to provide Jumbo Frames support if enabled - otherwise only the latter 8 are used)

 

Based on my troubleshooting, if the MSS value in the SYN lies between 1322 and 1329 then for some reason, instead of rounding down to MSS=1220, the Netscaler instead rounds UP to the value MSS=1330 and then uses that value as the send MSS for the connection despite it being greater than the client's advertised MSS.

 

I have tried changing TCP parameters, disabling SYN Cookies and also disabling/enabling Path MTU Discovery to no avail.

 

Eventually I changed the MSS table as per the above document (on a non-production device) and as soon as I did this the issue went away and the connection send MSS was negotiated down to the nearest value.

 

I'm posting this incase anyone else has the same problem or encounters it in the future - however I'd also like some clarification from Citrix on whether we should be changing the MSS table or whether there are some risks or side-effects to be aware of.

 

Its worth noting that on the customer WAN I'm working on presently, there are a multitude of different tunnelling protocols in use and the MSS of connections is generally in the 1300-1400 range.  The default MSS table provides no granularity in this range.  As an experiment I have implemented a custom table which matches all the common tunnel MTU's seen on this particular network and as a result the TCP connections are being matched precisely instead of the Netscaler using an MSS which is 5-10% less than would be possible.

 

 

[GSLB with Content Switching]

Geoff I've been trying to do something similar and it does not appear to be possible, which is a major limitation for GSLB in content switched scenarios.

 

What I have is a single CS vServer with a bunch of non-addressable LB vServers bound, each representing different applications with different hostnames, in each datacentre.

 

It would be great if you could configure GSLB services and vServers for each of the applications and use the status of the non-addressable LB VS in each site - shared by MEP - to determine Site-level availability for each app.

 

However as things stand, you can't associate a GSLB service with a non-addressable virtual server, and you can't create multiple GSLB services with the same public IP.