This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Citrix Problem with RED connection.

Hello

we are using several REDs in Bridge mode on a SG 330. The SG330 is in the DMZ which is guarded by an XG 550 and handling SSL/VPN and all Mailtraffic and Reverse Proxies.

Some dayss everything is working as expected. On some days we are not able to start a citrix session on a location that is connected via the red devices. When troubleshooting this with a client with wireshark installed I see UDP packets from the client to the Citrix Application Server and from the Citrix Server Application to the client. However there is no session established (this is preceded by a communication with the cirtrix portal wich obviously works because the client is connected with the application server).

The Citrix infrastructure is working properly as SSL/VPN and LAN Connection can connect to the citrix server without any issues.

What could be the reason? Any ideas how to fix this?



This thread was automatically locked due to age.
  • 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:

    U:\>ping -l 1365 wupfile.riedel.net -f
     
    Ping wird ausgeführt für wupfile.riedel.net [172.21.9.34] mit 1365 Bytes Daten:
    Antwort von 172.21.9.34: Bytes=1365 Zeit=25ms TTL=126
    Antwort von 172.21.9.34: Bytes=1365 Zeit=22ms TTL=126
    Antwort von 172.21.9.34: Bytes=1365 Zeit=21ms TTL=126
     
    Ping-Statistik für 172.21.9.34:
        Pakete: Gesendet = 3, Empfangen = 3, Verloren = 0
        (0% Verlust),
    Ca. Zeitangaben in Millisek.:
        Minimum = 21ms, Maximum = 25ms, Mittelwert = 22ms

    U:\>ping -l 1366 wupfile.riedel.net -f
     
    Ping wird ausgeführt für wupfile.riedel.net [172.21.9.34] mit 1366 Bytes Daten:
    Zeitüberschreitung der Anforderung.
    Zeitüberschreitung der Anforderung.
     
    Ping-Statistik für 172.21.9.34:
        Pakete: Gesendet = 2, Empfangen = 0, Verloren = 2
        (100% Verlust),

    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.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 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.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.