Citrix Problem with RED connection.

Hi,

are you using the traditional TCP or the newer UDP with Citrix? It’s not long ago Citrix introduced EDT over UDP. Till now this would be my guess, that there is a problem with IDP for example.

Which version and components of Citrix are you using?

Best regards 

Alex 

Hi Alex,

the packets that are flowing between the Citrix Application Server and the Clients are UDP. I'd not have been suprised if I saw only packets in the direction of client to server but I also see packets from the server to the client. What is also strange that one day it is working and one day not so I still assume that some parameters need to be tweaked to get it running. I am not 100% sure but I think either all of the REDs are working or none of them. The REDs are in bridge Mode an use the same subnet.

I am aware of the change but UDP has some advantages over TCP especially when you have high latency. Our farest location is Sydney with 330ms. They are connected with IPSec tunnel and everything is working.

We are using RED devices for some very small location 2-3 people mostly in Europe and some Homeoffices mostly in Germany. 

Best regards,
Bernd

Hi Bernd,

I assume you are using Citrix Virtual Apps and Desktops, so connection is going to Storefront?

The advantage of UDP for latency reasons is known to me, I just wanted to be sure your problems aren’t founded in that change.

And to be sure the problems are caused by settings related to UTM, you have to be sure that there isn’t any chance these problems are Citrix related. Beconing and so on can play a role for example.

You didn’t tell us how your REDs operate and some information about server and client placement. Are the in the same network, firewall rules and so on. Otherwise the cause can’t be determined.

Best regards 

Alex 

Yes the connection is going through storefront.

Citrix is working well in all other constellations. For the RED connections UDP seems to be the problem. AFIK TCP is working well.

The Citrix environment is in an separate /24 network. The servers are reachable from the RED network. I see no issues from the LAN, IPSec and SSL Connection. The RED boxes are bridged to a single /24 network. All RED clients are in the same network. 

The endpoint for the RED is a Sophos SG in the DMZ. The firewall that establishes the DMZ is a sophos XG which has appropriate rules. Same constellation as with SSLVPN (which is working with citrix).

There is some strange behaviour regarding ping through:

Compared to the SSLVPN (which is working) I see:

U:\>ping citrix.riedel.net -l 1472 -f

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1472 Bytes Daten:
Antwort von 172.21.10.201: Bytes=1472 Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=10ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=4ms TTL=253

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 10ms, Mittelwert = 6ms

 

U:\>ping citrix.riedel.net -l 1473 -f

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

 

U:\>ping citrix.riedel.net -l 1473

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1473 Bytes Daten:
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=9ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=13ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=11ms TTL=253

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 13ms, Mittelwert = 9ms

The problem is in my opinion that large Packets are not going through and resend until some client timeout is reached



With smaller packets I see traffic going back and forth.



I already reduced the MTU on the RED from 1500 to 1350 which did not help.

Yes the connection is going through storefront.

Citrix is working well in all other constellations. For the RED connections UDP seems to be the problem. AFIK TCP is working well.

The Citrix environment is in an separate /24 network. The servers are reachable from the RED network. I see no issues from the LAN, IPSec and SSL Connection. The RED boxes are bridged to a single /24 network. All RED clients are in the same network. 

The endpoint for the RED is a Sophos SG in the DMZ. The firewall that establishes the DMZ is a sophos XG which has appropriate rules. Same constellation as with SSLVPN (which is working with citrix).

There is some strange behaviour regarding ping through:

Compared to the SSLVPN (which is working) I see:

U:\>ping citrix.riedel.net -l 1472 -f

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1472 Bytes Daten:
Antwort von 172.21.10.201: Bytes=1472 Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=10ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 Zeit=4ms TTL=253

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 4ms, Maximum = 10ms, Mittelwert = 6ms

 

U:\>ping citrix.riedel.net -l 1473 -f

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

 

U:\>ping citrix.riedel.net -l 1473

 

Ping wird ausgeführt für citrix.riedel.net [172.21.10.201] mit 1473 Bytes Daten:
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=6ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=9ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=13ms TTL=253
Antwort von 172.21.10.201: Bytes=1472 (gesendet 1473) Zeit=11ms TTL=253

 

Ping-Statistik für 172.21.10.201:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 13ms, Mittelwert = 9ms

The problem is in my opinion that large Packets are not going through and resend until some client timeout is reached



With smaller packets I see traffic going back and forth.



I already reduced the MTU on the RED from 1500 to 1350 which did not help.

The "location that is connected via the red devices" uses ethernet with IPS or are there some kind of DSL?

You can tra to reduce the MTU at the Citrix-Server.

Not the best, but most the simplest solution with MTU-Problems.

dirkkotte said:

The "location that is connected via the red devices" uses ethernet with IPS or are there some kind of DSL?

You can tra to reduce the MTU at the Citrix-Server.

Not the best, but most the simplest solution with MTU-Problems.

 

Yes. The remote location is using DSL.

How am I reducing the MTU on the citrix server? Changing the UDP Packtet size?

no,

you have to change the MTU at the server-interface.

There are some options ...

- setmtu.exe (from Cisco VPN-Client)

- netsh.exe:

https://social.technet.microsoft.com/Forums/en-US/08f3d442-3163-488d-b899-915cec25da5b/mtu-and-change-connections-mtu-limit?forum=w7itpronetworking

1. Type “netsh interface ipv4 show subinterface”.
2. Press Enter.
3. You will see a list of network interfaces.
4. Type “netsh interface ipv4 set subinterface `Local Area Connection` mtu=1300 store=persistent”.
   You should replace Local Area Connection with the name that appeared in the “Interface” column from steps 1-3.
5. Press Enter.
6. Type “netsh interface ipv4 show subinterface” to check the result.