Jump to content
Updated Privacy Statement

Gregor Blaj

Members
 View Profile  See their activity

  • Posts

    52

  • Joined

  • Last visited

 Content Type 

Posts posted by Gregor Blaj

    RPC node password update

    in Core ADC use cases

    Posted

    On 3/20/2020 at 8:01 AM, Rhonda Rowland1709152125 said:

    GSLB is different as the ADC's participating are not in a synchronized config like an HA pair (or at least not an automatically synced config).  And rpcnode settings are not pushed as part of a gslb sync (which is a manual command anyway).

     

    In an HA pair, with the way command propagation works, changing the rpcnode password for NodeA's NSIP address WILL result in in NodeA and NodeB's rpcdnode (for NSIPA) being updated BECAUSE propagation pushes the the command to the secondary first, acknowledges if it works, and then applies to primary (self).  If propagation failed, then a prop fail/triggerring sync event is noted. The command is then in place on Node A, but might need to be manually applied to Node B (but usually not a n issue). Then you can update the NSIPB rpcnode password from NodeA and rely on propagation to update both copies of the NSIPB rpcnode password on Node B and Node A.

     

    However, when you change the rpcnode password or secure flag settings on rpcnodes participating in a GSLB config, command propagation isn't automatic in the GSLB Site partners (so location 1 (nodes A/B) and location 2 (nodes C/D)).  And if the location 1 pair is out of sync with location 2 pair, then the gslb sync command won't work anyway.

    So assume in a GSLB config you will need to manually update the appropriate rpcNodes (gslb site IPs) in each HA pair separately.  Update location 1 (node A/B) and then location 2 (node c/d) seperately.

     

    Then verify The HA pairs are happy A to B/B to A and C-to-D/D-to-C; and then verify GSLB to GSLB MEP is working between the ha pairs.

     

    I was testing this recently with standalone GSLB nodes, but even if I changed the RPC node password on just one node, the GSLB status never went down. Found it a bit odd.

    External/internal out-of-service DOWN occurs irregularly.

    in Core ADC use cases

    Posted

    It looks like it just isn't receiving a response to the probe but ICMP isn't the most reliable monitor. You can try a few things.

     

    1. Do a trace while the service is in a failed state and verify that ICMP responses are indeed not being received.

    2. As above, also try a manual ping from the shell while the service is down.

    3. Try a different monitor; since you're using 8.8.8.8 try a DNS monitor and see if that is more reliable. Or try an HTTP monitor to another destination.

    Stateful ACLs

    in Core ADC use cases

    Posted

    Hi,

     

    I'm doing a bit of testing with ACLs. With the following ACL in place I would expect the Netscaler not to be able to ping outbound hosts, as return traffic to the NS IP should be blocked. 

    add ns acl Deny_Mgmt DENY -destIP = 192.168.1.10 -priority 100 -logstate ENABLED -stateful NO

    But this isn't the case, return ICMP traffic is not blocked. I then figured the default (not visible) outbound ACL must be stateful (hence allowing return traffic), so I created another non-stateful ACL specifically allowing outbound ICMP from the NS IP. 

    add ns acl Allow_ICMP -srcIP = 192.168.1.10 -protocol ICMP -priority 110 -logstate ENABLED -stateful NO

    I can see hits on the Allow_ICMP ACL but return ICMP traffic is still allowed. Why would this be? What is allowing the return traffic?

     

    Thanks for any input.

    disablle tl1.0 and tls1.1 on netscaler

    in Core ADC use cases

    Posted

    16 hours ago, Chris Marreel said:

    Hi All, a quick question related to this topic.

    If you disable TLS 1.0 and 1.1, on the Netscaler Gateway Virtual Server, you mentioned you loose the possibility to connect from some (older) browsers and probably allso some (older) Citrix Receivers.  

    Do you have an idea which older Receiver versions will have issues ?

    Is this known or listed somewhere ?

     

    I know e.g. that disabeling SSL 3.0 had impact on Citrix Receiver versions lower than version 4.5.  

    I noticed SSLLABS is making it harded to score an A+ rating from january 2020.  If you still have TLS 1.0 and 1.1 enabled the rating will be downgraded to a B rating. 

            on the SSLLABS-test page you see at the moment -> "This server supports TLS 1.0 and TLS 1.1. Grade will be capped to B from January 2020."

     

    Thanks for you thoughts,

    Greetings,

      Chris

     

    The following article shows when TLS support was introduced for each Receiver version, https://support.citrix.com/article/CTX232266, but it doesn't include the relevant ciphers. For Windows, it looks like TLS 1.1 and 1.2 support was introduced in the same version, 4.2.100 (April 2015, https://support.citrix.com/article/CTX112613).

     

    You can use logging from the Netscaler to report on client Receiver versions being used to log into an environment.

    Nitro API - Call to disable GSLB Service?

    in Core ADC use cases

    Posted

    Good point, disabling the VPN/LB vserver would work too but as long as the resource is Netscaler hosted.

     

    I don't get GSLB services returned with a GET to the Service endpoint either, but I am able to modify them (at least the 'state' property) using the Service endpoint. To return GSLB services I have to use the GSLBService endpoint. 

    http://{{ inventory_hostname }}/nitro/v1/config/gslbservice?attrs=servicename

    I did try creating a Service with the same name as a GSLB Service and it doesn't let you, which at least sort of adds up.

    Nitro API - Call to disable GSLB Service?

    in Core ADC use cases

    Posted

    1 hour ago, Ross Bender said:

    One way to check is to tail the nitro.log and request.log files in /var/log while you are doing the operation in the GUI. That should help point in the right direction as to the appropriate API/SDK method to use.

     

    Thanks, that got it. I could see in nitro.log that it was a POST call and in httpaccess.log that it went to /nitro/v1/config/service, rather than 'gslbservice'. There is no request.log file.

     

    https://developer-docs.citrix.com/projects/netscaler-nitro-api/en/12.0/configuration/basic/service/service/#di

     

    Cheers for your help.

    disablle tl1.0 and tls1.1 on netscaler

    in Core ADC use cases

    Posted

    You should be disabling TLS 1.0 and TLS 1.1 everywhere but it is [arguably] more critical on externally accessible resources, so start there.

     

    In MAS/ADM you can easily modify SSL settings, see https://docs.citrix.com/en-us/netscaler-mas/12/manage-system-settings/how-to-configure-ssl-settings-for-mas.html.

     

    Once the protocols are sorted out, you will also need to remove insecure ciphers. The TLS 1.2/TLS 1.3 ciphers below were adequate for an A+ rating in October 2019 but as Johannes mentioned, certain older clients will not be able to connect. You can get all this info if you do a scan of your sites with SSL Labs (https://www.ssllabs.com/ssltest/).

     

    Quote

    TLS1.2-ECDHE-ECDSA-AES128-GCM-SHA256
    TLS1.2-ECDHE-ECDSA-AES256-GCM-SHA384
    TLS1.2-ECDHE-ECDSA-AES128-SHA256
    TLS1.2-ECDHE-ECDSA-AES256-SHA384
    TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
    TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
    TLS1.3-AES256-GCM-SHA384
    TLS1.3-CHACHA20-POLY1305-SHA256
    TLS1.3-AES128-GCM-SHA256

     

    GSLBURL Bug?

    in StoreFront

    Posted

    7 hours ago, Mark Dear said:

    Hi Warnox

     

    It sounds like you are experiencing a known issue we have discovered and now fixed in current releases of STF.  Luckily there is a very simple workaround in the affected versions from 3.9 upwards to the fix release using the Storefront admin console.  

    After having set the Gateway and GSLB URLs via Powershell on your gateway objects then simply unregister the GSLB gateways and then re-register them all to the Stores they are bound to.  Alternatively upgrade to a higher release than 1811 as I believe we fixed this in 1903 or higher.  Moving to the latest release will definitely contain the bug fix.

    See the attached screen shot of Configure Remote Access Settings.

    Please follow all recommendations in this doc I wrote when configuring GSLB within StoreFront.  Pay particular attention to the concept of unique callback URLs per gateway and please also set the VIP for each GSLB gateway as this is needed to help StoreFront identify the gateways if they all have the same URL.

    https://docs.citrix.com/en-us/storefront/current-release/integrate-with-citrix-gateway-and-citrix-adc/configure-two-gateway-urls.html

    If you have any problems using the feature please contact me and I will assist you further.

    Regards Mark

    Remote Access Settings.jpg

     

    Hi Mark,

     

    Thanks for your reply.

     

    I actually set this up in a vanilla lab over the weekend and was able to replicate the issue with even just a single gateway. This was both in 1811 and 1909, so I don't think the bug is resolved in the latest release?

     

    Please note that in my setup a callback URL is not required, but I managed to get around the bug with the following steps.

     

    1. Only a single gateway with a gateway URL configured on Netscaler definition in Storefront (GLSB URL, CallBack URL and vServer IP not configured). Everything working.
    2. Set GSLB URL, Gateway connections stop working (Cannot Complete Request).
    3. Set Callback URL, Gateway connections working again.
    4. Remove Callback URL, everything still working.

    GSLBURL Bug?

    in StoreFront

    Posted

    3 hours ago, Vamsi Krishna Kanduri said:

    It looks like SSO to the storefront is failing.

    Please paste the configuration of session profile.

     

    Thanks,

    Vamsi

     

    Hi Vamsi,

     

    Session Profile config below. I'm not sure why this would be related to the ADC config, if the only changes made are adding an additional URL to StoreFront? 

    add vpn sessionAction ICA-SF-WI -defaultAuthorizationAction ALLOW -SSO ON -icaProxy ON -wihome "https://storefront.domain.com/Citrix/centralWeb" -ntDomain CONTOSO

    Cheers.

    GSLBURL Bug?

    in StoreFront

    Posted

    Hi,

     

    I haven't seen anything about the below issue being fixed in newer StoreFront releases, but it seems like a bug to me.

     

    1. Set the GSLBURL for a NetScaler Gateway definition in StoreFront and propagate the changes.

    2. Connections from the Gateway, to the original URL (citrix.company.com) and the GSLB URL (site1.company.com), start failing ('Cannot complete your request').

    3. Remove the GSLBURL for the NetScaler Gateway definition.

    4. Connections still failing with the same error.

    5. Restart services, reset IIS, reboot servers etc... Error still present.

    6. Re-create the NetScaler Gateway definition in StoreFront, propagate the changes.

    7. Starts working again.

     

    I'm not sure why the GSLBURL specified (site1.company.com) didn't work, or what persisted once I reverted the setting, but I'm including the relevant logs below. Has anyone come across this before?

     

    • StoreFront: 1811
    • NetScaler: 12.0 60.10
    • CallBack URL: Blank
    • vServer IP: Blank
    • SSO Domain (Session Profile): Set to domain NETBIOS name.
    • Trusted Domains in SF: Configured, including the above.
    • Other gateways specified in StoreFront: Working the whole time as usual.

     

    Error 1:

    Quote

     

    The AG Web Service at: http://localhost/ failed with the following error. This endpoint will be ignored until: 16/09/2019 10:41:15 a.m.
    Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null
    A communication error occurred while attempting to contact the NetScaler Gateway authentication service at http://localhost/. Check that the authentication service is running.
       at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
       at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)

    System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
    The request failed with the error message:
    --
    <head><title>Document Moved</title></head>
    <body><h1>Object Moved</h1>This document may be found <a HREF="http://localhost/Citrix/centralWeb/">here</a></body>
    --.
       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Citrix.DeliveryServices.Authentication.CitrixAGBasic.AGAuthService.AuthenticationServiceSoap.GetAccessInformation(String sessionId, String username, String domain)
       at Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)

     

     

    Error 2:

    Quote

    None of the AG callback services responded

     

    Error 3:

    Quote

     

    A CitrixAGBasic Login request has failed.
    Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticatorException, Citrix.DeliveryServicesClients.Authentication, Version=3.17.0.0, Culture=neutral, PublicKeyToken=null
    Authenticate encountered an exception.
       at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)
       at Citrix.Web.AuthControllers.Controllers.GatewayAuthController.Login()

    System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
    The remote server returned an error: (403) Forbidden.
    Url: https://127.0.0.1/Citrix/centralAuth/CitrixAGBasic/Authenticate
    ExceptionStatus: ProtocolError
    ResponseStatus: Forbidden
       at System.Net.HttpWebRequest.GetResponse()
       at Citrix.DeliveryServicesClients.Utilities.HttpHelpers.ReceiveResponse(HttpWebRequest req)
       at Citrix.DeliveryServicesClients.Authentication.TokenIssuingClient.RequestToken(String url, RequestToken requestToken, String primaryToken, String languages, CookieContainer cookieContainer, IEnumerable`1 acceptedResponseTypes, IDictionary`2 additionalHeaders)
       at Citrix.DeliveryServicesClients.Authentication.AG.AGAuthenticator.Authenticate(HttpRequestBase clientRequest, Boolean& passwordSupplied)

     

     

    Cheers.

    Netscaler Throughput

    in NetScaler Gateway

    Posted

    I don't think MAS/ADM let's you poll more frequently than every 5min, "Your polling interval cannot be less than 5 minutes or more than 60 minutes.". Look at something like Cacti (or whichever SNMP tool you have access to) where you can poll interface statistics at the desired interval?

    Monitoring

    in NetScaler Application Security

    Posted

    That won't work because Response can't be longer than Interval (Response < Interval). The following would mark a service as failed between 30-41 seconds.

     

    Interval: 11

    Response: 10

    Retries: 3

     

    Or this for 30-36 seconds.

     

    Interval: 6

    Response: 5

    Retries: 6

     

    Remote GSLB Service - MEP or Monitor?

    in Core ADC use cases

    Posted

    1. It's just 2 sites and there are no issues with site to site communication.

    2. Yes, MEP is still used for other functions.

    3. Method is RTT and using a mix of Source IP and Cookie Insert (proxy) persistence.

     

    I guess with using MEP for tracking state other factors have to be taken into account and defaults modified, such as MEP Time Delay and Trigger Monitor, whereas using standard monitors removes this complexity.

    Monitoring

    in NetScaler Application Security

    Posted

    - Interval defines how often the appliance will probe (check) the back end service, under normal operations.

    - Response Timeout defines how long to wait before marking a probe as failed.

    - Retries define how many times the appliance will retry connecting to the back end service which had a probe fail, before marking it as down.

     

    By default a service which goes down will be marked as down after ~6-11 seconds, keeping in mind the default Response Timeout is 2 seconds, not 2 ms.

     

    Minimum: 3x2 seconds (3 probes x Response Timeout)

    Maximum: 5 + (3x2) seconds (Interval + (3 probes x Response Timeout))

    StoreFront via NS GW - Load Balancer vs GLSB

    in Core ADC use cases

    Posted

    What do your internal/external/gslb URLs look like and what is the authentication method externally? To me it sounds like your Netscaler Gateway settings in StoreFront are not quite correct in terms of the URLs (Citrix Gateway URL, vServer IP address, Callback URL and GSLB URL). Have a look at this article, it's really useful, and then compare it to your setup.

     

    https://docs.citrix.com/en-us/tech-zone/design/design-decisions/storefront-gateway-integration.html.

     

     

© Cloud Software Group, Inc. All rights reserved.

×
×
  • Create New...