IPSec-Tunnel - received NO_PROPOSAL_CHOSEN error notify

Hallo zusammen,

ich wollte heute einen IPSec-Tunnel einrichten, jedoch kommt die Phase 1 mit der Meldung "received NO_PROPOSAL_CHOSEN error notify" nicht zustande.

Intranet: pfSense (Version 2.3.5)
Remote: Barracuda Firewall

Eigentlich ein simpler Tunnel, ohne NAT/BINAT o.ä.

Ich habe bereits:

pfSense-Wiki und Co geprüft
IPSec-Einstellungen mehrmals geprüft
VPN nochmals neu angelegt und darauf geachtet, dass alle Einstellungen stimmen
Pre-Shared-Key durch einen kürzeren + keine Sonderzeichen ersetzt
Testweise SHA256 sowie SHA1 probiert (SHA1 funktioniert bei einem anderen Kunden problemlos)

Jedoch kommt der Tunnel nicht zustande.

Hat noch jemand Tipps, wo es klemmen könnte, wenn die Einstellungen definitiv stimmen?

Grüße,

JeGr

Die IPSEC Logs auf der Sense mal prüfen und nachschauen. Dort sollte eigentlich immer sichtbar sein, was die Sense als Proposal von der anderen Seite bekommen hat. Nicht nur Barracudas, sondern auch Checkpoints, Bintecs, Lancoms und Co. geben manchmal (obskurerweise) einen Mist darauf, was konfiguriert ist, sondern fahren das erste Proposal mit irgendwelchen Global Defaults an und erst im zweiten Versuch machen sie das was konfiguriert ist. Die pfSense ist dann aber manchmal schon im Deny und sagt "nö ist nicht konfiguriert, vergiss es". Ist uns nun schon mehrfach mit Geräten unterschiedlicher Hersteller so gegangen (Lancom und Bintec bspw. grrr) oder aber, es wird ggf. AES mit 256Bit konfiguriert, das andere System fragt aber: 128? 192? 256? Und die pfSense legt nach 128/192 schon auf. Deshalb mal den Proposal String checken, was von der Gegenseite tatsächlich ankommt und zum Testen die pfSense auf Listen-only schalten, dass sie selbst die Verbindung nicht versucht aufzubauen, sondern nur als Gegenstelle auf das Proposal der Gegenseite wartet.

Gruß

@JeGr:

Die IPSEC Logs auf der Sense mal prüfen und nachschauen. Dort sollte eigentlich immer sichtbar sein, was die Sense als Proposal von der anderen Seite bekommen hat

Mit Listen-only zickt der Tunnel ebenfalls rum.

(IKE SA und IKE Child SA stehen in der Sense auf Diag)
Ich finde nur diese Zeile, dass ist aber die Config der pfSense und nicht die, der Gegenstelle.

Feb 22 14:22:49 fw1 charon: 05[CFG] <con2000|26>configured proposals: IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536</con2000|26>

Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing ISAKMP_VENDOR task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing ISAKMP_CERT_PRE task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing MAIN_MODE task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing ISAKMP_CERT_POST task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing ISAKMP_NATD task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>queueing QUICK_MODE task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating new tasks
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating ISAKMP_VENDOR task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating ISAKMP_CERT_PRE task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating MAIN_MODE task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating ISAKMP_CERT_POST task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>activating ISAKMP_NATD task
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>sending XAuth vendor ID
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>sending DPD vendor ID
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>sending FRAGMENTATION vendor ID
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>sending NAT-T (RFC 3947) vendor ID
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>initiating Main Mode IKE_SA con2000[26] to 217.XXX.XXX.XXX
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>IKE_SA con2000[26] state change: CREATED => CONNECTING
Feb 22 14:22:49 fw1 charon: 05[CFG] <con2000|26>configured proposals: IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
Feb 22 14:22:49 fw1 charon: 05[ENC] <con2000|26>generating ID_PROT request 0 [ SA V V V V V ]
Feb 22 14:22:49 fw1 charon: 05[NET] <con2000|26>sending packet: from 192.168.178.22[500] to 217.XXX.XXX.XXX[500] (180 bytes)
Feb 22 14:22:49 fw1 charon: 05[NET] <con2000|26>received packet: from 217.XXX.XXX.XXX[500] to 192.168.178.22[500] (40 bytes)
Feb 22 14:22:49 fw1 charon: 05[ENC] <con2000|26>parsed INFORMATIONAL_V1 request 0 [ N(NO_PROP) ]
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>received NO_PROPOSAL_CHOSEN error notify
Feb 22 14:22:49 fw1 charon: 05[IKE] <con2000|26>IKE_SA con2000[26] state change: CONNECTING => DESTROYING</con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26></con2000|26>

JeGr

Mit Listen-only zickt der Tunnel ebenfalls rum.

Ich hatte ja nichts anderes behauptet, sondern gesagt: schließe damit eine Fehlerseite aus ;) Bislang war der Fehler meistens nicht auf pfSense sondern auf der anderen Seiten zu suchen.

Das Proposal liest sich aber nach AES-192 mit SHA1 und DH Gruppe von 1536. Klingt eher schräg?

bon-go

Ich möchte den Topic nicht kapern, aber hat denn jemand eine Lösung dafür? Ich stehe vor dem exakt gleichen Problem, habe auch wie der TO schon sehr viel gelesen und auch probiert und es funktioniert nicht.
Intranet: pfSense (Version 2.4.4)
Remote: Lancom VPN Router
Wo kann ich die angebotenen Proposals der Gegenseite sehen? Die Logs der pfSense unter System Logs / IPSec sehen im Prinzip so aus wie die des TO und zeigen das nicht.

JeGr

Normalerweise einfach die pfSense Seite so einstellen, dass sie die Verbindung nicht aufbaut sondern nur annimmt.
Dann Log leeren und die Lancom Seite triggern, damit die aufbaut. Und dann das Log nach den Proposals und Fehlern durchsuchen.

bon-go

Danke, muss ich sehen ob ich das hinkriege. Die Lancom sollen im Laufe der Zeit eh alle ausgetauscht werden, aber dieser ist z.Z. das Gerät in der Zentrale und den muss ich noch einige Zeit am Leben halten.
Bisher hatte ich bei dieser Verbindung den Lancom nur annehmen und die pfSense den Tunnel aufbauen lassen. Die Logs sind dann leider nicht sehr ergiebig. Kann man den loglevel in der pfSense kurzzeitig höher stellen oder gibt es anderswo weitergehende Logs? Wenn ich das im Lancom trace spammt der mich voll weil da viele Tunnel eingerichtet sind und genutzt werden, da schmiert gar immer putty ab.

bon-go

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?

0_1541176522103_ipsec-log01.txt

bon-go

This post is deleted!

JeGr

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?

bon-go

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'?

JeGr

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

bon-go

ist:

JeGr

Ist im Normalfall auch völlig OK. Daher die Frage nach NAT-T, wenn die Kiste hinter NAT steht, muss auch 4500 funktionieren.

bon-go

Kein NAT, direkte öff. IPv4 auf beiden Seiten.

bon-go

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

bon-go

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

Protokoll 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.txt

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

bon-go

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:

JeGr

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

bon-go

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.