This message was deleted.
# citrix-vad
s
This message was deleted.
d
Not sure about modern vpns but it used to be the case that the traffic was TCP only, so maybe the vpn is converting the udp to tcp for the tunnel, or maybe if its a purchased vpn maybe it's got alot of hops introduced. Maybe try a traceroute to the gateway with and without vpn see if that shows anything obvious.
j
@Shane Kleinert hrmmmm
j
Sounds like a possible MTU issue?
t
Is the ICA latency still that high when you disable EDT?
n
Nope, latency is always super low - even with EDT enabled. It's just when I activate my VPN that things go haywire. This isn't an issue I would expect a user to be in, I just happened to notice is because I activate/deactivate my VPN while in the middle of my session somewhat frequently to do a few things.
d
VPN will probably change your MTU size, this might lead to paket fragmentations. Afaik MTU discovery only kicks in during session launch.
✅ 1
n
In the middle of a tracert right now, which has no end in sight
Ended at 30 hops, with 20 timeouts, lol
t
My question was, what’s the latency with VPN activated and EDT (UDP) disabled. I assume it depends on the smaller MTU size because of the additional VPN header. MTU discovery won’t work in that case.
n
My latency is always under 30ms with the VPN activated and EDT disabled.
MTU for the adapter was around 1420, I believe.
t
Thanks, then it seems to be the smaller MTU size like @dready mentioned before. Can’t test it by myself but anyone else here able to verify this behaviour?
n
Changing the MTU size doesn't appear to change the behavior. One thing I found interesting is that I could still see my Citrix desktop in real-time - Teams messages would pop up, I'd see Outlook notifications - but I couldn't interact with the desktop for a good 30-40 seconds.
j
I reckon you're losing a lot of UDP packets, which will increase the latency, interactions, etc. Where did you change the MTU?
n
Directly in the Wireguard config. Tried a few settings, based on some posts I found online. Like I said, though, not a huge deal as this is only something I've noticed and nobody else.
j
For EDT I set these to 1338 in Storefront default.ica as per https://support.citrix.com/article/CTX231821. After managing many incidents and problem records, this is how low I needed to go to get EDT reliable using Cisco AnyConnect VPN for users that connect using 4G and 5G from regional areas around Australia. No issue at all if I disable EDT. I would just troubleshoot live with users getting them to ping a reachable host using the -f and -l parameters. Start the -l at 1472, and keep lowering until you get a reply. Then set the default.ica to that and they can test it on the fly. Not exactly great change management, but sometimes this is the best way to sort out issues like this. Anyway, this may or may not be helpful.
r
While we are on the topic, In the newer builds and more importantly the new LTSR 2203. The term adaptive audio is something that seems to better. But in this blogs, it's saying "HDX Adaptive Transport= Off (This setting will avoid EDT to use UDP transport and reserve UDP DTLS transport to be used by UDP Audio.)" Trying to understand what they mean. https://www.citrix.com/blogs/2022/03/23/next-gen-hdx-multimedia-audio-redirection-a-difference-you-can-hear/
n
Good question, because that line is confusing.
r
Yea for sure, Then I went and read the Docs here. "If Audio over UDP Real-time Transport is not required for adaptive audio, Citrix recommends configuring the policy setting to Disabled. This helps avoid Citrix Workspace app clients requesting open UDP connections or triggering unwanted Citrix Workspace app client firewall configuration dialog windows to appear." So, being the EDT is UDP based. Then all the parts are setup ofver 16500-16509. Do we still need the Adaptive audio? Or is EDT doing this? Or are they used together? I have no idea yet. https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/multimedia/audio.html#audio-over-udp-real-time-transport-and-audio-udp-port-range
One more things to add. I just seen this "By default, Audio over User Datagram Protocol (UDP) Real-time Transport is allowed (when selected at the time of installation). It opens up a UDP port on the server for connections that use Audio over UDP Real-time Transport. If there is network congestion or packet loss, we recommend configuring UDP/RTP for audio to ensure the best possible user experience. For any real time audio such as softphone applications, UDP audio is preferred to EDT. UDP allows for packet loss without retransmission, ensuring that no latency is added on connections with high packet loss" This seems perhaps the Adaptive Audio is used over the EDT side? confusing for sure.
Didn't meant to hijack the thread either.
n
Nope, that's right up my alley with this. I just e-mailed my account rep to see if he can clarify.
It definitely sounds like it's either EDT or UDP adaptive audio, not both.
Which just seems wrong.
r
Yea, it does seem way wrong
Let me know what you find out please.
n
Will do. Same if you get a reply on that blog.
r
For sure man. Will do
n
"I see somebody named Ray already asked that question, so let's see what the PM says"
lol, no. Just ask somebody. You work for Citrix.
r
Geez man, If I worked for Citrix I would find out ASAP lol
a
What I found out is that you have to set a specific reg-key to activate UDP MTU discovery with 1912CU3(+?) Should find in in edocs, dont remember at the moment. Did you also enable UDP MTU discovery in ADC?