Ich habe am Wochenende versucht mit Vista Boardmitteln ein VPN mit PSK zum 1722 aufzubauen. Das ganze scheitert bereits in der Phase1 des IKE. Ich hatte bei draytek geshen das deren Büchsen die einwahl mit Vista Boardmitteln zulassen. Hier nachzulesen http://www.draytek.de/Beispiele/VPN/Vis ... -IPSec.pdf
In dem PDF steht was von Agressive Mode... Soweit ich das versteanden habe arbeitet Vista aber im Main Mode. Ich habe dann für IKE AES-SHA ausgewählt und die aushandlung der sicherheitsstufe funktioniert soweit nur kommt der 1722 mit den darauffolgenden Paketen nicht mehr klar
IKE info: The remote server 77.182.94.20:500 peer xxx id <no_id> supports NAT-T in mode rfc
[VPN-Status] 2007/10/07 20:00:27,490
IKE info: Phase-1 remote proposal 1 for peer xxx matched with local proposal 1
[VPN-Status] 2007/10/07 20:00:27,660
IKE info: Phase-1 [responder] for peer xxx between initiator id 192.168.178.2 5, responder id 87.xxx.xxx.xxx done
IKE info: NAT-T enabled in mode rfc, we are not behind a nat, the remote side is behind a nat
IKE info: SA ISAKMP for peer xxx encryption aes-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)
[VPN-Status] 2007/10/07 20:00:27,700
IKE log: 200027 Default message_parse_payloads: unknown minimum payload size for payload type 21
[VPN-Status] 2007/10/07 20:00:27,700
IKE log: 200027 Default dropped message from 77.182.xxx.xxx port 4500 due to notification type PAYLOAD_MALFORMED
Ich hab ein wenig recherchiert und bei MS einen Artikel gefunden, in welchem erklärt wird das vista im IPSEC AUTHIP eingeführt hat. Dies wird erst an die Gegenstelle geschickt und wenn dies nicht angenommen wird, wird mit standard IPSEC weitergefunkt. Ich vermute der Lancom verhält sich nicht "richtig" bei der AUTHIP kommunikation so dass vista meint es könne mit AUTHIP weitermachen. Vermute ich einfach mal...ich find den artikel gerade nicht. Jemand damit erfahrungen bzw. einen tip? Vermutlich unterstützt Lancom die geschichte erst garnicht da die ihren VPN-Client weiter vertreiben möchten...
Vista IPSEC Vpn mit Boardmitteln zu Lancom 1722/Swyxconnect
Moderator: Lancom-Systems Moderatoren
Hi tisso
IKE info: Phase-1 [responder] for peer xxx between initiator id 192.168.178.2 5, responder id 87.xxx.xxx.xxx done
IKE info: The remote server 77.182.94.20:500 peer xxx id <no_id> supports NAT-T in mode rfc
Wenn irgendetwas mit MS-Bordmitteln nicht funktioniert, wenn die Gegenseite kein Windows ist, dann sitzt der Schuldige normalerweise in Redmond...
Gruß
Backslash
nein, die Phase 1 geht durch:Das ganze scheitert bereits in der Phase1 des IKE
IKE info: Phase-1 [responder] for peer xxx between initiator id 192.168.178.2 5, responder id 87.xxx.xxx.xxx done
ich würde eher sagen, sich Vista nicht RFC-Konform verhält, denn alle Vendor-Spezifischen Erweiterungen, wie XAUTH, AUTHIP, NAT-T etc müssen in der Vendor-Informationen, ausgehandelt wedern, die im ersten IKE-Paket übermittelt werden wie z.B. hier:Ich vermute der Lancom verhält sich nicht "richtig" bei der AUTHIP kommunikation so dass vista meint es könne mit AUTHIP weitermachen
IKE info: The remote server 77.182.94.20:500 peer xxx id <no_id> supports NAT-T in mode rfc
Wenn irgendetwas mit MS-Bordmitteln nicht funktioniert, wenn die Gegenseite kein Windows ist, dann sitzt der Schuldige normalerweise in Redmond...
Gruß
Backslash
Tach,
wieso bringt dich das nicht weiter? Du weist jetzt, daß sich dein Vista nicht korrekt verhält. Somit ist klar das Vista fehlerhaft ist und für Fehler in Vista ist nunmal Microsoft zuständig. Also wäre deine nächste Handlung ein Anruf bei Microsoft mit der Bitte um Behebung des Fehlers...
Das Beklagen über Hersteller B aufgrund von Fehlern des Herstellers A ist übrigens eine der interessantesten menschlichen Eigenschaften - Ein Kumpel von mir bezeichnet sowas als mentale Tiefstapelei...
Gruß
COMCARGRU
wieso bringt dich das nicht weiter? Du weist jetzt, daß sich dein Vista nicht korrekt verhält. Somit ist klar das Vista fehlerhaft ist und für Fehler in Vista ist nunmal Microsoft zuständig. Also wäre deine nächste Handlung ein Anruf bei Microsoft mit der Bitte um Behebung des Fehlers...
Das Beklagen über Hersteller B aufgrund von Fehlern des Herstellers A ist übrigens eine der interessantesten menschlichen Eigenschaften - Ein Kumpel von mir bezeichnet sowas als mentale Tiefstapelei...
Gruß
COMCARGRU
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???
Er trägt sogar sehr viel zur Sache bei, natürlich haben lernressitente Menschen damit ein Problem - das ist mir klar...
Dir scheint es völlig egal zu sein, daß bei einer hochgradig kritischen Angelegenheit gepfuscht wird - warum benutzt du dann überhaupt Verschlüsselung? Fehler an sich sind schon schlimm genug, aber Fehler bei einer VPN Iplementierung sind eine Katastrophe. Ein Router Hersteller, der sowas absichtlich tut um zu einem fehlerhaften Produkt kompatibel zu sein landet somit sofort auf der Blackliste! Sowas ist Indiskutabel.
Scheint dir aber nicht klar geworden zu sein - naja wie sagte mein Kumpel...
Gruß
COMCARGRU
Dir scheint es völlig egal zu sein, daß bei einer hochgradig kritischen Angelegenheit gepfuscht wird - warum benutzt du dann überhaupt Verschlüsselung? Fehler an sich sind schon schlimm genug, aber Fehler bei einer VPN Iplementierung sind eine Katastrophe. Ein Router Hersteller, der sowas absichtlich tut um zu einem fehlerhaften Produkt kompatibel zu sein landet somit sofort auf der Blackliste! Sowas ist Indiskutabel.
Scheint dir aber nicht klar geworden zu sein - naja wie sagte mein Kumpel...
Gruß
COMCARGRU
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???
Hi,
Wenn Draytek auf den M$ Zug aufspringt und sich ggf. ebenfalls nicht RFC konform verhaelt und es dann funktioniert, muss das noch lange nicht jeder andere Hersteller ebenfalls tun.
Ciao
LoUiS
Wo steht das, und wer schreibt das? Hast Du da ggf. was falsch interpretiert?es ist ein fehler wenn etwas funktioniert...
Wenn Draytek auf den M$ Zug aufspringt und sich ggf. ebenfalls nicht RFC konform verhaelt und es dann funktioniert, muss das noch lange nicht jeder andere Hersteller ebenfalls tun.
... oder Dir haben einfach die Antworten zur Sache nicht in den Kram gepasst?leider hat dein beitrag hier überhaupt nix zur sache beigetragen
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
ihr seid mal richtig sympathisch und sowas von hilfsbereit...ich wollte eigentlich nur nen lösungsansatz den tunnel hinzubekommen das einzige was ich hier gehört habe war geht nicht...vista ist schrott, draytek ist schrott plus man wird pers. angegriffen...Anscheinend ist Lancom das einzig wahre und wehe man versucht kostenlos einen tunnel von dem BS Markführer aufzubauen ohne irgendwelche VPN-Clients in Vista reinzufriemeln. Trotzdem danke für eure "Hilfe".
Was erwartest du denn, wenn du verlangst in Profi-Produkte absichtlich Fehler einzubauen und dies auch noch verteidigst?
Du laberst Schei.., du verlangst noch mehr Schei.. und hast offensichtlich nicht mal im Ansatz begriffen was du da sagst - noch machst du Anstallten es verstehen zu wollen - und dann wunderst du dich wenn dich hier keiner Ernst nimmt?
Es wurde hier klar gesagt, daß deine tollen Produkte Fehlerhaft sind. Statt sich aber darum zu kümmern, das diese Fehler ausgemerzt werden, willst das andere in Ihre Produkte auch Fehler einbauen? - In welcher Welt lebst du eigentlich?
Wir haben dir geholfen - nur wie bereits vermutet aus Lernresistenz - willst du die Hilfe nicht annehmen, weil diese nicht so aussieht wie du möchtest. - Sorry dann ist dir nicht zu helfen. Wenn dir die Wahrheit nicht paßt, so bleibt es dennoch die Wahrheit. Nur weil es dem gnädigen Herrn nicht genehm ist, wird hier kein IT-Profi in die Niederungen des IT Billig Schrott hinabsteigen. Wenn dein toller Draytek das kann, ja dann verwende ihn doch auch...
Sorry - aber ich hege den Verdacht, dir kann nur geholfen werden, wenn man dir das benötigte Wissen verbal in den Kopf hämmert, daher hab ich mal kein Blatt vor den Mund genommen - viele Leute lernen es halt nur wenn es weh tut...
Gute Nacht
COMCARGRU
Du laberst Schei.., du verlangst noch mehr Schei.. und hast offensichtlich nicht mal im Ansatz begriffen was du da sagst - noch machst du Anstallten es verstehen zu wollen - und dann wunderst du dich wenn dich hier keiner Ernst nimmt?
Es wurde hier klar gesagt, daß deine tollen Produkte Fehlerhaft sind. Statt sich aber darum zu kümmern, das diese Fehler ausgemerzt werden, willst das andere in Ihre Produkte auch Fehler einbauen? - In welcher Welt lebst du eigentlich?
Wir haben dir geholfen - nur wie bereits vermutet aus Lernresistenz - willst du die Hilfe nicht annehmen, weil diese nicht so aussieht wie du möchtest. - Sorry dann ist dir nicht zu helfen. Wenn dir die Wahrheit nicht paßt, so bleibt es dennoch die Wahrheit. Nur weil es dem gnädigen Herrn nicht genehm ist, wird hier kein IT-Profi in die Niederungen des IT Billig Schrott hinabsteigen. Wenn dein toller Draytek das kann, ja dann verwende ihn doch auch...
Sorry - aber ich hege den Verdacht, dir kann nur geholfen werden, wenn man dir das benötigte Wissen verbal in den Kopf hämmert, daher hab ich mal kein Blatt vor den Mund genommen - viele Leute lernen es halt nur wenn es weh tut...
Gute Nacht
COMCARGRU
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???
Moin Leute,
bitte wieder runterkommen (alle beide...), sonst macht hier jemand den Thread
zu...
Tatsache ist wohl die, daß Vista sich in irgendeinem Punkt nicht RFC-konform
verhält. Jetzt kann man sich überlegen, ob man dafür einen Workaround
auf LANCOM-Seite reindreht oder Vista Vista sein läßt. Workarounds haben
bei komplexen Protokollen nur immer das Problem, daß man letzten Endes
auf der eigenen Seite auch wieder eine bewußte Protokollverletzung einbaut,
mit der man das Risiko eingeht, daß dann wieder die Verhandlung gegen
eine andere Gegenstelle schief geht, die vorher funktioniert hat - also fängt
man an, irgendwo einen Schalter 'Windows-Quirks' einzubauen, bei dem
man allen anderen Kunden erklären muß, daß sie ihn tunlichst nicht benutzen
sollen...aus diesem Grund ist es immer die bessere Lösung, wenn Fehler
an ihrer Quelle behoben werden...
...bei einer hinreichend 'wichtigen' Gegenstelle kommt man aber u.U.
nicht darum herum, solche Workarounds einzubauen, nur ist wohl im
Augenblick nicht so, daß der eingebaute Client von Vista als eine solche
angesehen wird (schon bei XP hat die absolute Minderzahl von Anwendern
versucht, den eingebauten Client zu Fuß zu konfigurieren...). Und wer weiß,
vielleicht repariert Microsoft das mit dem nächsten Service-Pack und dann
haben wir einen Schalter an der Backe, der wirklich für nichts mehr gut ist.
Was Comcargu auf die Palme gebracht hat, ist vermutlich Deine Haltung
a la 'mit Draytek funktioniert das aber und mir ist egal, woran das liegt,
solange ich meine Verbindung bekomme'. Natürlich können zwei
Implementationen in so passender Weise kaputt sein, daß sie wieder
zusammenspielen, aber in der Summe sicherheitsrelevante Elemente fehlen,
die so eine Verbindung dann angreifbar machen.
Im WLAN gibt und gab es z.B. auch das Problem, daß diverse D-Link-Clients
einen Teil des WPA-Protokolls nicht richtig implementieren. Nun gibt es
APs, die über des Protokollverletzung hinwegsehen und man könnte auch
in das LANCOM einen Schalter einbauen, diesen Fehler zu ignorieren.
Trotzdem habe ich das nicht getan. Warum? Weil diese Prüfung sicherheits-
relevant ist und ohne diese Prüfung wird die WPA-Anmeldung anfällig für
Man-in-the-middle-Attacken. Man bekommt eine Lösung, bei der der Kunde
nur meint, die Verbindung wäre sicher und sich in falscher Sicherheit wiegt.
Ich will nicht behaupten, daß hier auch so eine Situation vorliegt, dazu
verstehe ich von IPsec zu wenig, aber ich bitte Dich, das ganze auch mal
aus diesem Gesichtspunkt zu betrachten.
So, und nun schlagt alle zusammen auf mich ein...
Gruß Alfred
bitte wieder runterkommen (alle beide...), sonst macht hier jemand den Thread
zu...
Tatsache ist wohl die, daß Vista sich in irgendeinem Punkt nicht RFC-konform
verhält. Jetzt kann man sich überlegen, ob man dafür einen Workaround
auf LANCOM-Seite reindreht oder Vista Vista sein läßt. Workarounds haben
bei komplexen Protokollen nur immer das Problem, daß man letzten Endes
auf der eigenen Seite auch wieder eine bewußte Protokollverletzung einbaut,
mit der man das Risiko eingeht, daß dann wieder die Verhandlung gegen
eine andere Gegenstelle schief geht, die vorher funktioniert hat - also fängt
man an, irgendwo einen Schalter 'Windows-Quirks' einzubauen, bei dem
man allen anderen Kunden erklären muß, daß sie ihn tunlichst nicht benutzen
sollen...aus diesem Grund ist es immer die bessere Lösung, wenn Fehler
an ihrer Quelle behoben werden...
...bei einer hinreichend 'wichtigen' Gegenstelle kommt man aber u.U.
nicht darum herum, solche Workarounds einzubauen, nur ist wohl im
Augenblick nicht so, daß der eingebaute Client von Vista als eine solche
angesehen wird (schon bei XP hat die absolute Minderzahl von Anwendern
versucht, den eingebauten Client zu Fuß zu konfigurieren...). Und wer weiß,
vielleicht repariert Microsoft das mit dem nächsten Service-Pack und dann
haben wir einen Schalter an der Backe, der wirklich für nichts mehr gut ist.
Was Comcargu auf die Palme gebracht hat, ist vermutlich Deine Haltung
a la 'mit Draytek funktioniert das aber und mir ist egal, woran das liegt,
solange ich meine Verbindung bekomme'. Natürlich können zwei
Implementationen in so passender Weise kaputt sein, daß sie wieder
zusammenspielen, aber in der Summe sicherheitsrelevante Elemente fehlen,
die so eine Verbindung dann angreifbar machen.
Im WLAN gibt und gab es z.B. auch das Problem, daß diverse D-Link-Clients
einen Teil des WPA-Protokolls nicht richtig implementieren. Nun gibt es
APs, die über des Protokollverletzung hinwegsehen und man könnte auch
in das LANCOM einen Schalter einbauen, diesen Fehler zu ignorieren.
Trotzdem habe ich das nicht getan. Warum? Weil diese Prüfung sicherheits-
relevant ist und ohne diese Prüfung wird die WPA-Anmeldung anfällig für
Man-in-the-middle-Attacken. Man bekommt eine Lösung, bei der der Kunde
nur meint, die Verbindung wäre sicher und sich in falscher Sicherheit wiegt.
Ich will nicht behaupten, daß hier auch so eine Situation vorliegt, dazu
verstehe ich von IPsec zu wenig, aber ich bitte Dich, das ganze auch mal
aus diesem Gesichtspunkt zu betrachten.
So, und nun schlagt alle zusammen auf mich ein...
Gruß Alfred
Vielen dank für diese objektive und kompetente Antwort Alf, das Problem ist ich versteh von IPSEC auch nicht viel. Ich weiss nur das ich schon ein paar tunnel mit den wildesten Konfigurationen hinbekommen habe. Und oben wurde bis jetzt auch nur pauschal gesagt äh geht nicht...ja ist halt MS schuld aber was genau der fehler ist hat mir auch noch niemand gesagt. Das ich Draytek erwähnt habe war einfach nur die Rechtfertigung das halt VISTA jetzt standarmäßig IPSEC kann und das über nen popeligen Assistenten und das es mit den Drayteks von Werk aus funktioniert, nicht mehr und nicht weniger. Wenn mir jetzt jemand genau sagen kann es liegt an xy in Protokoll z weil Vista nicht nach RFC bla arbeitet dann nehm ich das hin und ich werde das gerne an Microsoft weiterleiten! Aber pauschal zu sagen alles ist super und wenn die gegenstelle nicht von LC ist kann es nur daran liegen find ich bissl oberflächlich.
Tach,
Aus der direkt erfolgten Antwort von Backslash:
Gruß
COMCARGRU
Aus deinem ersten Posting:Wenn mir jetzt jemand genau sagen kann es liegt an xy in Protokoll z weil Vista nicht nach RFC bla arbeitet dann nehm ich das hin und ich werde das gerne an Microsoft weiterleiten!
[VPN-Status] 2007/10/07 20:00:27,700
IKE log: 200027 Default dropped message from 77.182.xxx.xxx port 4500 due to notification type PAYLOAD_MALFORMED
Aus der direkt erfolgten Antwort von Backslash:
Da ist doch deine Antwort!Zitat:
>> Ich vermute der Lancom verhält sich nicht "richtig" bei der AUTHIP kommunikation so dass vista meint es könne mit AUTHIP weitermachen
ich würde eher sagen, sich Vista nicht RFC-Konform verhält, denn alle Vendor-Spezifischen Erweiterungen, wie XAUTH, AUTHIP, NAT-T etc müssen in der Vendor-Informationen, ausgehandelt wedern, die im ersten IKE-Paket übermittelt werden wie z.B. hier:
IKE info: The remote server 77.182.94.20:500 peer xxx id <no_id> supports NAT-T in mode rfc
Gruß
COMCARGRU
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???