IPSec-Tunnel - received NO_PROPOSAL_CHOSEN error notify
-
Ich bin erstmal ein kleines Stück weiter gekommen und beobachte nun die ipsec.log auf der Konsole.
Schlüssel und Authentifizierung stimmt nun überein aber letztendlich immer noch kein Tunnelaufbau :(
Hat noch jemand zielführende Ideen? -
This post is deleted! -
Da ich was von NAT-T sehe: sind udp500 und 4500 sauber verfügbar und abgehend entsprechend static genattet? NAT-T hieße zudem dass eine Seite hinter NAT steht?
-
Beide Router sind direkt am Netz, kein NAT davor. Eingehend 500 und 4500 offen für Anfragen so wie ESP auch. Der Lancom hat weitere feste Tunnel und Roadwarrior, die pfSense (neue Aussenstelle, noch im Testbetrieb weil's halt mit dem Lancom nicht geht, jederzeit umkonfigurierbar) auch.
Was genau meinst du mit 'abgehend entspr. statisch genattet'?
-
@bon-go Schau dir die Outbound NAT Regeln der Sense an (die Default Regeln), dort wird Port 500 abgehend bspw. mit static port Flag abgehend aufs WAN Interface "genattet". Grund: Default ist es die Ports beim outbound NAT zu shuffeln. IPSEC oder auch VoIP reagieren da aber empfindlich und müssen statisch genattet werden damit Port 500 auch 500 (4500/5060) so bleibt wie er ist.
-
ist:
-
Ist im Normalfall auch völlig OK. Daher die Frage nach NAT-T, wenn die Kiste hinter NAT steht, muss auch 4500 funktionieren.
-
Kein NAT, direkte öff. IPv4 auf beiden Seiten.
-
Sobald ich beim Lancom die Anwahlgegenstelle deaktiviere und auf der pfSense wieder aktiviere kommt auf der pfSense: NO_PROPOSAL_CHOSEN
0_1541187153649_ipsec-log02.txt -
Ich stehe immer noch vor dem Problem des nicht funktionierenden Tunnelaufbaus. Ich habe das Ganze nun mal bei mir separat in einem Testnetz mit von null an neu installierter Technik nachgebaut: Lancom 1781EF+ FW 9.24 RU4, pfSense 2.3.5, separater Testnetz Router und sep. Switche davor, alles in realer Hardware. Ich habe explizit mal nicht die aktuellste Fw des Lancom und der pfSense genommen aber könnte das ja jederzeit ändern.
Ich hab sogar extra mal die Anleitung bei Lancom gelesen (was ich sonst nie mache) wie man manuell einen VPN Tunnel einrichtet - ist letzten Endes gleich wie ich es auch vorher auch schon immer gemacht habe.
Nach wie vor scheitert nun der Tunnelaufbau am Ende von Phase 1 mit einem IKE Timeout, grundlos meiner Meinung nach. Initiator ist nun erstmal der Lancom.Protokoll 1 ist 'relativ kurz' und mit den normalen Diag Einstellungen entstanden:
0_1541347571262_protokoll01.txtProtokoll 2 ist schon einiges länger, hier hab ich mehr auf diag gestellt, werde aber nicht schlauer draus was die Ursache ist:
0_1541347664872_protokoll02-detailliert.txtIch habe schon sehr viele verschiedene VPN Konfigurationen am Start, aber entweder immer nur Lancom - Lancom oder pfSense - pfSense (IPSec und openVPN, auch mal openWRT / Untangle / nativ Linux / Sophos oder sonstwas). Bisher nie echte Probleme gehabt. Nur hier klappt es überhaupt nicht.
Hat denn überhaupt schon mal jemand eine funktionierende VPN Verbindung zwischen einem Lancom und einer pfSense hinbekommen?
Ich bin ohnehin verwundert dass sich mir hier so Schwierigkeiten auftun.
-
Es geht - auch wenn ich noch nicht genau weiss wieso das vorher nicht funktioniert hat. Ich komme mir ziemlich verarscht vor, ehrlich. Letztendlich ist es vmtl. genauso wie ich es mir von Anfang an dachte: der Lancom ist Schuld an dem Blödsinn. Deswegen verabschieden wir uns ohnehin an vielen Stellen von diesen Geräten.
Ich schreibe den Roman hier mal auf für diejenigen die es interessiert, die irgendwann vor gleichen Problemen stehen und auch für mich später falls ich das wieder suche.
Der Weg war recht mühselig. Ich habe auf der Lancom Konsole mittels 'trace + vpn status' und 'trace + vpn packet' sowie parallel auf der pfSense unter VPN Advanced Settings den SA Manager (und tlw. noch mehr) auf diag gestellt und dann dort auf der Konsole mittels 'clog -f /var/log/ipsec.log' praktisch alles logged was von Interesse sein könnten und diese Logs dann akribisch ausgewertet bis ich Fehlermeldung für Fehlermeldung nach und nach eleminiert habe. Die meisten Fehler ergaben auch im Nachgang betrachtet keinen Sinn. Es war korrekt eingestellt hat aber dennoch nicht funktioniert. Ich werde hier im Anschluss noch einmal die gesamten Gerätschaften auf null zurücksetzen bzw. neu installieren um zu schauen ob das wieder passiert. Fakt ist: es hätte von Anfang an funktionieren müssen. Ich habe am Ende genau die Konfiguration (tlw. gar noch leicht weniger) mit der ich angefangen hatte.
Folgende Fehlermeldungen haben mich auf dem Weg zum Ziel begleitet:
- received NO_PROPOSAL_CHOSEN error notify
- dann angeblich keine matchenden IKE Proposals obwohl die definitiv korrekt gleich eingestellt waren, bis hinunter zu AES 128, MD5, DH2, ohne DPD und ohne PFS sukzessive alles runtergeschraubt
- damit fing der Unsinn an, danach habe ich den Tunnel immer vom Lancom aufbauen lassen
- dann keine matchenden IKE Identifier bei der Authentifizierung, erst als ich manuell die jeweiligen IP eingegeben hatte - lokal und peer - sowie auch den remote gateway jweils mit IP angegeben habe hat das erstmalig geklappt
- IKE log: 173835.242284 Default ipsec_get_keystate: no keystate in ISAKMP SA im Lancom trace
- dann zwischenzeitlich Identifier bei denen keine PSK Authentifizierung erlaubt war
- da mir die Angabe der IP bei den remote gateways anstelle von FQDN als auch die manuellen Angaben bei my bzw. remote identifier / lokale bzw. entfernte Identität nicht gefallen hat habe ich lange daran rumgebastelt bis auch das irgenwann ohne ging
- keine matchenden Netzwerke in Phase 2, die Einstellungen kamen immer mit 'no match found' zurück bis ich dann letztendlich mal 0.0.0.0/0 bei remote network angegeben hab - ab dem Moment ging das :(
Danach habe ich alles schrittweise wieder so eingestellt wie ich das für gut finde und es geht immer noch: IKE 1, Auth. mit PSK im main mode, FQDN als Angabe bei den gateways auf beiden Seiten, keine IP als identifier auf beiden Seiten, AES 256 / SHA256 / DH14 / Lifetime 86400 / DPD 10 sek. bei IKE, ESP / AES 256 / SHA256 / PFS 14 / Lifetime 28800 bei IPSEC und Angabe von mehr. separaten /24 Netzen in Phase 2.
Ich habe die Geräte zwischendurch immer mal wieder mit Backups zurückgesetzt und auch kalt gestartet. Es gibt keine reale Erklärung für den Unsinn. Der Lancom braucht hier und da auch mehr an Zeit nach Ändern der Identifier, das auszuprobieren hat mich am meisten Zeit gekostet.
Die letzte Einstellung mit der ich leben kann sieht auf der pfSense udn im Lancom wie folgt aus:
-
Danke für das Durchstehen und Dokumentieren! Das deckt sich leider mit meiner Erfahrung an anderen Stellen, auch wenn es schon positive Stimmen zu den Lancom Geräten gab. Leider habe ich entweder nur die Problemkinder erwischt oder ähnlich wie du seltsames Verhalten was an Bugs grenzt erlebt, dass entweder sehr lange gebraucht wurde um überhaupt Einstellungen zu übernehmen bzw. schlicht mit falschen Werten verbunden wurde. Leider keine Ahnung wo das herrührt, aber an der Stelle positiv, dass es tatsächlich wie vermutet nicht die Schuld der Strongswan Instanz war.
Gruß Jens
-
Der zeitliche Aufwand und die sinnbefreiten Schwierigkeiten währenddessen waren um einiges größer wie ich hier geschrieben habe. Es waren mehrere Abende, das letzte WE, ungezählte Konfigurationen und doch ein gewisser Aufwand an eingesetzer realer Hardware notwendig um das gewünschte Ergebnis in mehreren Testszenarien zu evaluieren. Ich komme mir völlig verar***t und wie ein dummer Junge in der 2. Klasse vor *Kopfschüttel :(
Problem musste halt gelöst werden. Die einzige temporäre Alternative wäre ein openVPN Tunnel bis hinter den akt. eingesetzten Lancom gewesen, verbunden mit weiterem Hardwareeinsatz, einem zwangsweise weiteren NAT Tunnel bei der Kommunikation der Netze untereinander, evtl. einer weiteren DMZ und anderen unschönen Dingen. Das geht, habe ich anderswo auch temporär als Notmaßnahme im Einsatz, aber das kann nicht die Lösung sein.
Das Thema Lancom VPN Router ist bei uns im Prinzip durch. Außer im begrenzten Einsatz als ISDN Gateway für noch existierende ISDN Anlagen oder als ISDN Fax Gateway fliegen die überall raus.
Beispiel: wir haben anderswo mehrere fast komplett neue Lancom Router im Einsatz die ungeahnte Probleme haben. Sobald man eines der LAN Kabel zieht oder bei Multi WAN einer der Provider mal nicht verfügbar ist hängt sich der Router auf, darf auf Werkseinstellungen zurückgesetzt werden und die Konfiguration wieder eingespielt werden - unerklärlich. Die Geräte wurde bereits mehrfach komplett neu aufgesetzt, die Hardware getauscht, Anschlüsse und Erdung geprüft usw. usw. - alles ohne Erfolg. Auch die fliegen jetzt raus.
