driv3r
Sep 13, 2023, updated at 11:52:35 (UTC)
view2125
view17
0
Goto Top

OPNsense VPN IPsec (received proposals unacceptable)

GermansolvedQuestionVPN
Guten Morgen,

aktuell konfiguriere ich den IPsec VPN Zugang (verschiedene externe iPhones mit IPsec und vorher exportiertem Cert) meiner OPNsense.
Ich bekomme beim connected immer "received proposals unacceptable".

Ich habe folgende Anleitung benutzt und ebenso 1:1 konfiguriert.

IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

2023-09-13T05:51:49	Informational	charon	14[NET] <8> sending packet: from xxx.xxx.xxx.xxx[500] to xxx.xxx.xxx.xxx[8687] (36 bytes)	
2023-09-13T05:51:49	Informational	charon	14[ENC] <8> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]	
2023-09-13T05:51:49	Informational	charon	14[IKE] <8> received proposals unacceptable	
2023-09-13T05:51:49	Informational	charon	14[IKE] <8> remote host is behind NAT	
2023-09-13T05:51:49	Informational	charon	14[CFG] <8> configured proposals: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024	
2023-09-13T05:51:49	Informational	charon	14[CFG] <8> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024	
2023-09-13T05:51:49	Informational	charon	14[IKE] <8> xxx.xxx.xxx.xxx is initiating an IKE_SA	
2023-09-13T05:51:49	Informational	charon	14[ENC] <8> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]	
2023-09-13T05:51:49	Informational	charon	14[NET] <8> received packet: from xxx.xxx.xxx.xxx[8687] to xxx.xxx.xxx.xxx[500] (604 bytes)

Könnt ihr mit die obige Fehlermeldung erklären?
Firewall ist kontrolliert und entsprechend für die Ports offen.

Hier noch schnell die konfig der OPNsense.

Cert entfernt

mobile clients
phase1
phase2
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 5370794975

Url: https://administrator.de/contentid/5370794975

Printed on: July 27, 2024 at 12:07 o'clock

17 Comments
Latest comment
Goto Top
Member: aqui
aqui Sep 13, 2023 updated at 07:20:01 (UTC)
Goto Top
Unacaptable Proposals bedeutet das die zur Aushandlung vorgeschlagenen Schlüsselverfahren nicht akzeptiert werden.
In "configured proposals" kannst du immer sehen was lokal konfiguriert wurde und "receiveded proposals" ist das was das Gegenüber vorschlägt.
Zwischen diesen Auswahlvorschlägen (Proposals) gibt es dann keine Gemeinsamkeiten so das kein Schlüsselverfahren ausgewählt werden konnte und deshalb bricht der VPN Tunnelaufbau verständlicherweise ab.
Soviel zur Fehlermeldung... Die, wenn man sie einmal nur liest und etwas nachdenkt, auch selbsterklärend ist. face-wink
Wie die Fehlermeldung auch schon selbst sagt hat das mit dem Zertifikat per se rein gar nichts zu tun und das hier zu exponieren wäre nicht nötig gewesen!
(Nebenbei: Solltest du besser auf 3 oder 5 Jahre Gültigkeit setzen. Sonst bist du gleich nächstes Jahr wieder am Zertifikate generieren und importieren für die Clients wenn nach dem 14. Oktober nix mehr geht im VPN! 😉)

Mit anderen Worten: Du hast einen Konfig Fehler begangen und das Tutorial nicht richtig gelesen, denn bei den ein gestellten Schlüsselverfahren hast du einen Fehler gemacht! (Phase 2) 🧐

Fazit:
Tutorial in dem Punkt noch einmal wirklich genau lesen und dann korrigieren, dann klappt das auch sofort!!

Diese Schlüsselauswahl aus dem Tutorial ist richtig:
opsensprop.

Das vergleichst du jetzt einmal mit deinem obigen Screenshot!!
Finde den Fehler...!! 😉
Member: DRIV3R
DRIV3R Sep 13, 2023 updated at 07:46:52 (UTC)
Goto Top
Hi aqui,

erstmal danke.
Ich hab alles verglichen. PFS key group ist jetzt in den Mobile Clients Einstellungen unter Phase 2 PFS Group, vermute ich.
Ansonsten habe ich den Encryption Algorithmus von AES256 und gcm16 auf NUR AES256 gesetzt.
Und SHA512 hinzugefügt

Der Rest passt (hab auch den o.a. Identifier benutzt)

Es bleibt aber leider bei received proposals unacceptable
Ich habe die proposals verglichen. Sowohl in configured als auch in received sind identische Einträge vorhanden
Member: DRIV3R
DRIV3R Sep 13, 2023 at 07:52:21 (UTC)
Goto Top
Ich nehme alles zurück. Ich habe die OPNsense neu gestartet und teste gerade. Die proposals Meldung ist weg.
Member: DRIV3R
DRIV3R Sep 13, 2023 at 07:58:06 (UTC)
Goto Top
Falscher Alarm.
Es bleibt leider bei received proposals unacceptable
Member: DRIV3R
DRIV3R Sep 13, 2023 at 08:21:18 (UTC)
Goto Top
So, nach einigen Test bekomme ich nun tatsächlich ein "selected proposal".
Der Client (iPhone) connected aber nicht.
Es sieht nur wie folgt aus:

2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (320 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR SUBNET U_DEFDOM U_SPLITDNS DOMAIN) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> CHILD_SA con1{2} established with SPIs cd754a90_i 011500fb_o and TS 192.168.20.0/24 === 10.99.99.1/32
2023-09-13T08:16:46	Informational	charon	 09[CFG] <con1|2> selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> maximum IKE_SA lifetime 15836s
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> scheduling rekeying in 14396s
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> IKE_SA con1[2] established between xxx.xxx.xxx.xxx[opnsense]...xxx.xxx.xxx.xxx[xxx.xxx.xxx.xxx]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> no virtual IP found for %any6 requested by 'testvpn'  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> peer requested virtual IP %any6
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> assigning virtual IP 10.99.99.1 to peer 'testvpn'  
2023-09-13T08:16:46	Informational	charon	 09[CFG] <con1|2> reassigning offline lease to 'testvpn'  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> peer requested virtual IP %any
2023-09-13T08:16:46	Informational	charon	 09[CFG] <con1|1> lease 10.99.99.1 by 'testvpn' went offline  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|1> destroying duplicate IKE_SA for peer 'testvpn', received INITIAL_CONTACT  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> authentication of 'opnsense' (myself) with EAP  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> authentication of 'xxx.xxx.xxx.xxx' with EAP successful  
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> parsed IKE_AUTH request 5 [ AUTH ]
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> received packet: from xxx.xxx.xxx.xxx[40270] to 87.122.115.0[4500] (112 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (80 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 4 [ EAP/SUCC ]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> EAP method EAP_MSCHAPV2 succeeded, MSK established
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> received packet: from xxx.xxx.xxx.xxx[40270] to xxx.xxx.xxx.xxx[4500] (80 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (144 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> received packet: from xxx.xxx.xxx.xxx[40270] to xxx.xxx.xxx.xxx[4500] (144 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (112 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> initiating EAP_MSCHAPV2 method (id 0xF0)
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> received EAP identity 'testvpn'  
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> parsed IKE_AUTH request 2 [ EAP/RES/ID ]
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> received packet: from xxx.xxx.xxx.xxx[40270] to xxx.xxx.xxx.xxx[4500] (96 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (564 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <con1|2> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (1236 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 1 [ EF(2/2) ]
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 1 [ EF(1/2) ]
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> splitting IKE message (1728 bytes) into 2 fragments
2023-09-13T08:16:46	Informational	charon	 09[ENC] <con1|2> generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> sending end entity cert "C=DE, ST=Nordrhein Westfalen, L=xxxxxxxx, O=private, E=xxxxxxxxxx, CN=opnsense"  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> authentication of 'opnsense' (myself) with RSA signature successful  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> peer supports MOBIKE
2023-09-13T08:16:46	Informational	charon	 09[IKE] <con1|2> initiating EAP_IDENTITY method (id 0x00)
2023-09-13T08:16:46	Informational	charon	 09[CFG] <con1|2> selected peer config 'con1'  
2023-09-13T08:16:46	Informational	charon	 09[CFG] <2> looking for peer configs matching xxx.xxx.xxx.xxx[opnsense]...xxx.xxx.xxx.xxx[10.143.223.122]
2023-09-13T08:16:46	Informational	charon	 09[ENC] <2> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
2023-09-13T08:16:46	Informational	charon	 09[ENC] <2> unknown attribute type INTERNAL_DNS_DOMAIN
2023-09-13T08:16:46	Informational	charon	 09[NET] <2> received packet: from xxx.xxx.xxx.xxx[40270] to xxx.xxx.xxx.xxx[4500] (496 bytes)
2023-09-13T08:16:46	Informational	charon	 09[NET] <2> sending packet: from xxx.xxx.xxx.xxx[500] to xxx.xxx.xxx.xxx[56348] (481 bytes)
2023-09-13T08:16:46	Informational	charon	 09[ENC] <2> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
2023-09-13T08:16:46	Informational	charon	 09[IKE] <2> sending cert request for "C=DE, ST=Nordrhein Westfalen, L=xxxxxxxx, O=home, E=xxxxxxxxxx, CN=opnsense-ca"  
2023-09-13T08:16:46	Informational	charon	 09[IKE] <2> remote host is behind NAT
2023-09-13T08:16:46	Informational	charon	 09[CFG] <2> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
2023-09-13T08:16:46	Informational	charon	 09[IKE] <2> xxx.xxx.xxx.xxx is initiating an IKE_SA
2023-09-13T08:16:46	Informational	charon	 09[ENC] <2> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
2023-09-13T08:16:46	Informational	charon	 09[NET] <2> received packet: from xxx.xxx.xxx.xxx[56348] to xxx.xxx.xxx.xxx[500] (604 bytes)
2023-09-13T08:16:36	Informational	charon	 09[NET] <con1|1> sending packet: from xxx.xxx.xxx.xxx[4500] to xxx.xxx.xxx.xxx[40270] (80 bytes)
2023-09-13T08:16:36	Informational	charon	 09[IKE] <con1|1> retransmit 4 of request with message ID 0
Member: aqui
aqui Sep 13, 2023 updated at 11:53:56 (UTC)
Goto Top
Sieht ja jetzt gut und richtig aus! face-wink
Member: DRIV3R
DRIV3R Sep 13, 2023 at 12:09:27 (UTC)
Goto Top
Verbindet aber nicht face-sad
Ein Lease wird erzeugt und die Verbindung wird als aktiv gekennzeichnet bis dann DPD greift.
Aber das iPhone zeigt nur
„Verbinden…“ für 3-5 Sekunden.
Dann ist der VPN Schalter wieder aus.
Ohne Fehlermeldung o.ä.
Member: aqui
aqui Sep 14, 2023 updated at 07:49:44 (UTC)
Goto Top
  • Das CA Zertifikat (nicht Server!) hast du auf das iPhone importiert??
  • Hast du auf dem iPhone als remote ID auch einen der CNs definiert?
Member: DRIV3R
DRIV3R Sep 15, 2023 at 11:39:28 (UTC)
Goto Top
Ja hab ich.
Brauche ich eventuell noch eine spezielle IPSec Rule in der Firewall?
Member: DRIV3R
DRIV3R Sep 16, 2023 at 06:46:53 (UTC)
Goto Top
Aqui, ich schulde dir ein Bierchen.

Nachdem ich nun den Prozess dreimal neu gemacht habe hab ich den Fehler gefunden. Es war tatsächlich der common name. face-smile

Noch mal ne Frage zur Firewall.
Ich hab eine Testregel Allow IPsec to any.
Und in Phase 2 hab ich LAN Subnet.
Aber ein Ping zum LAN Subnet aus dem VPN geht nicht.
Hab ich ne Regel vergessen?

Grüße
Timo
Member: aqui
aqui Sep 16, 2023 updated at 07:30:10 (UTC)
Goto Top
Hi Timo!
Kleine Ursache große.... aber klasse das du das gefixt bekommen hast. 👍 👏
Generell kann man sagen wenn der Debug Output oben bei der Zerifikatsabfrage hängen bleibt und es gar nicht zur MSCHAPv2 Userabfrage kommt stimmt oft irgendwas mit dem Zertifikat und dann meistens mit dem CN dadrin, nicht.
Ich hab eine Testregel Allow IPsec to any.
WO?? 🤔
In der Regel braucht es keine Regeln, weil die pfSense und auch die OPNsense diese am WAN Port immer automatisch erstellen bei IKEv2. Zumindestens bei der OPNsense kanst du das im Regelwerk hinten mit Klick auf die Info für die Autorules die unterdrückt werden dir anzeigen lassen. face-wink
In der Beziehung wäre deine o.a. Regel falsch , da überflüssig und auch sicherheitstechnsich kontraproduktiv. Solltest du also besser wieder löschen!
Schreibst ja leider nicht wo du diese Regel gesetzt hast. face-sad
Aber ein Ping zum LAN Subnet aus dem VPN geht nicht.
Sind das Windows Rechner die du anpingst??
Wenn ja, gilt das hier auch für dich.
Member: DRIV3R
DRIV3R Sep 16, 2023 at 07:49:28 (UTC)
Goto Top
Hi aqui,

die grundsätzlichen Ports sind auch automatisch freigegeben worden.
Ich komm aber nicht in mein lokales Netz.
Deshalb habe ich unter dem neuen Punkt der Firewall IPSec eine allow all gemacht. Ich möchte ja das ich von außen alle Geräte usw. erreichen kann.

Es gelingt mir noch nicht mal die OPNSense zu erreichen auf dem LAN Adapter 192.168.20.1
Auch per Ping nicht.

Bin aber sauber von außen connected und bekomme auch eine IP Adresse aus dem Bereich 10.99.99.0/24 den ich gewählt habe.
Member: DRIV3R
DRIV3R Sep 16, 2023 at 07:53:38 (UTC)
Goto Top
Pass Regel
img_1896.
Member: DRIV3R
DRIV3R Sep 18, 2023 at 16:01:40 (UTC)
Goto Top
Inzwischen habe ich mal eine andere Regel getestet. Damit bekomme ich jetzt problemlos datentransfer von draußen auf alle Geräte in meinem Netzwerk.

Ist das nun einen Schneunentor? Sollte ich dir Regel feiner definieren?
Oder reicht es so, da ich ja ohne CA und Username Passwort kombi eh nicht von draußen rein komme?

vpn rule

Grüße
Timo
Member: aqui
aqui Sep 18, 2023 updated at 17:11:24 (UTC)
Goto Top
Ist das nun einen Schneunentor? Sollte ich dir Regel feiner definieren?
OK, dann hattest du die Regel am Tunnelinterface selber vergessen einzurichten. Gut, das ist dann klar das das nicht klappen kann, denn damit blockt die Firewall, wie üblich, alles.
Any, Any ist erstmal Scheunentor aber jetzt auch nicht tragisch da es ja nur ein internes, von dir kontrollieres Interface ist.
Wenn du es etwas sicherer machen willst und das 10.99.99.0/24 er Netz das interne Tunnelnetz für die VPN Clients ist, änderst du die o.a. Regel noch um statt Source "*" dann 10.99.99.0 Mask: /24 was dann dort nur Traffic mit 10.99.99.0er Absender IPs passieren lässt.
Wenn du das VPN Client Netz einzig nur für den Zugang auf deine internen LANs begrenzen willst dann kannst du die Regel noch weiter dichtziehen
PASS Source: 10.99.99.0 Mask: /24 Destination: 192.168.0.0 Mask: /16
Was dann nur Traffic von den VPN Clients in alle 192.168er Netze erlaubt.
Wenn du den VPN Zugang aber auch für die Clients zum sicheren Internet Zugang an öffentlichen Hostspots, Hotelnetzen usw. nutzen willst dann muss die Destination natürlich weiter "Any" bleiben.
Member: DRIV3R
DRIV3R Sep 18, 2023 at 18:06:35 (UTC)
Goto Top
Fein fein.
Dann bin ich auf dem richtigen Weg, danke.

Noch mal kurz zum sicheren Internetzugang. Die Konfig die ich jetzt laufen habe tunnelt ja nur den „privaten“ Traffic. Wenn ich z.B. im Internet surfe mit verbundenen VPN, dann geht das am VPN vorbei.

Ist das folgender Hinweis aus deinem Tut?

Wer den gesamten VPN Client Traffic in den Tunnel routen will (Gateway Redirect), setzt “Local Network” auf Network, und gibt 0.0.0.0 als Adresse und /0 für das Subnet ein!
Member: aqui
aqui Sep 18, 2023, updated at Sep 29, 2023 at 17:10:42 (UTC)
Goto Top
Wenn ich z.B. im Internet surfe mit verbundenen VPN, dann geht das am VPN vorbei.
Nein, nicht zwingend!
Es hängt davon ab ob du Split Tunneling machst oder Gateway Redirect.
Beim Windows Client kannst du das z.B. auch am Client einstellen:
wincli.
Ist das folgender Hinweis aus deinem Tut?
Jepp, ganz genau.
Bei einigen Clients ist das aber nicht customizebar. iPhones machen immer Redirect.

Viel wichtiger ist das du die Krypto Hardware Beschleunigung (AES NI) bei VPN in deinem Proxmox zwingend an die Firewall VM durchreichen solltest!!
AES-NI bei Proxmox auf VM durchreichen
GermansolvedQuestionVPN