Phase 2 scheitert mit AVC - aber nur bei UMTS

[tbc233]

Hallo,

Wir man meinen anderen Posts in diesem Unterforum entnehmen kann, hab ich (und mangels Reaktionen offenbar nur ich) ja derzeit "die problematischen AVC Wochen". Nun ist was neues aufgetaucht (wiederum bei einem gänzlich anderen 1711+ als jene Geräte um die es in den anderen Threads ging).

Ein Lancom VPN Client hat in seinen Proposals LZS Komprimierung drin, funktioniert soweit auch alles. Wenn er von seinem Netzwerk zuhause (irgendeine DSL Variante) eine Verbindung aufbaut funktioniert alles, Komprimierung kommt zustande.

Wenn er sich allerdings mit umts einwählt (mit der umts Client Software des Netzbetreibers, der AVC managed hier nichts) und eine Verbindung aufbaut, bricht der Aufbau bei Phase 2 ab (Timeout bei Warten auf Message). Sobald ich aber im Client die Kompression im Profil deaktivere, funktioniert es (Verbindung kommt zustande, natürlich ohne Komprimierung). Nachvollziehbar. Bei jedem anderen Internetzugang funktioniert alles, bei umts funktioniert es nur mit ausgeschalteter Kompression. Ich hab dafür keine Erklärung.

Im Trace stellt sich das mit Komprimierung so dar, das er anscheinend die IKE-CFG Message nicht mehr durchkriegt bzw. diese nie ankommt:

Code: Alles auswählen

[VPN-Status] 2010/08/12 08:08:12,570
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer NAME
IKE info: IKE-CFG:   Attribute APPLICATION_VERSION      len 0 skipped
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_NBNS        len 4 value 192.168.1.1 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_DNS         len 4 value 192.168.1.10 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_ADDRESS     len 4 value 192.168.1.202 added
IKE info: IKE-CFG: Sending message

danach kommt nichts mehr bis zum Timeout

Ohne Kompression:

Code: Alles auswählen

[VPN-Status] 2010/08/12 08:09:37,630
IKE info: IKE-CFG: Creating REPLY message with id 0 for peer NAME
IKE info: IKE-CFG:   Attribute APPLICATION_VERSION      len 0 skipped
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_NBNS        len 4 value 192.168.1.1 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_DNS         len 4 value 192.168.1.10 added
IKE info: IKE-CFG:   Attribute INTERNAL_IP4_ADDRESS     len 4 value 192.168.1.200 added
IKE info: IKE-CFG: Sending message


[VPN-Status] 2010/08/12 08:09:37,830
IKE info: Phase-2 remote proposal 1 for peer NAME matched with local proposal 1

Ansonsten keine Meldungen zu dieser Angelegenheit. Wenn mir hier jemand helfen kann eine logische Erkläerung zu finden, wär ich nicht undankbar.

[Dr.Einstein]

Komische Fehler meldest du in letzter Zeit mit dem AVC. Bei meinen Clients zusammen mit de Release 8.00 treten keine Fehler auf, egal ob der Client <2.1 ist oder sogar schon auf Windows 7 läuft.

Kompression verwend ich allerdings nicht. Vielleicht liegt es in deinem Fall daran, dass der UMTS Provider von Hause aus IPComp macht und durch einen dummen Zufall genau bei der Einigung kommen falsche Checksummen zustande bei doppelter Kompression mit verschiedenen Algorithmen ?

Kannst ja mal antworten, wenn du Neuigkeiten hast, klingt sehr komisch ...

[tbc233]

Keinem kommt das so komisch vor wie mir
(und ich installier Lancom Produkte schon seit Elsa Zeiten). Aber im Moment stellen sich all diese Dinge so dar wie von mir beschrieben.

Eine Kompression seitens des umts dürfte eigentlich nicht das Problem sein, da diese ja einen Layer drunter ist. Das dürfte der Client ja gar nicht "sehen".

[xexex]

Welcher UMTS Provider wird verwendet. Ist NAT Traversal auf dem Router aktiv? Sind die Proposals bis auf die Komprimierung sonst identisch?

[tbc233]

Vodafone (Austria). Ein Business-Produkt, die öffentliche IP ist direkt am Interface nach der Einwahl.

NAT-T ist dennoch (aufgrund anderer Clients) aktiviert.

Proposals sind 100% ident mit Ausnahem der Komprimierung.