VPN über DSL: Citrix, Tastaturverzögerungen

[glady]

Hallo,

Kunden melden sporadisch Tastaturverzögerungen über ihre Citrixsessions. Die Umgebung sieht folgendermaßen aus:
In der Zentrale VPN-Router mit VPN-VTI-Konfiguration, 34Mbit Internetanschluss
Aussenstelle C876 mit VPN-VTI-Konfiguration, Internetanschluss theoretisch 6Mbit Download/660Kbit Upload, tatsächlich 2,7Mbit Download/395 Kbit Upload (sh dsl interface atm0).

Ich lasse einen Dauerping von der Zentrale auf das Router-Lan-Interface mit Timestamp laufen. Die Antwortzeiten sind gut. Mit FTP Down- und Upload zur Aussenstelle wird ca. 70-75% der tatsächlichen Bandbreite erreicht.

Hat jemand eine Idee woran die Tastaturverzögerungen im Citrix liegen könnte bzw. wie man die Routerkonfiguration tunen könnte?

Grüße
Glady

[glady]

Passt die Konfiguration?

version 12.4
service timestamps debug datetime localtime
service timestamps log datetime localtime
service password-encryption
!
hostname xxx
!
boot-start-marker
boot-end-marker
!
logging buffered 40000 debugging
enable secret xxx
!
no aaa new-model
!
resource policy
!
clock timezone MEZ 1
clock summer-time MESZ recurring last Sun Mar 1:00 last Sun Oct 2:00
no ip source-route
ip cef
!
!
!
!
ip tftp source-interface Loopback0
no ip domain lookup
ip host tftp xxx
!
!
isdn switch-type basic-net3
!
key chain key1
key 1
key-string xxx
!
!
username xxx password xxx
!
!
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 3600
crypto isakmp key xxx address xxx no-xauth
crypto isakmp key xxx address xxx no-xauth
crypto isakmp key xxx address xxx no-xauth
!
!
crypto ipsec transform-set 3dessha esp-3des esp-sha-hmac
!
crypto ipsec profile P-3dessha
set transform-set 3dessha
!
!
!
!
!
interface Tunnel10
bandwidth 2000
ip address xxx 255.255.255.252
delay 15
tunnel source Dialer1
tunnel destination xxx
tunnel mode ipsec ipv4
tunnel protection ipsec profile P-3dessha
!
interface Tunnel20
bandwidth 2000
ip address xxx 255.255.255.252
delay 10
tunnel source Dialer1
tunnel destination xxx
tunnel mode ipsec ipv4
tunnel protection ipsec profile P-3dessha
!
interface Loopback0
ip address xxx 255.255.255.255
!
interface BRI0
description backup
bandwidth 64
no ip address
encapsulation ppp
dialer pool-member 10
isdn switch-type basic-net3
isdn point-to-point-setup
ppp authentication chap
!
interface ATM0
no ip address
ip mtu 1492
no atm ilmi-keepalive
pvc 1/32
pppoe-client dial-pool-number 1
!
dsl operating-mode auto
!
interface FastEthernet0
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface Vlan1
ip address xxx 255.255.255.0
ip helper-address xxx
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 key1
ip tcp adjust-mss 1452
ip policy route-map Clear-DF
!
interface Dialer1
ip address negotiated
ip access-group internet_in in
ip mtu 1492
encapsulation ppp
dialer pool 1
dialer idle-timeout 0
dialer-group 1
no cdp enable
ppp authentication chap pap callin
ppp chap hostname xxx@qsc-tdsl.de
ppp chap password xxx
ppp pap sent-username xxx@qsc-tdsl.de password xxx
!
interface Dialer10
description eigene rufnummer xxx
bandwidth 64
ip address xxx 255.255.255.252
encapsulation ppp
dialer pool 10
dialer remote-name xxx
dialer idle-timeout 300
dialer string xxx
dialer caller xxx
dialer hold-queue 30
dialer-group 1
no cdp enable
ppp authentication chap
ppp multilink
!
router eigrp 1
passive-interface default
no passive-interface Vlan1
no passive-interface Tunnel10
no passive-interface Tunnel20
network xxx 0.0.0.0
network xxx 0.0.0.0
network xxx 0.0.0.0
network xxx 0.0.0.0
distribute-list route_list_in_allow in Tunnel10
distribute-list route_list_in_allow in Tunnel20
no auto-summary
!
ip route 0.0.0.0 0.0.0.0 Dialer1

[glady]

no ip http server
no ip http secure-server
!
ip access-list standard route_list_in_allow
remark default
permit xxx 0.0.3.255
permit xxx 0.0.0.255
permit xxx 0.0.7.255
permit xxx 0.0.255.255
!
ip access-list extended internet_in
permit icmp any any administratively-prohibited
permit icmp any any echo
permit icmp any any echo-reply
permit icmp any any packet-too-big
permit icmp any any time-exceeded
permit icmp any any traceroute
permit icmp any any unreachable
permit esp xxx 0.0.0.127 any
permit udp xxx 0.0.0.127 any eq isakmp
deny ip any any
ip access-list extended routemap-clear-df
permit ip xxx 0.0.255.255 any
permit ip any xxx 0.0.255.255
!
logging trap debugging
access-list 10 permit xxx 0.0.0.255
access-list 10 permit xxx 0.0.0.255
access-list 10 permit xxx 0.0.0.255
access-list 10 permit xxx 0.0.0.255
access-list 10 permit xxx 0.0.255.255
access-list 10 permit xxx 0.0.255.255
access-list 10 deny any log
access-list 120 deny udp any eq syslog any
access-list 120 deny udp any eq snmp any
access-list 120 deny udp any eq snmptrap any
access-list 120 deny udp any eq ntp any
access-list 120 deny udp any eq netbios-dgm any
access-list 120 deny udp any eq netbios-ns any
access-list 120 deny udp any eq netbios-ss any
access-list 120 deny udp any range snmp snmptrap any
access-list 120 deny udp any range bootps bootpc any
access-list 120 deny tcp any eq 137 any
access-list 120 deny tcp any eq 138 any
access-list 120 deny tcp any eq 139 any
access-list 120 permit ip any any
dialer-list 1 protocol ip list 120
snmp-server community xxx RO
no cdp run
!
!
!
route-map Clear-DF permit 10
match ip address routemap-clear-df
set ip df 0
!
!
control-plane
!
!
line con 0
password xxx
login
no modem enable
line aux 0
password xxx
login
line vty 0 4
access-class 10 in
exec-timeout 300 0
password xxx
login
!
scheduler max-task-time 5000
ntp clock-period 17179558
ntp source Loopback0
ntp server xxx
end

[Wordo]

Bei spontanen Verzoegerungen kann das z.B. mal ne dicke ausgehende Mail sein. Dafuer wuerde sich dann QoS anbieten (sofern es an ausgehenden Verbindungen liegt).

[glady]

Ausser Drucken, Citrix-Session und Ping geht nichts über die Leitung. Mail, usw. geht alles über die Citrix-Session.
Wie könnte QoS aussehen, um die Citrix-Sessions Vorrang gegenüber Drucken zu geben?

Habe eine neue Erkenntnis. Gegenüber einer FTP-Übertragung habe ich bei der Datenübertragung über die Windows-Freigabe 45% schlechtere Perfomance (Download) und 30% beim Upload. Woran liegt das? Vielleicht ist das auch der Grund für die Verzögerungen bei den Citrix-Sessions.

[mr._oiso]

Hi glady,

ich bin ja hoch erfreut zu sehen, dass andere auch mit solchen Tricks arbeiten.
Ich denke auf Grund dieser Konfiguration wusste da schon jemand welche Probleme Citrix
oder generell Terminal Server Anwendungen auf VPN/Wan Leitungen machen.
Ich befürchte in Deinem Fall eher ein "Fragmentation" Problem.
Allein die Tatsache, dass Du hier die route map Clear-DF bit integriert hast bedeutet,
dass eventuell jemand wusste das der Terminal Server das DF-Bit bei seinen ausgehenden Packeten zum Client gesetzt hat. Dieses ist in der Regel auch normal. Path-MTU-discovery ist standardmäßig unter Windows aktiv.
Jedoch gibt es ein White-Paper von Citrix, in der einiges über die richtige MTU-size nachzulesen ist. Nun kenn ich natürlich nicht die Serverumgebung, und weiß auch nicht ob der Citrix Server auf einem Windows Server System läuft.
Zusätzlich hast Du die IP Adressen aus der Config entfernt.
Sollte aber diese Liste:

ip access-list extended routemap-clear-df
permit ip xxx 0.0.255.255 any
permit ip any xxx 0.0.255.255

Deine Problemzone sein, so deutet alles darauf hin.
Eventuell bringt es schon etwas wenn Du mit
ip tcp adjust-mss an Vlan 1 den Wert weiter nach unten drückst.

Überprüfen solltest Du auf jeden Fall mal, wo die MTU Werte vom Server liegen, und ob
adjust-mss auch arbeitet.
Das bedeutet, der Server muss vom Router die Info bekommen (ICMP code 4)
Fragmentation Needed and DF Set !
Solche Informationen werden oft gerne von Firewall Systemen/Anwendungen verworfen.
Auch hier sehe ich in Deiner Config die notwendigen permit's
icmp any any packet-too-big
icmp any any unreachable

Auf jeden Fall sieht es wohl so aus, dass der Server die Bildinfo's nicht schnell genug rüber bringt (Packet zu groß, -> verworfen) (ist noch normal)
Tastaturverzögerung aus meiner sicht - Ich tippe ein "A" und sehe es erst sekunden später.
Das bedeutet eventuell, zu viele, zu große Packete = kein Path MTU discovery
Fragmentierungsfehler zwischen Server und Router.
Vieleicht hilft es auch einfach nur zu überlegen, was in der letzen Zeit am System geändert worden ist.
z.B. Citrix Patch, Firewall konfigurationen, etc.

Ich hoffe notwendige Anregungen zur Fehlerbehebung beitragen zu können.

greez

Mr.Oiso

[Wordo]

Hi Oiso! Schoen mal wieder von dir zu lesen

Wir arbeiten auch mit clear DF-bit Bei uns aber erst seit einer unserer Upstream Provider auf Juniper umgestellt hat, die machen da anscheinend ordentlich Zicken. Und QSC wird die Tage wohl auch nachziehen
Ich wuerd auch mal adjust-mss auf 1300 setzen, hm, und den MTU Wert auf ATM0 kannste auch rausnehmen.

[glady]

Danke für die ausführlichen Infos Mr. Oiso!

Ohne das DF-Bit haben sich die Citrix-Sessions und auch alles andere was mit Windows zu tun hat aufgehängt, eine Kommunikation war nicht möglich. Mit dem entzug des DF-Bits hatten wir diese Probleme nicht mehr. Später habe ich rausbekommen, dass man das DF-Bit auch im Windows in der Registry rauskriegt.
Wenn auf Server und Client Seite das entsprechende ICMP freigegeben ist, warum können die sich dann nicht trotzdem einigen?

>Überprüfen solltest Du auf jeden Fall mal, wo die MTU Werte vom Server liegen, und ob
adjust-mss auch arbeitet.

Wenn ich vom Client zum Server pinge mit den Optionen -f -l, dann kommt bei 1472 Bytes eine normale Antwort. Ab 1473 kommt dann die Meldung "Paket müsste fragmentiert werden". Was hat das nun auszusagen? Und wie prüfe ich, ob adjust-mss arbeitet?

@Wordo
Was meinst Du mit "Upstream Provider"? Und was wird QSC nachziehen?

Ich dachte das tcp adjust-mss muss man MTU-Size -40 setzen. Bei einer MTU-Size von 1492 wären das also tcp adjust-mss 1452

Danke für eure Antworten!

[Wordo]

Das war an Oiso gerichtet, das mit QSC ist fuer dich uninteressant. Fuer RDP Sessions z.B. wird ein Wert von 1300 empfohlen. Ich glaub das steht sogar in nem MS KnowledgeBase Artikel. Die ICMP Kommunikation von Client zu Server ist fuer das "Aushandeln" der MTU Werte nicht wichtig. Eher ICMP von Gateway zu Client. Uebrigens gilt adjust-mss nur fuer TCP Verbindungen, da bringt dir der ping mit "-l" nicht viel

[glady]

>Die ICMP Kommunikation von Client zu Server ist fuer das "Aushandeln" der MTU Werte nicht wichtig. Eher ICMP von Gateway zu Client

Wo muss ich dann in so einer Umgebung prüfen:
Server-MLS-Firewall-Firewall-VPN-Router1<-Internet->VPN-Router2-Client

Was ist beim DF-Bit lsöchen der Unterschied zu diesem Verfahren:
Cisco IOS Security Configuration Guide, Release 12.4 - DF Bit Override Functionality8 with IPSec Tunnels* [Cisco IOS Software Releases 12.4 Mainline] - Cisco Systems

Da steht folgender Hinweis:
Performance Impact
Because each packet is reassembled at the process level, a significant performance impact occurs at a high data rate. Two major caveats are as follows:
•The reassemble queue can fill up and force fragments to be dropped.
•The traffic is slower because of the process switching.

Was habt ihr für Erfahrungen?