How to use Forcedtimeout option for Traffic Management session on NetScaler

This article provides information on one of the logout mechanisms that Netscaler offers called “Forcedtimeout”, its usage and underlying configuration.

Use case and Solution

NetScaler offers multiple ways to timeout user session.

You can configure idleTimeout in “tm session policies/actions” such that if user is idle for a certain period, session gets removed.

You can also configure traffic policy based on-demand logout such that when a user hits certain page on backend, Netscaler removes it session (after serving that logout page).

Above approaches address majority of logout cases. However, some applications have background traffic, for monitoring. So, Netscaler does not remove session for those applications in a timely fashion assuming it is active traffic. One such Application is OWA. OWA is a peculiar application that opens up a bunch of tcp connections to keep the session alive. Today in Netscaler, when the timer is fired, it sees that there are still active connections and therefore tries again after few minutes. Since OWA doesn’t close these monitoring connections, session keeps prolonging.

Therefore there is some more config required to logout user from such applications as OWA in order to essentially tell Netscaler what those monitoring sessions are .

It is due to the monitoring /keepalive messages from OWA that when a user tries to open the application in another tab, it still opens up without asking for the user credentials again.

For such applications and also for cases wherein an administrator wants to remove user session regardless of user activity, one could configure logout mechanism “forcedTimeout” such that a session lives up a maximum specified time regardless of activity. This forcedtimer can be reset if needed. Otherwise, once started, it will remove session after stipulated time.

Configuration

Two new parameters are introduced in traffic action namely, ForcedTimeout and ForcedTimeoutVal as shown below in bold.

Usage: add tm trafficAction <name> [-appTimeout <mins>] [-SSO ( ON | OFF )

[-formSSOAction <string>]] [-persistentCookie ( ON | OFF )]

[-InitiateLogout ( ON | OFF )] [-kcdAccount <string>]

[-samlSSOProfile <string>] [-forcedTimeout <forcedTimeout>

-forcedTimeoutVal <mins> ]

ForcedTimeoutVal is a number in minutes to which force timer needs to be set. ForcedTimeout argument itself can take three values START, STOP and RESET. These options are explained below:

START: When a timer is not already started, START can be used to start a timer. However, once a timer is STARTed at a timestamp t1, another start at a later timestamp t2 is a NOOP. This means, once a timer is started, another start on that timer is ignored.

STOP: This option can be used to stop an already running timer. This means, if administrator as started a timer in the past, he could stop it based on another traffic pattern.

RESET: This option can be used to START or RESET a timer. If timer is not already running, this option would start it. If timer is already running, then this option will stop the timer and start it again.

One of the differences between START and RESET is that once a timer is started, START does not result in another start.

Above trafficaction needs to referenced in a traffic policy which in turns needs to be bound to TM vserver.

add tm trafficPolicy <name> <rule> <action>

bind lb vserver lbhttp –policyName <name> -priority <number>

Example Configuration

In case of rule as “true“ as below after user session is created ,Netscaler registers a timer and when the timer is expired (2 mins here), the session gets killed regardless of user activity.

add tm trafficAction trafficact -SSO ON -forcedTimeout START -forcedTimeoutVal 2

add tm trafficPolicy trafficpol true trafficact

bind lb vs lbowa –policy tmowapol –priority 1

With rule as “HTTP.REQ.URL.CONTAINS(“UA=0″)” in the example below, after the session is created , the timer will start as soon as there is a traffic pattern matching “UA=0”.This pattern matches the keepalives from OWA application ;therefore as soon as this traffic pattern is matched,Netscaler will log -out the user from the application,

add tm trafficAction trafficact1 -SSO ON -forcedTimeout START -forcedTimeoutVal 2

add tm trafficPolicy trafficpol1 “HTTP.REQ.URL.CONTAINS(“UA=0″)” trafficact1

bind lb vs lbowa –policy trafficpol1 –priority 1

Related:

FAQ: NetScaler Load Balancing/Persistence

Q: How does LB slow start work with persistence? When is the slow start exited?

A: By default a newly configured virtual server remains in a Slow Start mode for Startup RR Factor of 100.

If there are 2 services bound to the LB VIP, the LB vServer will exit the slow-start mode after 200 hits. The calculation is PE(n) X service(n) X 100 = 1 X 2 X 100 = 200 (assuming there is one PE).

When Source IP based persistency is configured, the client connections need to hit the LB VIP with different source IP’s. In the above case, if 200 connections are initiated from the same source IP, the counter will only decrement by 1 (with 199 connections remaining). The rest of the 199 connections need to be from unique source IP’s for the NetScaler to exit the slow-start mode and come back to the configured load balancing method

root@netscaler# nsconmsg -K newnslog -d current -s disptime=1 -g vsvr_do_next_rrreq | moreDisplaying performance informationNetScaler V20 Performance DataNetScaler NS11.1: Build 51.21.nc, Date: Dec 22 2016, 12:32:24 14 427000 200 200 28 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:55:59 2017 15 322000 199 -1 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 11:01:21 2017 16 1938995 198 -1 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 13:15:31 2017 17 14000 197 -1 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 13:15:45 2017If the persistence is set to NONE, irrespective of the Source IP's, once the number of connections reaches 200, the slow start is exited 2 223997 200 1 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:46:46 2017 3 49000 199 -1 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:47:35 2017 4 7000 176 -23 -3 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:47:42 2017 5 7001 163 -13 -1 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:47:49 2017 6 6999 132 -31 -4 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:47:56 2017 7 7000 109 -23 -3 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:03 2017 8 7000 89 -20 -2 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:10 2017 9 7000 57 -32 -4 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:17 2017 10 7000 25 -32 -4 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:24 2017 11 7001 23 -2 0 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:31 2017 12 14000 13 -10 -1 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:45 2017 13 6999 0 -13 -1 vsvr_do_next_rrreq vserver_lb_172.16.181.146:80(LB) Fri Jul 7 10:48:52 2017

Refer to https://support.citrix.com/article/CTX108886 to know more about Slow-Start

Q: A persistence RULE is configured with a persistence timeout of 10 minutes. When “show persistent sessions” command is run for that particular load balancing vServer, many entries with a timeout of 0 (expired) are still see in the output table. What causes this persistence table entries to show even though the timeout has expired?

A: The “show persistence session” output only displays entry from master core and not from peer cores where persistence session is cached.

Even if the timeout value is set to 0 on the master core, the other core still has this session entry with non-zero value due to which the master core does not remove this from its table immediately after it times out.

By design, after the connection is idle and deleted and the persistence timeout has passed, in addition to remaining for 2 minutes due to the relationship between the master core and the peer core, there may be a case in which 120-330 seconds remain for synchronization between NSPPE and internal processing.

Q: LB vServer (HTTP) does not load balance the hits on the vServer correctly when LB method is Least Connection. Uneven number of hits seen on the 2 load balanced backend services.

A: In the “Least Connection” method of load balancing, the number of connections per service is the value that we take into account, not the number of hits to the service.

Q: Does the TCP profile bound on the CS VIP or the corresponding LB VIP takes precedence?

A: NetScaler will use the TCP profile bound on the Content Switch vServer for front-end/client connection

The TCP profile bound to the Load Balancing vServer will not be used if the connection is made through the Content Switching vServer

The TCP profile bound to the Load Balancing vServer will be applied only if the client establishes the connection with the Load Balancing VIP directly

If no TCP profile is bound to the Content Switch vServer, the default TCP profile will be used

Q: Can a VIP address be bound to netprofile/ ipset in Cluster?

A: This is currently not allowed. You will see the error “ERROR: Operation not permitted” while trying to do this. This is supported starting from 11.1 build 58.x and 12.0 build 33.x (Issue ID: 664024)

Q: Are active sessions dropped while disabling a service or a member of a service group?

A: Yes, the active connections are dropped if we do not do a “Graceful” disable of the service. Active connections are maintained if the “Graceful” checkbox is selected.

Traffic Management ->LB-> ServiceGroup-> Manage Member -> Select member then click disable -.> Check Graceful and click ok

Q: What does the “Graceful” option do while disabling a service?

A: This checkbox indicates graceful shutdown of the service. System will wait for all outstanding connections to this service to be closed before disabling the service.

Gracefully disabled services will maintain all current connections until these have timed-out/gracefully closed. All new connections will be sent to the enabled services.

Just disabling the services, will migrate all existing connections to the enabled service

State

Results

Graceful shutdown is enabled and a wait time is specified.

Service is shut down after the last of the current active client connections is served, even if the wait time has not expired. The appliance checks the status of the connections once every second. If the wait time expires, any open sessions are closed.

Graceful shutdown is disabled and a wait time is specified.

Service is shut down only after the wait time expires, even if all established connections are served before expiration.

Graceful shutdown is enabled and no wait time is specified.

Service is shut down only after the last of the previously established connections is served, regardless of the time taken to serve the last connection.

Graceful shutdown is disabled and no wait time is specified.

No graceful shutdown. Service is shut down immediately after the disable option is chosen or the disable command is issued. (The default wait time is zero seconds.)

Q: NS 10.5: NetProfile does not work intermittently and traffic is sourced from the wrong SNIP

A: This has been identified as an issue in the build of 10.5 and is fixed in 11.1 (Issue ID: 536377)

Q: Why does SSL VIP use HTTP/1.1 despite configuring HTTP/2 in the HTTP profile bound?

A: In the SSL handshake, we see in the client hello that client supports http2 over TLS (h2), however the VIP chooses HTTP 1.1.

HTTP/2 only supports TLS version 1.2 or higher for HTTP/2 over TLS (h2). HTTP/2 doesn’t support any of the ciphers suites that are listed in the following article.

https://http2.github.io/http2-spec/#BadCipherSuites

Ensure that HTTP/2 supported Ciphers are bound to the VIP

Q: Can we view SSL counters/ statistics specific to a vServer or a VIP?

A: This is currently not possible. An enhancement request with the Product management has been raised for this:

ENH0234441: Display of per vServer/service stats with “stat ssl” command

ENH0234442: SSL per vServer/service stats should be displayed with nsconmsg -s ConSSL output

Q: What does the spillover count (SO) for a vServer in the ConLb output indicate?

A: If you have spillover configured or have a backup vServer and spillover occurs, they will be sent to the backup and the counter will increment. If you do not have spillover configured or a backup vServer configured, then the connection is reset and the spillover counter will still increment. The incrementing counter is indicative of requests being reset when you have no spillover configured.

When you do have spillover configured and requests are actually being spilled over, the counter is going to increment. Thus the counter increments in either scenario. Hence, if you know you don’t have spillover configured and you see spillover hits, then you should consider setting up spillover so that requests are processed instead of being reset.

Q: What are the ways to protect a Load Balancing vServer against Failure when it goes DOWN?

A: “Disable Primary When Down”: If you want the backup virtual server to remain in control until you manually enable the primary virtual server even if the primary virtual server comes back up, select “Disable Primary When Down”. For more information on “Configuring a Backup Load Balancing Virtual Server” refer docs:

http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-protect-configuration/config-backup-vserver.html

“Connection fail over”: Connection fail over helps prevent disruption of access to applications deployed in a distributed environment. In a NetScaler High Availability (HA) setup, connection fail over (or connection mirroring-CM) refers to keeping active an established TCP or UDP connection when a fail over occurs. The new primary NetScaler appliance has information about the connections established before the fail over and continues to serve those connections. After failover, the client remains connected to the same physical server. Setup supported for connection failover are Service type –> ANY, UDP, TCP, FTP, SSL_BRIDGE.

For more information on “Connection failover” refer

http://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-protect-configuration/connection-failover.html

Other methods can be viewed in the following link: https://docs.citrix.com/en-us/netscaler/11/traffic-management/load-balancing/load-balancing-protect-configuration.html

Q: Can we integrate MFA with LB vServer?

A: Yes, this can be done by configuring AAA vserver which can be configured as SAML SP. Microsoft MFA can be configured as SAML IDP if it has access to the LDAP/Radius.

Related:

VPX on SDX becomes inaccessible when an interface is Administratively Disabled.

Root Cause:

==========

It’a bug with Free BSD as explained below:

When interface is Administratively Disabled, the IFF_DRV_RUNNING flag is not getting set. The IFF_DRV_RUNNING flag is used to indicate the FreeBSD stack to invoke the driver’s functions.

If the aforementioned flag is not set (which was being cleared when interface is disabled using NSCLI), then FreeBSD stack will not forward the packet to Packet Enginer and will cause ping command to generate the failure message “ping : Host network is down”.

Related:

Commonly Used Options and Filters with nstcpdump.sh NetScaler Script

  • -i<Interface_Number>: to restrict recording of the packets to the specified interface. You can use this option multiple times to select multiple interfaces.

Note: The -i, -r and -F are not supported on NetScaler 10.5 and the following message will be displayed when any command is used with this option:

nstcpdump.sh: utility to view/save/sniff LIVE packet capture on NETSCALER boxtcpdump version 4.0.0libpcap version 1.0.0Usage: tcpdump [-aAdDefKlLnNOpqRStuUvxX] [ -c count ][ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ][ -i interface ] [ -M secret ] [ -r file ][ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ][ -y datalinktype ] [ -z command ] [ -Z user ][ expression ]NOTE: tcpdump options -i, -r and -F are NOT SUPPORTED by this utility

For NetScaler 10.5, if you want to filter traffic based on the interface, then the following command can be used:

start nstrace –size 0 –tcpdump ENABLED –filter CONNECTION.INTF.EQ(“1/1”)

Filter Expressions

The following is a list of some options you can use in the filter expression. You can combine multiple expressions by using the boolean operators.

  • host <IP_Address>: to restrict recording of the packets to or from the specified host IP address.

  • net <Subnet_Address> mask <Netmask>: to restrict recording of the packets from the specified subnet.

  • port <Port_Number>: to restrict recording of the packets for the specified TCP or UDP port.

  • portrange <From_Port_Number>-<To_Port_Number>: to restrict recording of the packets for the specified range of the TCP or UDP port numbers.

  • dst port <Port_Number>: to restrict recording of the packets for the specified destination TCP or UDP port numbers.

  • src port <Port_Number>: to restrict recording of the packets from the specified source TCP or UDP port numbers.

  • tcp: to restrict recording of the packets only to the TCP packets. This option is a substitute for the ip proto x option.

  • udp: to restrict recording of the packets only to the UDP packets.

  • arp: to restrict recording of the packets only to the ARP packets.

  • icmp: to restrict recording of the packets only to the ICMP packets.

The operators that can be used with filter expressions are ==, eq, !=, neq, >, gt, <, lt, >=, ge, <=, le, and BETWEEN. Additionally, multiple sets of qualifiers can be used with boolean && or || operator.

Examples

The following are some of the examples for running the nstcpdump.sh script:

  • root@ns# nstcpdump.sh -X dst host 10.102.13.14 and port 80

    The output of this command is displayed on stdout and consists of all tcp port 80 traffic destined to the 10.102.13.14 IP address.

  • root@ns# nstcpdump.sh -w /var/trace/trace1.cap -i 1/1 -i ½

    The output of this command is directed to the /var/trace/trace1.cap file and consists of all traffic on the interfaces 1/1 and 1/2.

  • root@ns# nstcpdump.sh -w /var/trace/trace2.cap host 10.102.13.14 and not port 443

    The output of this command is directed to the /var/trace/trace2.cap file and consists of all traffic to or from the host IP address 10.102.13.14 and which does not have destination or source port as 443.

  • root@ns# nstcpdump.sh host 10.102.13.14 and host 10.102.13.15

    The output of this command is displayed on stdout and consists of all traffic between the host 10.102.13.14 and 10.102.1315 IP addresses.

Sample Output

The following is a sample output of the nstcpdump.sh script:

root@103# nstcpdump.sh port 80Setting 1000 pages (4000 KB) of trace buffers ... Done.Enabling all nic trace mode=6 ... Done.Changing trace packet length from 0 to 0 ... Done.Saving current trace data in file 'pipe' for '3600' seconds ... in TCPDUMP format18:17:13.391479 10.198.4.112.29221 > 10.198.4.41.http: S 1430428239:1430428239(0) win 8190 <mss 1460>18:17:13.391599 10.198.4.41.http > 10.198.4.112.29221: R 0:0(0) ack 1430428240 win 0 (DF)18:17:13.691462 10.198.4.112.29217 > 10.198.4.204.http: R 1430282160:1430282160(0) win 980018:17:13.691467 10.198.4.112.29217 > 10.198.4.204.http: R 1430282160:1430282160(0) win 980018:17:16.091528 127.0.0.2.61049 > localhost.http: S 1430522929:1430522929(0) win 8190 <mss 1460>18:17:16.091566 localhost.http > 127.0.0.2.61049: S 1213225328:1213225328(0) ack 1430522930 win 57344 <mss 1460> (DF)18:17:16.091570 127.0.0.2.61049 > localhost.http: F 1:1(0) ack 1 win 819018:17:16.091585 localhost.http > 127.0.0.2.61049: . ack 2 win 58400 (DF)18:17:16.091654 localhost.http > 127.0.0.2.61049: F 1:1(0) ack 2 win 58400 (DF)18:17:16.091665 127.0.0.2.61049 > localhost.http: . ack 2 win 8190/div>

The following table contains the details of the entry highlighted in the preceding output:

Timestamp Source IP Source Port Direction Destination IP Destination Port TCP Flags Sequence Number Additional Info

18:17:13.391479

10.198.4.112

.29221 > 10.198.4.41 .http: S 1430428239:1430428239(0) win 8190 <mss 1460>

Related:

  • No Related Posts

Longer than usual launch duration of Virtual App and Desktop while using Citrix Gateway Service

After 18th May, 2020 users with the following registry key set to “Preferred” can attempt to initiate an EDT connection. As EDT is not yet provisioned by admin, it will take few seconds for the connection to fallback to TCP, causing the delay.

HKEY_CURRENT_USERSoftwareCitrixIca ClientEngineLockdown ProfilesAll RegionsLockdownNetworkEDT

HKEY_CURRENT_USERSoftwarePoliciesCitrixIca ClientEngineLockdown ProfilesAll RegionsLockdownNetworkEDT

HKEY_LOCAL_MACHINESoftwareCitrixIca ClientEngineLockdown ProfilesAll RegionsLockdownNetworkEDT

HKEY_LOCAL_MACHINESoftwarePoliciesCitrixIca ClientEngineLockdown ProfilesAll RegionsLockdownNetworkEDT

On 64 bit machine

HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeCitrixICA ClientEngineLockdown ProfilesAll RegionsLockdownNetworkEDT

Related:

TLS handshake fails with any TLS LB VIP FIPS 9700 – Reset code 9811 from ADC

Daylight savings time changed and NTP Servers out-of sync with ADC.

Time mismatch between client-server created by Daylight saving time 2020 began at 2:00 AM Time stamp mismatch in client-server created by Daylight Saving time change and out-of sync NTP server.

TLS is time sensitive, ADC detects a time mismatch and teardown TLS Session sending a RESET with Code 9811

Note regarding REST code 9811

=============================

As part of TLS handshake :: After a “Change Cipher Spec” message from Client machine, ADC should send back another “Change Cipher Spec” confirming the newly created TLS Session, but instead ADC sends a RESET message with RESET code :: 9811 because it detected a time stamps mismatch.


Following this article :: NetScaler Reset Error Codes

https://support.citrix.com/article/CTX200852

Reset code 9811 means :: NSDBG_RST_ERRHANDLER: This reset code is used with SSL. After sending a Fatal Alert, the NetScaler sends a RST packet with this error code. If the client does not display any supported ciphers to the NetScaler appliance, the appliance sends a Fatal Alert and then this RST packet.

In this case this error code is deceiving because the client machine did displayed ciphers available to ADC, but ADC found a mismatch in Time Stamp TLS Session-ID and invalidates the Session.

Cipher used on this Session was :: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Handshake Protocol: Server Hello

Handshake Type: Server Hello (2)

Length: 87

Version: TLS 1.2 (0x0303)

Random: 5e66690d10ed940e434f5ef414065933aac401eaf2806ad7…

Session ID Length: 32

Session ID: 1a1ff2f6e4aaa45336d6c8f3454892b324fea21528474cce…

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

Compression Method: null (0)

Extensions Length: 15

Extension: application_layer_protocol_negotiation (len=11)

Related:

SSL connection toward explicit forward proxy

I need a solution

Hi all,

We are currently using an explicit forward proxy using HTTP basic auth. The goal is to at least secure the transmitted credentials.

What we had set up before:

  1. client —– http —–> proxysg:80 —-> http://internet.site/
  2. client —– http —–> proxysg:80 —-> https://internet.site/… (uses HTTP CONNECT)

What we would like to do now is the same as above, except the first step which should preferably become https:

  1. client —– https —–> proxysg:443 —-> http://internet.site/
  2. client —– https —–> proxysg:443 —-> https://internet.site/

That last part required setting up a proxy service listening on proxysg:443 and selecting “HTTPS reverse proxy”. I hope that is correct!

Currently accessing a site using HTTP on the internet works:

# curl -vv --proxy https://192.168.1.12:443 --proxy-insecure --insecure http://www.site.com/
*   Trying 192.168.1.12...
* TCP_NODELAY set
* Connected to 192.168.1.12 (192.168.1.12) port 443 (#0)
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Proxy certificate:
*  subject: C=US; ST=CA; O=Blue Coat Systems, Inc.; OU=Blue Coat SG-S200 Series; CN=xxx
*  start date: Jan  1 10:46:49 2020 GMT
*  expire date: Jan  1 10:46:49 2025 GMT
*  issuer: C=US; ST=California; L=Sunnyvale; O=Blue Coat Systems, Inc.; OU=Blue Coat, ABRCA; CN=abrca.bluecoat.com; emailAddress=sysadmin@bluecoat.com
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
> GET http://www.site.com/ HTTP/1.1
> Host: www.site.com
> User-Agent: curl/7.60.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Server: nginx/1.10.3
< Date: Wed, 29 Jan 2020 15:46:24 GMT
< Content-Type: text/html
< Content-Length: 226
< Last-Modified: Mon, 22 Sep 2014 17:55:21 GMT
< ETag: "e2-503ab2786f440"
< Accept-Ranges: bytes
< Vary: Accept-Encoding
< Proxy-Connection: Keep-Alive
< Connection: Keep-Alive
< Age: 0
<
<HTML>
<HEAD>
<TITLE>Welcome!</TITLE>

Accessing a site using HTTPS does NOT work, however I don’t understand why. It shouldn’t depend on the outer layer of the connection which has now become HTTPs instaead of HTTP…

# curl -vv --proxy https://192.168.1.12:443 --proxy-insecure --insecure https://www.site.com/
*   Trying 192.168.1.12...
* TCP_NODELAY set
* Connected to 192.168.1.12 (192.168.1.12) port 443 (#0)
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Proxy certificate:
*  subject: C=US; ST=CA; O=Blue Coat Systems, Inc.; OU=Blue Coat SG-S200 Series; CN=xxx
*  start date: Jan  1 10:46:49 2020 GMT
*  expire date: Jan  1 10:46:49 2025 GMT
*  issuer: C=US; ST=California; L=Sunnyvale; O=Blue Coat Systems, Inc.; OU=Blue Coat, ABRCA; CN=abrca.bluecoat.com; emailAddress=sysadmin@bluecoat.com
*  SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
* allocate connect buffer!
* Establish HTTP proxy tunnel to www.site.com:443
> CONNECT www.site.com:443 HTTP/1.1
> Host: www.site.com:443
> User-Agent: curl/7.60.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.site.com:443
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, Client hello (1):
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.site.com:443

The remote end shows this (no data is transmitted)

   98 16:47:41.913409959 1.1.1.1 → 2.2.2.2 TCP 74 53656 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1380 SACK_PERM=1 TSval=4144667785 TSecr=0 WS=64
   99 16:47:41.913463623 2.2.2.2 → 1.1.1.1 TCP 74 443 → 53656 [SYN, ACK] Seq=0 Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3089349285 TSecr=4144667785 WS=128
  100 16:47:41.925293814 1.1.1.1 → 2.2.2.2 TCP 66 53656 → 443 [ACK] Seq=1 Ack=1 Win=262848 Len=0 TSval=4144667797 TSecr=3089349285
  101 16:47:41.925490666 1.1.1.1 → 2.2.2.2 TCP 66 53656 → 443 [FIN, ACK] Seq=1 Ack=1 Win=262848 Len=0 TSval=4144667797 TSecr=3089349285
  102 16:47:41.925529264 2.2.2.2 → 1.1.1.1 TCP 66 443 → 53656 [FIN, ACK] Seq=1 Ack=2 Win=29056 Len=0 TSval=3089349288 TSecr=4144667797
  103 16:47:41.937479029 1.1.1.1 → 2.2.2.2 TCP 66 53656 → 443 [ACK] Seq=2 Ack=2 Win=262848 Len=0 TSval=4144667809 TSecr=3089349288

Proxy Policy trace is inconclusive:

connection: service.name=Explicit HTTPS client.address=192.168.2.226 proxy.port=443 client.interface=0:0.44 routing-domain=default
  location-id=0 access_type=unknown
time: 2020-01-29 15:19:07 UTC
CONNECT tcp://www.site.com:443/
  DNS lookup was unrestricted
User-Agent: curl/7.60.0
user: unauthenticated
authentication status='not_attempted' authorization status='not_attempted'
  url.category: none@Policy;none@Blue Coat
    total categorization time: 0
    static categorization time: 0
server.response.code: 0
client.response.code: 200
application.name: none
application.operation: none
application.group: none
DSCP client outbound: 65
DSCP server outbound: 65

What could be the problem?

Am I doing this correctly? Or is there a more correct approach to secure the connection toward the proxy itself?

Thanks,

Jim

0

Related:

  • No Related Posts

PVS Vdisk Inconsistency – Replication Status Shows Error ” Server Not Reachable” When NIC Teaming is Configured

  • Verify if NIC Teaming is configured as Active-Active. Reconfigure as Active-Passive.

Steps:

Open Network team configuration and make sure the team is Active Active.

Verify the NICs configured under Active Adaptors and confirm no Standby Adaptors are configured.

Reconfigure the Team and make sure Active and standby adaptors are configured.

Please note that NIC team configuration will differ for different adapter manufacturers, check the configuration guide to follow appropriate steps to reconfigure.

Reconfigure NIC teaming may interrupt the network connection. Please make sure to take proper actions to avoid production impact.


User-added image

  • Verify the MTU setting of NIC on all PVS servers

Since the status of the replication is synced via UDP on PVS port 6895, the communication failure over this udp port will also effects the status of the replications.

The different MTU of the NICs of PVS servers will also block this kind of UDP communication between them. For example, if one of the NIC has MTU of 1500(default) and the other NIC has MTU of 6000, the udp packets which is larger than 1500 will be lost due to the different fragmentation. From MTU of 6000, the udp packet larger than 1500 but less than 6000, so it will not be fragmented. But the peer has MTU of 1500, so it is unable to accepted this packet and causing packet loss.

You need to check the MTU value of all PVS servers by command:

netsh interface ipv4 show subinterface

If MTUs are different on all PVS servers, please change it to the same value (The default value 1500 is recommended):

netsh interface ipv4 set subinterface “ Ethernet ” mtu=1500 store=persistent

Please replace Ethernet with the NIC name of your PVS server.

Related:

  • No Related Posts

What are Hung Threads and why is the StreamProcess terminating?

Engage the Storage, Network and DBA teams to check the health of those system and resource availability

You can check TCP/IP connectivity to SQL Server by using telnet.

Note that SQL database does not grow slowly, but expands by a pre-configured amount. Inspect the Files property of the PVS database to find the location of the database file and the ‘Autogrowth/Maxsize’ value.

Confirm all the Anti Virus Exclusions are configured as per the following Citrix Article: https://support.citrix.com/article/CTX124185

Check if there’s a pattern to the occurrence of the Events in the Event Logs. For example if there are Hung Threads every night at the same time, check if there are Backup processes that might impact Storage Access or Maintenance procedures

To eliminate the possibility of issues with the Operating System, reboot the PVS Servers

If the issue persists, contact Citrix Support to capture diagnostic data and further narrow down the actual root cause of the issue.

Related:

  • No Related Posts