Paul Blitz
-
Posts
242 -
Joined
-
Last visited
-
Days Won
14
Content Type
Forums
Articles
Labs
Videos
TechZone
Citrix Community Articles
Events
Profiles
Posts posted by Paul Blitz
-
-
So, whilst I haven't been as active here as I used to be, I have, over the years tried to contribute and answer questions where I could.
I finally decided last month to take that step of retiring. Which means no more giving training, no more providing support for Netscalers. No more needing to have any Netscaler VPXes here to be able to use for training demos etc. My remote access solution for home, rather than using the Gateway feature on Netscaler, now uses OpenVPN on a Raspberry Pi!
It has been great to have been involved with Netscaler for the last 19 years, and it's good to see that Netscaler still has a good future. Good luck to you all!
So long... and thanks for all the fish!
Paul Blitz
(now retired!)
- 2
-
Why are you using TCP rather than HTTP?
Is there any particular reason that the Vserver is on port 84, surely port 80 would be more convenient?
The syntax "http://<fqdn>:84" is simply to tell the web browser that it needs to connect on port 84, rather than the default port 80: the "84" is never sent to the sever. The Netscaler's Vserver is on port 84, so it will accept the traffic, and it will send the traffic to the backend servers on the ports specified by their bindings to the service group 80 and 81) : you seem to have that correct. Are they the right way around? Are the IP's correct?
So, let's look at other things: the fact that you have a working monitor indicates that you have a SNIP... what monitor are you using that is validating the back end? If it's the default-tcp one, then maybe the actual service isn't there, it's something else.... what happens if you use a local browser, and connect to "http://<ip1>" and "http://<ip2>:81"?
Ok, a silly one: have you checked the netmask of the VIP address? If you create the VIP address by adding a vserver, then the netmask will be "255.255.255.255", which may cause you problems on the front end!
Take a look at the stats for the LB and the service group: what do they show?
Using wireshark: do you see the request packet coming in to the VIP? Do you see that traffic being passed to the backend servers?
-
Of course, whilst EPA can look for a client mac address, EPA won't run on an iPhone ?
Is this for Gateway / AAA, or something else?
-
-
In the GUI, you just go to System / NTP Servers: delete and add NTP servers as needed.
(If the current time is BADLY wrong, then you need to use a BSD shell "date" command to get it relatively correct, then the NTP will kick in.)
-
By the way, I see that they are killing off the "Standard Edition"...
-
The old Citrix ADC datasheets used to include this. The new Netscaler ones just list the different hardwares!
Here's an old datasheet: <link removed>
-
The NTP config is NOT part of the netscaler configuration, per se, so you would need to go to the shell, and view / edit the /nsconfig/ntp.conf file
-
If you trust someone enough to have shell access, you might as well just make them a superuser!
-
In the end, it turned out to be a firewall issue!!!! Grrr!!!
-
If you are using an HTTP monitor of any type, remember to tick the "secure" box: this converts the plaintext HTTP request into an encrytped HTTPS request.
Without that, you are sending a plaintext HTTP request (albeit over port 443) to an SSL server - which will fail, of course!
-
So, use your browser to look at the certificate chain, as seen by a browser: is it ok, or is it incomplete? Just because your browser doesn't show an error when it connects doesn't mean the chain is good (your PC may contain intermediate certs).
Also remember that, whilst most Server Certs issued just need a single intermediate cert, some need a chain of TWO intermediates. If that's the case, on the Netscaler, having linked the server cert to the 'lower' intermediate cert, you now need to also link that 'lower' intermediate to the 'upper' intermediate cert.
-
If you PURCHASED a licence, then inside the licence file (it's textual) it will say "Perpetual", so it never expires.
From a TECHNICAL perspective there should be no issues upgrading straight to 13.1 (but be aware that Classic Policies in the ADC have been killed off in 13.1, so make sure you aren't using any! Convert any to equivalent default policies / features)
-
I'm on 13.8-58.32 here, and it allowed me to create that bookmark ok
However, on my 13.1-24.38 I also got the Invalid URL error!
The documentation on bookmarks is 100% useless!
I can see in the 13.1.12.51 release notes (https://docs.citrix.com/en-us/citrix-adc/current-release/citrix-adc-release-notes/release-notes-13-1-12-51.html) it states:
[ CGOP-19685 ]
The Citrix Gateway portal enterprise bookmark feature supports only the following protocols. All other bookmarks are blocked. http://, https://, rdp://, and ftp://.
-
Does this error happen as soon as you connect to the page (ie BEFORE attempting to login), or is it after trying to login?. Did you flush your browser cache & relevant cookies?
-
Happy to report that the second upgrade, of SDX 12.1 to 13.1 went just as well as the 13.0 to 13.1 upgrade...
Next is upgrading the VPX instances: first pair went ok... we used that script to check for classic policies, and did a tidy up (there were unbound classic policies) and re-ran it.
-
- Clock seems fine
- sync working great
- dmesg.boot looks clean
- no VMAC
- no INC
- sync etc all enabled and working
There's an LDAPS LB on another instance that we know works, so we're about to see if it works via that (rather than using a direct 'cascade')... if it does, then this problem 'goes away' nicely!
-
Cant you change the session profile to not auto downgrade it?
Maybe time to upgrade your Netscaler?
-
Simply editting the text isn't going to work! It's all 'protected' by the data in those hexadecimal strings!
-
Gonna need a bit more info, I suspect... like how is the cs set up....
-
We gave up using gui to upgrade on the training courses, because, for whatever reason, it no longer works. Never seen an issue using cli to upgrade, it's not hard to do...
-
It seems that classically only /8, /16 and /24 are supported, although there is RFC 2317 that helps get around this... sadly not as trivial as using a /26
So Netscaler is correct in what it's doing!
-
ssl_bridge is almost just a tcp proxy, so responder actions are very limited.
-
The problem remains with the secondary, even after a failover... so the test fails and you can't log in with ldaps to the secondary, but promote it to primary, and it then works ok (and of course, the box demoted to secondary now fails!)
So that pretty well eliminates all suggestions so far.
3 other vpx pairs are working fine!
GSLB configuration across multiple sites
in Core ADC use cases
Posted
If you had actually posted the question, I could have replied.
Don't ask if you can ask a question, just ask the question!