Jump to content
Welcome to our new Citrix community!

Is DTLS used by the VPN?


Rowen Gunn

Recommended Posts

What is the use case scenario here?

 

DTLS  is for high definition in-session user experience of virtual desktops and applications for users running Citrix Receiver. 

The endpoint must have a minimum Citrix Receiver for Windows 4.3.100 or Citrix Receiver for iOS 6.0.1. It is driven by receiver.

When you mentioned that "support recommends we have DTLS on, and sometimes of" , can you please DM case number.

 

Link to comment
Share on other sites

1 minute ago, Ananta Thakur said:

What is the use case scenario here?

 

DTLS  is for high definition in-session user experience of virtual desktops and applications for users running Citrix Receiver. 

The endpoint must have a minimum Citrix Receiver for Windows 4.3.100 or Citrix Receiver for iOS 6.0.1. It is driven by receiver.

When you mentioned that "support recommends we have DTLS on, and sometimes of" , can you please DM case number.

 

 

The use case is the VPN, which is the VPN client and EPA scanner, no Receiver involved. However in my support case for a weird Win10 VPN login issue the support engineers found in the VPN client logs a step where it attempts to use DTLS. This caused a back and forth about if DTLS is even used for the VPN and no one seems to know... I thought it was an ICA gateway only feature.

Link to comment
Share on other sites

6 minutes ago, Vamsi Krishna Kanduri said:

DTLS is not used by SSLVPN.

Do you have any packet capture when DTLS is used?

Stop check would be during EPA Scan and VPN Establish 

 

Thanks,

Vamsi

 

These are two snippets from nssslvpn.txt - a VPN Client log, notice is says there was a DTLS mux data error. This implies the VPN Client is somehow attempting to use DTLS to do... something...

 

07:32:57.581 | VERBOSE | 005E7CB8 | port=60091 receive data (len=181/3133) from svr
07:32:57.581 | DEBUG   | 005E7CB8 | ptobesent=0x2ae2288 ltobesent=134 ptobedecode=0x2ae230e ltobedecode=0
07:32:57.581 | DEBUG   | HttpParser::ParseHttpBody called
07:32:57.581 | VERBOSE | HTTP header found, contentLen=0 hdrLen=134 processed=134
07:32:57.581 | VERBOSE | [<HTTP/1.1 200 OK

TunnelType:nocmp

Content-Length: 0

Cache-control: no-cache, no-store

Pragma: no-cache

Content-Type: text/html

>]
07:32:57.581 | DEBUG   | pccb->svr.ltobesent=0
07:32:57.799 | EVENT   | Error while rec. DTLS mux data.
07:32:57.799 | DEBUG   | 005E7DD8 | SSL_ClientHandshakeLoop: scRet=80090318
07:32:57.799 | DEBUG   | 005E7DD8 | pccb->clt.ltobesent=0
07:32:58.022 | DEBUG   | RedrawActiveXWnd: 2:0
07:32:58.022 | DEBUG   | Calling Shell_NotifyIcon
07:32:58.022 | DEBUG   | Shell_NotifyIcon succeeded
07:32:58.022 | EVENT   | Connection established.
To end this session, right-click the NetScaler Gateway Plug-in icon and click Logoff.07:32:58.022 | DEBUG   | m_Notifier[0]
07:32:58.022 | DEBUG   | Calling Shell_NotifyIcon
07:32:58.022 | DEBUG   | Shell_NotifyIcon succeeded
07:32:58.022 | DEBUG   | ns_BackupFirefoxCookieFiles called

 

07:32:58.022 | EVENT   | The NetScaler Gateway is ready
07:32:58.038 | DEBUG   | syspath=C:\Users\rogunn.admin\AppData\Local
07:32:58.038 | DEBUG   | ns_start_vpn returned 1
07:32:58.038 | DEBUG   | dologin: ns_start_vpn returns 1
07:32:58.304 | EVENT   | Error while rec. DTLS mux data.
07:32:58.304 | DEBUG   | 005E7DD8 | SSL_ClientHandshakeLoop: scRet=80090318
07:32:58.304 | DEBUG   | 005E7DD8 | pccb->clt.ltobesent=0
07:32:58.804 | EVENT   | Error while rec. DTLS mux data.
07:32:58.804 | DEBUG   | 005E7DD8 | SSL_ClientHandshakeLoop: scRet=80090318
07:32:58.804 | DEBUG   | 005E7DD8 | pccb->clt.ltobesent=0
07:32:59.304 | EVENT   | Error while rec. DTLS mux data.
07:32:59.304 | DEBUG   | Didn't receive proper response from Vserver. Most probably, DTLS tunnel is not supported. Terminating DTLS creation

07:32:59.304 | VERBOSE | Closing client socket on port:0
07:32:59.304 | EVENT   | Secure Access Client closed one connection [type: 0].

  • Like 1
Link to comment
Share on other sites

So the official answer is that DTLS is not used by the SSLVPN, but the SSLVPN client logs talk about not being able to use DTLS. So the SSLVPN client which doesn't use DTLS in any way is making log entries in it's own logs about not being able to access DTLS.

 

So if it doesn't use it why do the SSLVPN logs refer to DTLS over and over, and then make DEBUG log entries complaining that DTLS is not working?

  • Like 1
Link to comment
Share on other sites

  • 3 months later...

So after testing this, I found the SSLVPN DOES use DTLS. If you enable DTLS on your SSLVPN gateway you need to unbind and rebind the SSL cert as well. Once you do that in the client logs you'll see the following items showing up in the VPN client debug logs:

 

11:21:00.464 | DEBUG   | SSL Handshake Succeed
11:21:00.464 | DEBUG   | DTLS Handshake finished.
11:21:00.464 | DEBUG   | SSL_EncryptData: cbHeader=29, cbTrailer=36, cbMaximumMessage=1096
11:21:00.464 | DEBUG   | 005E9DD8 | pccb->clt.ptobesent=0x2ab3328, pccb->clt.ltobesent=85
11:21:00.464 | DEBUG   | 005E9DD8 | EncryptMessage (len=141)

 

11:21:01.425 | DEBUG   | SSL_EncryptData: cbHeader=29, cbTrailer=36, cbMaximumMessage=1096
11:21:01.425 | DEBUG   | 005E9DD8 | pccb->clt.ptobesent=0x2b99f38, pccb->clt.ltobesent=119
11:21:01.425 | DEBUG   | 005E9DD8 | EncryptMessage (len=173)
11:21:01.425 | DEBUG   | Sending UDP over DTLS len 119
11:21:01.471 | DEBUG   | ns_init_svrbuf get new buffer
11:21:01.471 | VERBOSE | 005EA018 | port=56978 receive data (len=163/300) from svr
11:21:01.471 | DEBUG   | 005EA018 | ptobesent=0x2ab3308 ltobesent=134 ptobedecode=0x2ab338e ltobedecode=0
11:21:01.471 | DEBUG   | HttpParser::ParseHttpBody called
11:21:01.471 | VERBOSE | HTTP header found, contentLen=0 hdrLen=134 processed=134
11:21:01.471 | VERBOSE | [<HTTP/1.1 200 OK

  • Like 1
Link to comment
Share on other sites

  • 7 months later...

Quick update here since literally every Citrix support person I talked to has no idea if DTLS is used on the SSLVPN.

 

YES DTLS IS USED IF ACTIVATED ON THE SSLVPN GATEWAY. If you turn it on also enabled UDP 443 traffic to your VPN gateway from external internet and you will see DTLS traffic on the VPN gateway. It seems to improve performance overall however don't turn it on for VPN unless you're on 12.0-58 or higher as the previous versions have a memory leak issue with DTLS and SSLVPN.

  • Like 1
Link to comment
Share on other sites

  • 4 months later...
17 hours ago, Reinier Sanchez1709155063 said:

DTLS is used by Citrix VPN plug-in when needed to route audio traffic over the VPN tunnel. Audio is more sensitive to latency, DTLS will encrypt UDP/443 traffic. In a network trace you would see protocol DTLSv1.0 when DTLS is used.

 

DTLS is used the entire time during the VPN session, the VPN logs clearly show that. My users rarely have audio calls over our SSL VPN and DTLS is active the entire time, in fact the VPN seems to send it's DNS requests over UDP with DTLS is active.

 

Set your VPN client to debug mode, you will see the DTLS log entries there and it's used for MUCH more than just "audio." We've now seen three radically different responses from Citrix employees on this matter and none of them seem to match what the VPN client itself says it's doing.

  • Like 1
Link to comment
Share on other sites

2 minutes ago, Reinier Sanchez1709155063 said:

Here you can find detailed information regarding Citrix DTLS Support

 

Support for DTLSv1.0 protocol

https://docs.citrix.com/en-us/citrix-adc/12-1/ssl/support-for-dtls-protocol.html

 

I've read the link, it mentions audio once on the entire page. The Netscaler has no insight into say Lync or Skype audio packets because they are wrapped in SSL encryption. It's up to the application itself on the VPN to determine if it will use UDP or TCP for audio, the Netscaler doesn't and can't make that choice for an application running on the VPN because it can't see inside the packets of data once encrypted.

 

If this was an ICA gateway then yes 100%, DTLS is used for audio. It's also used for Framehawk which isn't audio at all, the page doesn't mention that at all but FrameHawk which is just video can't work without DTLS.

 

It seems like Citrix themselves have some confusion on what DTLS is and what uses it. Despite the multiple Citrix employees saying different things in this thread... I've worked on a Netscaler based SSL VPN for years now, DTLS is used by the VPN and it's used for much more than audio. Citrix's VPN client debug logs make that very clear and perhaps the employees posting quick canned responses or responding to dead threads should really look at those logs before posting conflicting data.

Link to comment
Share on other sites

  • 2 weeks later...

I too noticed that the Gateway Plugin some time ago would utilize 443/udp instead of 443/tcp if the ADC Gateway had DTLS enabled. Since it does not appear that the Gateway plugin will automatically switch from TCP to UDP and back to TCP like ICA with EDT based on environmental conditions and this appears to be an all or nothing. I am interested in recommendations on if and when DTLS should be used as the transport for a full SSL VPN deployment. I have heard conflicting information around latency and packet loss conditions.

Link to comment
Share on other sites

12 minutes ago, Shawn Ragsdale1709154330 said:

I too noticed that the Gateway Plugin some time ago would utilize 443/udp instead of 443/tcp if the ADC Gateway had DTLS enabled. Since it does not appear that the Gateway plugin will automatically switch from TCP to UDP and back to TCP like ICA with EDT based on environmental conditions and this appears to be an all or nothing. I am interested in recommendations on if and when DTLS should be used as the transport for a full SSL VPN deployment. I have heard conflicting information around latency and packet loss conditions.

 

We've had DTLS enabled for our VPN for about a year now, no issues so far and I actually work remotely full time for the company I support. I did need to make some TCP profile changes to get the full speed out of the VPN, the default recommendations for TCP settings barely used 10% of our test case available bandwidth. We also have a VPX 1000 Netscaler and the VPX needed some tuning to really get the best performance out of it.

 

Use the TCP recommendation posted here: https://support.citrix.com/article/CTX232321

Then increase the buffer size to 4096000, Max Burst Limit of 20, Disable Dynamic Receive Buffering, & Enable Cubic Hystart worked well for us and our users

Link to comment
Share on other sites

  • 5 months later...
On 4/4/2019 at 9:31 AM, Rowen Gunn said:

 

We've had DTLS enabled for our VPN for about a year now, no issues so far and I actually work remotely full time for the company I support. I did need to make some TCP profile changes to get the full speed out of the VPN, the default recommendations for TCP settings barely used 10% of our test case available bandwidth. We also have a VPX 1000 Netscaler and the VPX needed some tuning to really get the best performance out of it.

 

Use the TCP recommendation posted here: https://support.citrix.com/article/CTX232321

Then increase the buffer size to 4096000, Max Burst Limit of 20, Disable Dynamic Receive Buffering, & Enable Cubic Hystart worked well for us and our users

 

Link to comment
Share on other sites

sh tcpParam

sh tcpProfile nstcp_default_profile

 

These commands will how same values and the default profiles are the same on any given Netscaler version. But remember DTLS uses UDP not TCP ;) there will be not much impact tweaking the TCP options.

 

Although, for app streaming through the gateway Citrix recommend the build-in tcp profile :: nstcp_default_XA_XD_profile

 

Link to comment
Share on other sites

On 3/22/2019 at 10:33 AM, Rowen Gunn said:

 

I've read the link, it mentions audio once on the entire page. The Netscaler has no insight into say Lync or Skype audio packets because they are wrapped in SSL encryption. It's up to the application itself on the VPN to determine if it will use UDP or TCP for audio, the Netscaler doesn't and can't make that choice for an application running on the VPN because it can't see inside the packets of data once encrypted.

 

If this was an ICA gateway then yes 100%, DTLS is used for audio. It's also used for Framehawk which isn't audio at all, the page doesn't mention that at all but FrameHawk which is just video can't work without DTLS.

 

It seems like Citrix themselves have some confusion on what DTLS is and what uses it. Despite the multiple Citrix employees saying different things in this thread... I've worked on a Netscaler based SSL VPN for years now, DTLS is used by the VPN and it's used for much more than audio. Citrix's VPN client debug logs make that very clear and perhaps the employees posting quick canned responses or responding to dead threads should really look at those logs before posting conflicting data.

VPN plug-in will use DTLS to stream audio traffic when ever is possible and available in the VPN channel between client and Netscaler gateway.

Link to comment
Share on other sites

8 hours ago, Reinier Sanchez1709155063 said:

sh tcpParam

sh tcpProfile nstcp_default_profile

 

These commands will how same values and the default profiles are the same on any given Netscaler version. But remember DTLS uses UDP not TCP ;) there will be not much impact tweaking the TCP options.

 

Although, for app streaming through the gateway Citrix recommend the build-in tcp profile :: nstcp_default_XA_XD_profile

 

Reinier,

 

Rgunn688 was only providing TCP recommendations from the CTX article and his own performance analysis.  I would like to compare his final TCP settings to what I have configured.  He did not indicate that he changed anything in the DTLS profile

 

The tcpParam and tcpProfile nstcp_default_profile are NOT exactly the same and have differences.

 

To show the DTLS profiles settings:  "sh dtlsProfile nsdtls_default_profile"

 

Also, the Gateway will only use the default HTTP profile no matter what you have set in most versions/builds. It is a know issue that has an enhancement already submitted.

Edited by sragsda714
Added additional information for clarification
Link to comment
Share on other sites

On 3/21/2019 at 2:56 PM, Reinier Sanchez1709155063 said:

DTLS is used by Citrix VPN plug-in when needed for example: audio traffic over the VPN tunnel. Audio is more sensitive to latency, DTLS will encrypt UDP/443 traffic. In a network trace you would see protocol DTLSv1.0 when DTLS is used.

 

> sh tcpparam
        TCP Parameters

        Window Scaling status: ENABLED
        Window Scaling factor: 8
        Selective Acknowledgement(SACK) status: ENABLED
        Learn Maximum Segment Size(MSS) for VServer: ENABLED
        Maximum number of TCP segments in a burst: 6 MSS
        Initial congestion window(cwnd) setting: 10 MSS
        TCP Delayed-ACK Timer: 100 millisec
        Down Service Reset status: DISABLED
        Nagle's Algorithm: DISABLED
        Limited Persist Probes: ENABLED
        Maximum out-of-order packets to queue: 300
        Immediate ACK on PUSH packet: ENABLED
        Maximum packets per MSS: 0
        Maximum packets per retransmission: 1
        TCP minimum Retransmission Timeout(RTO) in millisec: 600
        TCP Slow start increment: 2
        Maximum number of server probes allowed in 10ms: 7
        Max threshold after which server probes are reduced: 1024
        Maximum number of SYN allowed to be queued per probe PCB: 128
        Maximum number of SYN that can be held: 16384
        Vserver Maximum Segment Size(MSS) learning interval (in seconds): 180
        Vserver Maximum Segment Size(MSS) learning delay (in seconds): 3600
        Max connection limit for FIN TIME WAIT: 7000
        Max limit for syn+ack retransmissions in a interval: 100
        Syn attack detection enable/disable: ENABLED
        Connection flush on memory failure: NONE
        Connection flush threshold: (not set)
        Multipath TCP(MPTCP) checksum: ENABLED
        MPTCP subflow timeout: 0 sec
        MPTCP maximum established subflows per MPTCP Session: 4
        MPTCP maximum pending subflows per MPTCP Session: 4
        MPTCP maximum pending join subflows: 0
        MPTCP RTO count to Switch to other subflow: 2
        MPTCP Use Backup Subflow on Data Sequence Signal(DSS): ENABLED
        MPTCP subflow replace timeout: 10 sec
        MPTCP Accept DATA_FIN/FAST_CLOSE on passive subflow: ENABLED
        MPTCP Allow Subflows to close immediately on FIN: DISABLED
        MPTCP Close mptcp connection on closing last subflow: DISABLED
        Maximum number of retries after which free the connection: 7
        TCP Fast Open Cookie Timeout: 0
        Auto SYNcookie timeout (in seconds): 30

 

> sh tcpProfile nstcp_default_profile
        Name: nstcp_default_profile
        Window Scaling status: ENABLED
        Window Scaling factor: 8
        Selective Acknowledgement(SACK) status: ENABLED
        Maximum Segment Size(MSS): 1460
        Maximum TCP segments allowed in a burst: 6 MSS
        Initial congestion window(cwnd) setting   : 10 MSS
        TCP Delayed-ACK Timer: 100 millisec
        Nagle's Algorithm: DISABLED
        Maximum out-of-order packets to queue: 300
        Immediate ACK on PUSH packet: ENABLED
        Maximum packets per MSS: 0
        Maximum packets per retransmission: 1
        TCP minimum Restransmission Timeout(RTO) in millisec: 600
        TCP Slow start increment: 2
        TCP Buffer Size: 600000 bytes
        TCP Send Buffer Size: 600000 bytes
        TCP Syncookie: ENABLED
        Update Last activity on KA Probes: ENABLED
        TCP flavor: BIC
        TCP Dynamic Receive Buffering: DISABLED
        Keep-alive probes: DISABLED
        Connection idle time before starting keep-alive probes: 900 seconds
        Keep-alive probe interval: 75 seconds
        Maximum keep-alive probes to be missed before dropping connection: 3
        Establishing Client Connection: AUTOMATIC
        TCP Segmentation Offload: AUTOMATIC
        TCP Timestamp Option: DISABLED
        RST window attenuation (spoof protection): DISABLED
        Accept RST with last acknowledged sequence number: ENABLED
        SYN spoof protection: DISABLED
        TCP Explicit Congestion Notification(ECN): DISABLED
        Multipath TCP: DISABLED
        Multipath TCP drop data on pre-established subflow: DISABLED
        Multipath TCP fastopen: DISABLED
        Multipath TCP session timeout: 0 seconds
        Duplicate Selective Acknowledgement(DSACK): ENABLED
        ACK Aggregation: DISABLED
        Forward RTO recovery(FRTO): ENABLED
        TCP Max congestion window(CWND): 524288 bytes
        TCP Forward Acknowledgment(FACK): ENABLED
        TCP Optimization mode : TRANSPARENT
        TCP Fastopen: DISABLED
        TCP Fastopen Cookie Size: 8 bytes
        TCP Hybrid Start(HYSTART): DISABLED
        TCP dupack threshold: 3
        Burst Rate Control: DISABLED
        TCP Rate: 0
        TCP Rate Maximum Queue: 0
        Silently Drop HalfClosed connections on idle timeout: DISABLED
        Silently Drop Established connections on idle timeout: DISABLED
        Apply adaptive TCP optimizations: DISABLED
        Reference count: 1247

 

> sh tcpprofile TCP-Profile-PRD-Performance
        Name: TCP-Profile-PRD-Performance
        Window Scaling status: ENABLED
        Window Scaling factor: 8
        Selective Acknowledgement(SACK) status: ENABLED
        Maximum Segment Size(MSS): 1460
        Maximum TCP segments allowed in a burst: 30 MSS
        Initial congestion window(cwnd) setting   : 4 MSS
        TCP Delayed-ACK Timer: 100 millisec
        Nagle's Algorithm: DISABLED
        Maximum out-of-order packets to queue: 64
        Immediate ACK on PUSH packet: ENABLED
        Maximum packets per MSS: 0
        Maximum packets per retransmission: 1
        TCP minimum Restransmission Timeout(RTO) in millisec: 600
        TCP Slow start increment: 2
        TCP Buffer Size: 4000000 bytes
        TCP Send Buffer Size: 4000000 bytes
        TCP Syncookie: ENABLED
        Update Last activity on KA Probes: ENABLED
        TCP flavor: BIC
        TCP Dynamic Receive Buffering: DISABLED
        Keep-alive probes: DISABLED
        Connection idle time before starting keep-alive probes: 900 seconds
        Keep-alive probe interval: 75 seconds
        Maximum keep-alive probes to be missed before dropping connection: 3
        Establishing Client Connection: AUTOMATIC
        TCP Segmentation Offload: AUTOMATIC
        TCP Timestamp Option: DISABLED
        RST window attenuation (spoof protection): DISABLED
        Accept RST with last acknowledged sequence number: ENABLED
        SYN spoof protection: ENABLED
        TCP Explicit Congestion Notification(ECN): ENABLED
        Multipath TCP: DISABLED
        Multipath TCP drop data on pre-established subflow: DISABLED
        Multipath TCP fastopen: DISABLED
        Multipath TCP session timeout: 0 seconds
        Duplicate Selective Acknowledgement(DSACK): ENABLED
        ACK Aggregation: DISABLED
        Forward RTO recovery(FRTO): ENABLED
        TCP Max congestion window(CWND): 524288 bytes
        TCP Forward Acknowledgment(FACK): ENABLED
        TCP Optimization mode : TRANSPARENT
        TCP Fastopen: DISABLED
        TCP Fastopen Cookie Size: 8 bytes
        TCP Hybrid Start(HYSTART): ENABLED
        TCP dupack threshold: 3
        Burst Rate Control: DISABLED
        TCP Rate: 0
        TCP Rate Maximum Queue: 0
        Silently Drop HalfClosed connections on idle timeout: DISABLED
        Silently Drop Established connections on idle timeout: DISABLED
        Apply adaptive TCP optimizations: DISABLED
        Reference count: 8498

 

 

These are our current settings, everything seems to be running smoothly but I do see mixed results. Some ISPs can get up to 20Mpbs downloads on the VPN, some get 5 Mbps. If you change the TCP buffer size you can increase the download speed sometimes but it's ISP related.

 

Overall, I got really tired of constantly tweaking these settings. You can get the VPN to run as fast as sitting onsite with some TCP settings for FIOS users, but then Comcast users are slow. ETC ETC. One thing I can tell you is that the default TCP settings are "safe" but SLOW. Good luck!

 

Link to comment
Share on other sites

  • 2 years later...

This thread is very help full. I agreed with Rowen Gun that sometime Citrix Support still does not know these info.(need to be the escalation engineer level above)

So summary.

 

Type 1: Citrix gateway Way VIP ICA proxy for Citrix Virtual Apps and Desktops

-DTLS is use for EDT, Audio, Frame hawk, etc..

 

Type 2: Citrix gateway VIP for normal SSL VPN

-DTLS helps for Softphone Voice Application over SSL VPN tunnel. (Avaya OneX, etc.) 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...