17
OPNsense VPN IPsec (received proposals unacceptable)
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
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 5370794975
Url: https://administrator.de/forum/opnsense-vpn-ipsec-received-proposals-unacceptable-5370794975.html
Ausgedruckt am: 22.12.2024 um 11:12 Uhr
17 Kommentare
Neuester Kommentar
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.
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:
Das vergleichst du jetzt einmal mit deinem obigen Screenshot!!
Finde den Fehler...!! 😉
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.
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:
Das vergleichst du jetzt einmal mit deinem obigen Screenshot!!
Finde den Fehler...!! 😉
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
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
Ich nehme alles zurück. Ich habe die OPNsense neu gestartet und teste gerade. Die proposals Meldung ist weg.
Falscher Alarm.
Es bleibt leider bei received proposals unacceptable
Es bleibt leider bei received proposals unacceptable
So, nach einigen Test bekomme ich nun tatsächlich ein "selected proposal".
Der Client (iPhone) connected aber nicht.
Es sieht nur wie folgt aus:
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
Sieht ja jetzt gut und richtig aus!
Verbindet aber nicht 
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.ä.
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.ä.
- Das CA Zertifikat (nicht Server!) hast du auf das iPhone importiert??
- Hast du auf dem iPhone als remote ID auch einen der CNs definiert?
Ja hab ich.
Brauche ich eventuell noch eine spezielle IPSec Rule in der Firewall?
Brauche ich eventuell noch eine spezielle IPSec Rule in der Firewall?
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.
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
Nachdem ich nun den Prozess dreimal neu gemacht habe hab ich den Fehler gefunden. Es war tatsächlich der common name.
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
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.
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.
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.
Wenn ja, gilt das hier auch für dich.
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.
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.
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.
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.
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.
Pass Regel
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?
Grüße
Timo
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?
Grüße
Timo
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.
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!
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!
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:
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
