Johannes Norz

I don't really know what a Mac is (and I refuse to do), but as far as I can see, the client is unable to create a config file. So the client can't create the directory needed to store the config file. These ones don't surprise me: No config directory, no config data. As far as I understand, MacOS seems to be just a custom shell for BSD, and BSD is UNIX. I guess, the user who installed this client does not have the right to create a subdirectory in the desired location (following UNIX best practices, this should be /etc).

Well, the Source IP (SIP) mode is the right choice. However, the problem with SIP mode is that the NetScaler uses the client IP. So it sends a TCP SYN packet from the client IP to the backend, and the backend server sends SYN/ACK to the "real" client. This packet comes as a surprise to the client and is therefore discarded. There are only two ways to work around the problem: The NetScaler and the mail server are in the same subnet, then you can, as mentioned, enter the NetScaler as the default gateway on the mail server (which has the disadvantage that the NetScaler must have licensed all traffic that the mail server must do to the Internet, this includes updates. And perhaps better: The components between NetScaler and mail server (switches, routers) must support Policy Based Routing (PBR). Then only the traffic that was initiated from the NetScaler runs via the NetScaler. If the device is a Cisco device, PBR can be programmed very quickly and easily via RISE Integration.

F5 won't solve his problem, rather the opposite would be true: He wants to get rid of costly components, not replace a very expensive one with an extremely expensive one 😂

There is no direct support for ISO 8583 built into WAF. However, you may use HTTP load-balancing and WAF for ISO 8583 data.

It is not supported.

Even though nspepi is a good tool, I would do a snapshot, examine the current configuration (i.e. which policies exist, where are they bound too and some more things like that). I would strongly recommend following Amin's suggestion to do a snapshot first. Even more: I'd clone this snapshot, move it into different networks (to avoid IP address conflicts, most hypervisors support host-only networks) and do the upgrade there. Make sure the MAC address of the first network card is the same as the original VM, or you won't be licensed.

I used source IP persistence for StoreFront (following Citrix leading practices). Now I found out, that persistence sessions get created, but they time out, even if a user is busy. before upgrading to 14.1, all entries in the persistence table are extended when the user does something. I want this behaviour back, as users tend to work for 8-10 hours daily, and not just for 30 minutes.

Until NS 14.1 build 8.50, disabled features had been marked as disabled in NS-GUI. That had been a good feature. Unfortunately, it vanished in 14.1 12.30 and did not return in 14.1 17.38. That's a bloody mess, as 1) we are used to it, and 2) it's been a rather handy feature. In short, I want this feature back!

That's true. I totally agree about not bind IP reputation globally. I miss statements about the implications: Binding globally would affect all vServers, including the ones you'll add in future, and in a non-obvious way. It won't be visible on vServer level, neither by opening the vServer, nor in visualizer. The implication of IP Reputation feature: The feature is based on webroot's database. Webroot runs several sensors all over the internet and is, therefore, able to detect IP addresses of malicious computers. It puts these IP addresses into its database. An incoming request is compared to (an offline-copy of) this database. If the IP is in, IP reputation will notice. There are several types of malicious IPs (ranging from infected PCs to TOR network endpoints), and in addition to .IPREP_IS_MALICIOUS we also have .IPREP_THREAT_CATEGORY (see here https://docs.citrix.com/en-us/citrix-adc/current-release/reputation/ip-reputation.html). That way, you could potentially filter things like TOA network endpoints. Based on my experience, I would not use thread categories like spam sources or similar, as infected PCs usually change their behaviour quite frequently. Webroot's reaction would potentially be too slow, even though they are pretty fast. One more: Webroot's database is also available with several firewall solutions. Usually, we filter as soon as possible, so I'd prefer the filtering mechanism of the firewall. Filtering on both sides, firewall and NetScaler doesn't make sense and adds unnecessary latency.