29
PfSense 2.2.6 IPSec VPN Moblie Clients AES-128 nicht möglich?
Folgendes Setup:
PfSense mit Site2Site VPN zur Fritzbox und mobilen Clients (IPSec)
Phase 1 bei der Fritte ist mit AES-256 konfiguriert.
Phase 1 bei den Clients ist mit AES-128 konfiguriert.
Fehlermeldung der PfSense bei der Clienteinwahl: kein passendes Proposal. (Man kann sehen, dass StrongSwan AES-256 erwartet, trotz anderer Einstellung in der GUI.
Stelle ich den Client auf AES-256 klappt die Einwahl.
Stelle ich die Phase1 für die Site2Site Einwahl auf AES-128 klappt die Client-Einwahl auch wieder. Aber natürlich kann die FB mit dem Proposal dann nichts anfangen,
Es sieht also so aus, als ob die PfSense die Proposals für die Phase-1 der Clienteinwahl aus den Settings der anderen Phase1 ausliest.
Merkwürdig, oder?
Hat noch jemand diese Probleme?
PfSense mit Site2Site VPN zur Fritzbox und mobilen Clients (IPSec)
Phase 1 bei der Fritte ist mit AES-256 konfiguriert.
Phase 1 bei den Clients ist mit AES-128 konfiguriert.
Fehlermeldung der PfSense bei der Clienteinwahl: kein passendes Proposal. (Man kann sehen, dass StrongSwan AES-256 erwartet, trotz anderer Einstellung in der GUI.
Stelle ich den Client auf AES-256 klappt die Einwahl.
Stelle ich die Phase1 für die Site2Site Einwahl auf AES-128 klappt die Client-Einwahl auch wieder. Aber natürlich kann die FB mit dem Proposal dann nichts anfangen,
Es sieht also so aus, als ob die PfSense die Proposals für die Phase-1 der Clienteinwahl aus den Settings der anderen Phase1 ausliest.
Merkwürdig, oder?
Hat noch jemand diese Probleme?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 297660
Url: https://administrator.de/forum/pfsense-2-2-6-ipsec-vpn-moblie-clients-aes-128-nicht-moeglich-297660.html
Ausgedruckt am: 10.04.2025 um 12:04 Uhr
29 Kommentare
Neuester Kommentar
Hallo,
ist kommt sie eben wieder schnell zu Stande.
Gruß
Dobby
Stelle ich den Client auf AES-256 klappt die Einwahl.
Weil vorher die Einwahl funktioniert hat, und die Lease der Sitzung wohl noch aktivist kommt sie eben wieder schnell zu Stande.
Gruß
Dobby
Eben nicht. Die Clienteinwahl hatte ja nicht geklappt. Oder versteh ich dich falsxh?
Rennt die pfSense auf einem ALIX Bord mit dedizierter Crypto HW sprich 2Dxx Boards ?
Wenn das der Fall ist und diese Hardware, wie es sein sollte, in den Miscellaneous Settings aktiviert wurde, dann supportet die pfSense nur AES 128.
Bei allen anderen Boards z.B. APU1D usw. entfällt das natürlich.
Du kannst sonst den Dubug Lever auf der pfSense in den "Advanced Settings" unter IPsec hochsetzen um einen detailiertern Debug Output im Syslog zu bekommen.
Wenn das der Fall ist und diese Hardware, wie es sein sollte, in den Miscellaneous Settings aktiviert wurde, dann supportet die pfSense nur AES 128.
Bei allen anderen Boards z.B. APU1D usw. entfällt das natürlich.
Du kannst sonst den Dubug Lever auf der pfSense in den "Advanced Settings" unter IPsec hochsetzen um einen detailiertern Debug Output im Syslog zu bekommen.
@aqui: Die PfSense rennt wie beim mir (intern) immer auf einem FSC S400.
Ich stell den Duduk-Level nochmal höher, aber der Fehler ist ja klar definiert: Sie erwartet AES-256 trotz eingestelltem AES-128. Offenbar werden aktuell verschiedene Einstellungen für verschiedene Interfaces nicht unterstützt. (?)
Magst Du das mal nachstellen ob das reproduzierbar ist?
Hat denn wirklich keiner eine PfSense im Einsatz, die verschiedene Algorithmen für die statische und die mobile Verbindung verwendet?
Schön ist aber am StrongSwan, dass er das Proposal der Gegenseite im Log abbildet und ich so endlich mal erfahren konnte, was die Frittzbox mit meinem Setting real supportet. Da ist AES-128 übrigens dabei, auch wenn keine Verbindung zustandekommt.
Bug
Ich stell den Duduk-Level nochmal höher,
aber der Fehler ist ja klar definiert: Sie erwartet AES-256 trotz eingestelltem AES-128. Offenbar werden aktuell verschiedene Einstellungen für verschiedene Interfaces nicht unterstützt. (?)Magst Du das mal nachstellen ob das reproduzierbar ist?
Hat denn wirklich keiner eine PfSense im Einsatz, die verschiedene Algorithmen für die statische und die mobile Verbindung verwendet?
Schön ist aber am StrongSwan, dass er das Proposal der Gegenseite im Log abbildet und ich so endlich mal erfahren konnte, was die Frittzbox mit meinem Setting real supportet. Da ist AES-128 übrigens dabei, auch wenn keine Verbindung zustandekommt.
Bug
Mmmmhhh...wenn du AES-128 und AES-256 anhakst, dann sollte das Proposal eigentlich beide Optionen anbieten. Partner einigen sich dann immer auf das größte gemeinsame Vielfache.
Ich werde die pfSense im Praxistutorial mal für Client Dialin konfigurieren und dir dann berichten.
Ich werde die pfSense im Praxistutorial mal für Client Dialin konfigurieren und dir dann berichten.
Achtung: Site2Site AES-256 Client AES-128.
Berichte mal. Bin neugierig.
Berichte mal. Bin neugierig.
Och aqui... "Long time no see..."
Haste das mal getestet? Das ist noch immer ungelöst und da wir uns hier langsam zum deutschen pfSense Forum mausern...
Auf der 2.1.x mit Racoon ging das noch problemlos.
Und erzähl mir jetzt nix von 2.3 (oder hat sich die StrongSwan Version geändert?)
LG
Buc
Haste das mal getestet? Das ist noch immer ungelöst und da wir uns hier langsam zum deutschen pfSense Forum mausern...
Auf der 2.1.x mit Racoon ging das noch problemlos.
Und erzähl mir jetzt nix von 2.3
(oder hat sich die StrongSwan Version geändert?)LG
Buc
Nee... zu faul und wenig Zeit.... Mal sehen wenns regnet am Wochenende. 
Ich habe jetzt sogar ein freies APU1D jetzt zum Testen hier....
Ich habe jetzt sogar ein freies APU1D jetzt zum Testen hier....
Hi Aqui,
Leider habe ich beim Verbindungsversuch IPSec zwischen pfSense-Alix (AES-128, leider 256 nicht möglich) und einer Fritte 3370 das gleiche Problem wie @the-buccaneer. Alles Config-Versuche erfolglos.
Ich habe mir als "Alternative" zur Fritte nun einen E4200 in der Bucht ersteigert, um mit DD-WRT zu "kontern". Leider eine V2 erwischt und nix DD-WRT.
Bin nun an der Config für OpenWRT mit OpenVPN am "rummurksen", gestaltet sich schon fast wie "Fritzbox".
Gruß orcape
Ich habe jetzt sogar ein freies APU1D jetzt zum Testen hier....
Ja wie schön für Dich...Leider habe ich beim Verbindungsversuch IPSec zwischen pfSense-Alix (AES-128, leider 256 nicht möglich) und einer Fritte 3370 das gleiche Problem wie @the-buccaneer. Alles Config-Versuche erfolglos.
Ich habe mir als "Alternative" zur Fritte nun einen E4200 in der Bucht ersteigert, um mit DD-WRT zu "kontern". Leider eine V2 erwischt
und nix DD-WRT.Bin nun an der Config für OpenWRT mit OpenVPN am "rummurksen", gestaltet sich schon fast wie "Fritzbox".
Gruß orcape
Verbindungsversuch IPSec zwischen pfSense-Alix (AES-128, leider 256 nicht möglich)
Das ist leider etwas doppeldeutig... - Was meinst du Client VPN oder Site to Site ? Oder beides parallel ?
- Auf einem ALIX 2Dxx ist nur AES 128 möglich weil der interne Cryptochip nicht mehr kann. Das 2Dxx macht die Verschlüsselung sehr performant in HW. 256 geht mit dem APU1D aber fehlerlos, da in SW.
- Das es mit 128 klappt kannst du HIER ja sehen !
- AES 256 funktioniert aber mit APU1D, getestet mit dem latest 2.3.1_p1 Patch. (Site to Site zu Cisco)
Kollege Buc meint aber die Client VPN Seite bzw. das gleichzeitige Site to Site UND Client VPN auf einer Box denke ich.
Ich habe bis dato nur Site to Site getestet.
Richtig. Ich meinte (und meine) das gleichzeitige AES 256 auf einer site2site und ein AES 128 auf einer parallel installierten mobilen IPSec Einwahl.
Das klappt nicht mit der 2.2.6.
Der StrongSwan will auf beiden Connections dieselbe Verschlüsselung. Und denselben PSK. (Warum auch immer, sicher ein Bug)
Die FB sollte aber witzigerweise doch auch 128 bit unterstützen, wie ich aus den Aushandlungsprotokollen ershehen konnte, die ja in StrongSwan angezeigt werden. (mindestens auf der aktuellen Firmware)
Mein Tip (ungetestet) wäre also mal nur diese Verbindung auf AES128 laufen zu lassen. Debug-Level etwas hochstellen.
https://doc.pfsense.org/index.php/IPsec_Troubleshooting
und auch auf der Fritte mal sehen, was der fehler ist. Wenn es in Richtung "Hash-Fehler" geht, nochmal den PSK auf beiden Seiten eingeben.
Aber du weisst das... Welche PfSense, welche FB-Firmware etc.pp.
Das ist immer schon kompliziert genug, wenn man direkt vor den Kisten hockt. Aber ohne die kisten zu kennen, naja...
LG
Buc
Das klappt nicht mit der 2.2.6.
Der StrongSwan will auf beiden Connections dieselbe Verschlüsselung. Und denselben PSK. (Warum auch immer, sicher ein Bug)
Die FB sollte aber witzigerweise doch auch 128 bit unterstützen, wie ich aus den Aushandlungsprotokollen ershehen konnte, die ja in StrongSwan angezeigt werden. (mindestens auf der aktuellen Firmware)
Mein Tip (ungetestet) wäre also mal nur diese Verbindung auf AES128 laufen zu lassen. Debug-Level etwas hochstellen.
https://doc.pfsense.org/index.php/IPsec_Troubleshooting
und auch auf der Fritte mal sehen, was der fehler ist. Wenn es in Richtung "Hash-Fehler" geht, nochmal den PSK auf beiden Seiten eingeben.
Aber du weisst das... Welche PfSense, welche FB-Firmware etc.pp.
Das ist immer schon kompliziert genug, wenn man direkt vor den Kisten hockt. Aber ohne die kisten zu kennen, naja...
LG
Buc
Hi,
IPSec Site-to-Site Tunnel pfSense 2.3 zu Fritzbox 3370 FRITZ!OS:06.51
pfSense mit DSL feste-Ip, Fritzbox web.vodafone.de über Mobilfunk, HSPA IP-Adresse: 100.64.xxx.122, DynDNS
Einstellungen lt.Tutorial @aqui.
Gruß orcape
IPSec Site-to-Site Tunnel pfSense 2.3 zu Fritzbox 3370 FRITZ!OS:06.51
pfSense mit DSL feste-Ip, Fritzbox web.vodafone.de über Mobilfunk, HSPA IP-Adresse: 100.64.xxx.122, DynDNS
Einstellungen lt.Tutorial @aqui.
Gruß orcape
So und wenn du mir jetzt noch sagst, wie die Fehlermeldungen auf der Fritte und der pfSense lauten, könnte ich mal versuchen, das nachzustellen... oder dir einen sonstigen Tip geben evtl. vielleicht.
Und am besten noch die Konfigurationsdaten dazu zum abgleichen...
Buc
Und am besten noch die Konfigurationsdaten dazu zum abgleichen...
Buc
Fritte
pfsense Logs...
Vor der pfSense ist eine 7490 in der Routerkaskade, Netz 192.168.219.0/24. IPSec ist da per Portforwarding freigeschaltet.
vpncfg {
connections {
enabled = yes;
editable = yes;
conn_type = conntype_out;
name = "Achilleus";
boxuser_id = 0;
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = no;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 85.183.xx.xx;
remote_virtualip = 0.0.0.0;
localid {
fqdn = "pixcvb8.ddns.net";
}
remoteid {
ipaddr = 85.183.xx.xx;
}
keepalive_ip = 192.168.155.1;
localid {
key_id = ".............";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "...................";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = yes;
phase2localid {
ipnet {
ipaddr = 192.168.33.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 192.168.155.0;
mask = 0.0.0.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
accesslist = "permit ip any 192.168.155.0 255.255.255.0";
}
ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",
"udp 0.0.0.0:4500 0.0.0.0:4500";
} Jun 3 20:43:15 charon 09[IKE] <1869> received XAuth vendor ID
Jun 3 20:43:15 charon 09[IKE] <1869> received DPD vendor ID
Jun 3 20:43:15 charon 09[IKE] <1869> received NAT-T (RFC 3947) vendor ID
Jun 3 20:43:15 charon 09[IKE] <1869> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 3 20:43:15 charon 09[IKE] <1869> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 3 20:43:15 charon 09[ENC] <1869> received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Jun 3 20:43:15 charon 09[IKE] <1869> 109.43.3.18 is initiating a Aggressive Mode IKE_SA
Jun 3 20:43:16 charon 09[CFG] <1869> looking for pre-shared key peer configs matching 192.168.219.2...109.43.3.18[achilleus]
Jun 3 20:43:16 charon 09[IKE] <1869> found 1 matching config, but none allows pre-shared key authentication using Aggressive Mode
Jun 3 20:43:16 charon 09[ENC] <1869> generating INFORMATIONAL_V1 request 2891960927 [ N(AUTH_FAILED) ]
Jun 3 20:43:16 charon 09[NET] <1869> sending packet: from 192.168.219.2[500] to 109.43.3.18[4542] (56 bytes)
Jun 3 20:43:20 charon 09[NET] <1870> received packet: from 109.43.3.18[4542] to 192.168.219.2[500] (665 bytes)
Jun 3 20:43:20 charon 09[ENC] <1870> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 3 20:43:20 charon 09[IKE] <1870> received XAuth vendor ID
Jun 3 20:43:20 charon 09[IKE] <1870> received DPD vendor ID
Jun 3 20:43:20 charon 09[IKE] <1870> received NAT-T (RFC 3947) vendor ID
Jun 3 20:43:20 charon 09[IKE] <1870> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 3 20:43:20 charon 09[IKE] <1870> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 3 20:43:20 charon 09[ENC] <1870> received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Jun 3 20:43:20 charon 09[IKE] <1870> 109.43.3.18 is initiating a Aggressive Mode IKE_SA
Jun 3 20:43:21 charon 09[CFG] <1870> looking for pre-shared key peer configs matching 192.168.219.2...109.43.3.18[achilleus]
Jun 3 20:43:21 charon 09[IKE] <1870> found 1 matching config, but none allows pre-shared key authentication using Aggressive Mode
Jun 3 20:43:21 charon 09[ENC] <1870> generating INFORMATIONAL_V1 request 1683123830 [ N(AUTH_FAILED) ]
Jun 3 20:43:21 charon 09[NET] <1870> sending packet: from 192.168.219.2[500] to 109.43.3.18[4542] (56 bytes)
Jun 3 20:43:25 charon 09[NET] <1871> received packet: from 109.43.3.18[4542] to 192.168.219.2[500] (665 bytes)
Jun 3 20:43:25 charon 09[ENC] <1871> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 3 20:43:25 charon 09[IKE] <1871> received XAuth vendor ID
Jun 3 20:43:25 charon 09[IKE] <1871> received DPD vendor ID
Jun 3 20:43:25 charon 09[IKE] <1871> received NAT-T (RFC 3947) vendor ID
Jun 3 20:43:25 charon 09[IKE] <1871> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 3 20:43:25 charon 09[IKE] <1871> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 3 20:43:25 charon 09[ENC] <1871> received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Jun 3 20:43:25 charon 09[IKE] <1871> 109.43.3.18 is initiating a Aggressive Mode IKE_SA
Jun 3 20:43:26 charon 09[CFG] <1871> looking for pre-shared key peer configs matching 192.168.219.2...109.43.3.18[achilleus]
Jun 3 20:43:26 charon 09[IKE] <1871> found 1 matching config, but none allows pre-shared key authentication using Aggressive Mode
Jun 3 20:43:26 charon 09[ENC] <1871> generating INFORMATIONAL_V1 request 1737712532 [ N(AUTH_FAILED) ]
Jun 3 20:43:26 charon 09[NET] <1871> sending packet: from 192.168.219.2[500] to 109.43.3.18[4542] (56 bytes)
Jun 3 20:43:30 charon 09[NET] <1872> received packet: from 109.43.3.18[4542] to 192.168.219.2[500] (665 bytes)
Jun 3 20:43:30 charon 09[ENC] <1872> parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
Jun 3 20:43:30 charon 09[IKE] <1872> received XAuth vendor ID
Jun 3 20:43:30 charon 09[IKE] <1872> received DPD vendor ID
Jun 3 20:43:30 charon 09[IKE] <1872> received NAT-T (RFC 3947) vendor ID
Jun 3 20:43:30 charon 09[IKE] <1872> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jun 3 20:43:30 charon 09[IKE] <1872> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Jun 3 20:43:30 charon 09[ENC] <1872> received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
Jun 3 20:43:30 charon 09[IKE] <1872> 109.43.3.18 is initiating a Aggressive Mode IKE_SA
Jun 3 20:43:31 charon 09[CFG] <1872> looking for pre-shared key peer configs matching 192.168.219.2...109.43.3.18[achilleus]
Jun 3 20:43:31 charon 09[IKE] <1872> found 1 matching config, but none allows pre-shared key authentication using Aggressive Mode
Jun 3 20:43:31 charon 09[ENC] <1872> generating INFORMATIONAL_V1 request 141740931 [ N(AUTH_FAILED) ]
Jun 3 20:43:31 charon 09[NET] <1872> sending packet: from 192.168.219.2[500] to 109.43.3.18[4542] (56 bytes)
Jun 3 20:43:16 charon 09[IKE] <1869> found 1 matching config, but none allows pre-shared key authentication using Aggressive Mode
Bitte checke in der PfSense Phase 1
Authentication Method. "Mutual PSK"
Negotiation Mode "Aggressive"
Ich habe mit der FB immer PFS im Einsatz. Z.B.: esp-all-all/ah-none/comp-all/pfs
Das ist in der PfSense in derPhase 2 zu konfigurieren mit PFS Group 2 und Lifetime 3600 sec.
Edith: Die Fritte liefert dir unter System auch Fehlermeldungen.
Und unter always_renew kannst du ruhig bei einer Site2Site Verbindung yes setzen.
Und dass das gesamte Internet via VPN über die Fritte erreichbar ist, ist gewollt?
Buc
Ausserdem fällt mir auf: Bei mir steht IMMER in der fb.cfg:
conn_type = conntype_lan
Bitte checke in der PfSense Phase 1
Authentication Method. "Mutual PSK"
Negotiation Mode "Aggressive"
Ich habe mit der FB immer PFS im Einsatz. Z.B.: esp-all-all/ah-none/comp-all/pfs
Das ist in der PfSense in derPhase 2 zu konfigurieren mit PFS Group 2 und Lifetime 3600 sec.
Edith: Die Fritte liefert dir unter System auch Fehlermeldungen.
Und unter always_renew kannst du ruhig bei einer Site2Site Verbindung yes setzen.
Und dass das gesamte Internet via VPN über die Fritte erreichbar ist, ist gewollt?
Buc
Ausserdem fällt mir auf: Bei mir steht IMMER in der fb.cfg:
conn_type = conntype_lan
Ich habe mit der FB immer PFS im Einsatz. Z.B.: esp-all-all/ah-none/comp-all/pfs
conn_type = conntype_lan
always_renew = yes;
Habe ich geändert, einzig verbliebene Fehlermeldung auf der pfSense.....conn_type = conntype_lan
always_renew = yes;
generating INFORMATIONAL_V1 request 3928527701 [ N(AUTH_FAILED) ] VPN-Fehler: Achilleus, IKE-Error 0x203f [2 Meldungen seit 04.06.16 09:38:35]Und dass das gesamte Internet via VPN über die Fritte erreichbar ist, ist gewollt?
Nicht wirklich.use_nat_t = no;
NAT Traversal sollte eigentlich immer an sein !
@orcape
Kommt der Tunnel zustande und kannst du darüber pingen ?
Und...2te Frage: Hast du noch die nackte 2.3 oder schon die aktuelle 2.3.1 mit dem P1 Patch (2.3.1_p1) ??
@orcape
Kommt der Tunnel zustande und kannst du darüber pingen ?
Und...2te Frage: Hast du noch die nackte 2.3 oder schon die aktuelle 2.3.1 mit dem P1 Patch (2.3.1_p1) ??
NAT Traversal sollte eigentlich immer an sein !
Ist wieder aktiv.Kommt der Tunnel zustande und kannst du darüber pingen ?
Nein.
Und...2te Frage: Hast du noch die nackte 2.3 oder schon die aktuelle 2.3.1 mit dem P1 Patch (2.3.1_p1) ??
2.3
Ooops...liegt das jetzt am Krypto Set oder warum nicht ??
Irgendwelche relevanten Error Meldungen von der FB und/oder pfSense Seite ?
Installier mal den latest Patch.
Irgendwelche relevanten Error Meldungen von der FB und/oder pfSense Seite ?
Installier mal den latest Patch.
Ooops...liegt das jetzt am Krypto Set oder warum nicht ??
Nun, ich geh mal davon aus, das Du hier wohl nicht unrecht hast.Seit 2.3 tut sich die pfSense auf dem ALIX mehr als schwer, was Änderungen per GUI betrifft.
Ich greife z.Zt. per OpenVPN auf die pf zu und da ist eine Änderung mehr wie zähflüssig.
Es laufen 4 OVPN Tunnel drauf. Ich glaube schon fast, das das Teil seit 2.3 etwas überfordert ist.
Habe gerade auf 2.3.1 aktualisiert. War wohl keine so blendende Idee.
Drei meiner Tunnel, alles Site-to-Site (AES-128-CBC und BF-CBC) sind mit "Krypto Problemen" ausgestiegen. Einzig der Linux-Client zur pfSense funktioniert noch. Welchem Umstand das nun wieder zu verdanken ist? Dem ALIX oder der Tatsache das 2.3.1 noch nicht "reif" ist für die Praxis?
Drei meiner Tunnel, alles Site-to-Site (AES-128-CBC und BF-CBC) sind mit "Krypto Problemen" ausgestiegen. Einzig der Linux-Client zur pfSense funktioniert noch. Welchem Umstand das nun wieder zu verdanken ist? Dem ALIX oder der Tatsache das 2.3.1 noch nicht "reif" ist für die Praxis?
PfSense aktualisieren? Hihii.
Aktuell wohl nicht sooo stabil.
Mein Vorschlag: Wenn du nicht die 2.3.x aus irgendeinem Grund brauchst / willst, nimm eine saubere Neuinstallation der 2.2.6 und spiele deine gesicherte Konfiguration ein.
2.1.x ist auch noch eine Wahl, wenn du bestimmte packages nicht brauchst und gewillt bist, diie Fixes händisch durchzusehen und eine Entscheidung zur Sicherheit zu treffen.
Das Einspielen der gesicherten Konfig. funktioniert nämlich seit jeher stabil...
Lösche die IPSec VPN Verbindungen. (Alle!)
Starte neu.
Danach neu anlegen, wie beschrieben und empfohlen.
Wenn du da keinen Fehler einbaust rennt das auch mit der Fritte auf AES-128.
Fast sicher.
OVPN ist wohl etwas CPU--lastiger als IPSec. Nun gut. Also 2.2.x und fertsch.
Buc
Hihii. Aktuell wohl nicht sooo stabil.
Mein Vorschlag: Wenn du nicht die 2.3.x aus irgendeinem Grund brauchst / willst, nimm eine saubere Neuinstallation der 2.2.6 und spiele deine gesicherte Konfiguration ein.
2.1.x ist auch noch eine Wahl, wenn du bestimmte packages nicht brauchst und gewillt bist, diie Fixes händisch durchzusehen und eine Entscheidung zur Sicherheit zu treffen.
Das Einspielen der gesicherten Konfig. funktioniert nämlich seit jeher stabil...
Lösche die IPSec VPN Verbindungen. (Alle!)
Starte neu.
Danach neu anlegen, wie beschrieben und empfohlen.
Wenn du da keinen Fehler einbaust rennt das auch mit der Fritte auf AES-128.
Fast sicher.
OVPN ist wohl etwas CPU--lastiger als IPSec. Nun gut. Also 2.2.x und fertsch.
Buc
Danke für die Info. Die CPU-Last auf dem ALIX spricht dann auch Bände. Also, return to 2.2.6 und für die Zukunft dann mal eine andere Hardware für die pfSense, denn das ALIX ist bei der Anzahl der Tunnel wohl schon etwas überfordert.
Gruß orcape
Gruß orcape
Hallo buccaneer,
" Richtig. Ich meinte (und meine) das gleichzeitige AES 256 auf einer site2site und ein AES 128 auf einer parallel installierten mobilen IPSec Einwahl. Das klappt nicht mit der 2.2.6. Der StrongSwan will auf beiden Connections dieselbe Verschlüsselung. Und denselben PSK. (Warum auch immer, sicher ein Bug)"
Um das bei der Pfsense zu testen, habe ich folgenden Aufbau benutzt:
Der Linux-Server (Debian/Strongswan 5.2.1) und die Pfsense (2.2.6) sind in VirtualBox, der Cisco-Router in GNS3 installiert. Der Client ist mein PC und R1 ist mein physikalischer Router mit NAT-Loopback. Die Captures habe ich an der Pfsense gemacht.
Verbindungsaufbau mit Shrew:
Verbindungsaufbau mit Linux/Cisco:
Bei beiden Verbindungen habe ich einen anderen Pre-shared Key. Wenn du also schon eine funktionierende Verbindung mit der Fritzbox herstellen kannst, müsste das mit der Clienteinwahl auch funktionieren.
BB
" Richtig. Ich meinte (und meine) das gleichzeitige AES 256 auf einer site2site und ein AES 128 auf einer parallel installierten mobilen IPSec Einwahl. Das klappt nicht mit der 2.2.6. Der StrongSwan will auf beiden Connections dieselbe Verschlüsselung. Und denselben PSK. (Warum auch immer, sicher ein Bug)"
Um das bei der Pfsense zu testen, habe ich folgenden Aufbau benutzt:
Der Linux-Server (Debian/Strongswan 5.2.1) und die Pfsense (2.2.6) sind in VirtualBox, der Cisco-Router in GNS3 installiert. Der Client ist mein PC und R1 ist mein physikalischer Router mit NAT-Loopback. Die Captures habe ich an der Pfsense gemacht.
Verbindungsaufbau mit Shrew:
Verbindungsaufbau mit Linux/Cisco:
Bei beiden Verbindungen habe ich einen anderen Pre-shared Key. Wenn du also schon eine funktionierende Verbindung mit der Fritzbox herstellen kannst, müsste das mit der Clienteinwahl auch funktionieren.
BB
denn das ALIX ist bei der Anzahl der Tunnel wohl schon etwas überfordert.
Bitte welche Alix HW meinst du denn ?? 2Dxx Modelle oder das APU1 ?? Da ist ja ein erheblicher Unterschied !Alix ist ja nun nicht gleich Alix...
Bitte welche Alix HW meinst du denn ??
Na das 2D13, der Nachfolger APU sollte ja etwas mehr Reserven haben. Ich glaube nur, das ich mir das Teil mit Upgrade auf 2.3.1 in Sachen VPN fast komplett "totgelegt" habe. Der letzte von 4 Tunneln (Admin-Tunnel), vom Laptop zur pfSense war auch kurzzeitig "außer Gefecht". Die CPU-Anzeige pendelt mir sehr ungewöhnlich, recht oft zwischen 90 und 100% und dann geht nicht mehr viel auf dem GUI. Da muss ich wohl mal auf 2.2.6 zurücksetzen und das Backup einspielen. Leider bin ich im Moment nicht vor Ort.Gruß orcape
in Sachen VPN fast komplett "totgelegt" habe.
Hast du unter Diagnosis --> nanao BSD die Flash Operation auf Read Write gestellt und den Haken gesetzt das das permanent so sein soll.Das verbessert die Antwortszeiten erheblich.
Die 2Ds haben aber das Problem das der Kryptochip intern nur max. 128 Bit supportet !
Hast du den in den Advanced Settings denn überhaupt aktiviert ?? (gxslb) und rebootet.
Das solltest du dringenst tun, ansonsten arbeitet das 2D13 rein in Software und logisch das es dann in die Knie geht.
Hast du den in den Advanced Settings denn überhaupt aktiviert ?? (gxslb) und rebootet.
Ja logisch, steht wohl so auch in Deinem Tutorial.Zur Zeit geht von remote erst mal gar nix mehr, muss ich mir vor Ort anschauen und erst mal das Backup einspielen.
Dazu brauche ich aber erst mal ein Tiefdruckgebiet, bei dem derzeitigen Wetter sitzt es sich auf der Terrasse im Garten bei einem Bier einfach besser.
Gruß orcape
Hallo BitBurg!
Herzlichsten Dank! Das ist eine sehr hilfreiche Rückmeldung, die man leider zu selten bekommt, da die meisten eben das eigene Setting nicht 1:1 übertragbar im Einsatz haben und die Kollegen (incl. mir) nur selten den Nerv haben, mal was nachzubauen...)
Glaube mir, ich habe damals (und aktuell gerade wieder) einiges probiert, da ich das so nicht erwartet hätte.
nun grenzt sich der Fehler immerhin ein auf die Übernahme der Einstellungen nach einem Update.
Ursprünglich trat das auf nach einem Upgrade von der 2.1.5 auf die 2.2.6 jetzt trat es auf nach Rücksichern der Settings auf eine Neuinstallation der 2.2.6.
Beidesmal ist das: Settings Racoon --> Settings StrongSwan.
Evtl. müssten die User mit den PSK's neu angelegt werden (?)
Oder das komplette IPSec?
Da AES-128 sowieso nur eingerichtet wurde um ein iPhone zu supporten, das anders gar nicht wollte und der User aktuell noch nicht gemotzt hat mal abwarten...
So ist es erstmal erledigt mit der Anpassung des Shrews auf AES-256. (Was ja eh besser ist)
Trotzdem: Gut zu wissen!!!
Und orcape: Wir reissen uns hier am Rechner den A... auf und du sitzt mit einem Bier im Liegestuhl???
Na gut, nicht ganz, aber so ähnlich...
Mach ma, jeden Tag ist grad Gewitter.
Buc
Herzlichsten Dank! Das ist eine sehr hilfreiche Rückmeldung, die man leider zu selten bekommt, da die meisten eben das eigene Setting nicht 1:1 übertragbar im Einsatz haben und die Kollegen (incl. mir) nur selten den Nerv haben, mal was nachzubauen...)
Glaube mir, ich habe damals (und aktuell gerade wieder) einiges probiert, da ich das so nicht erwartet hätte.
nun grenzt sich der Fehler immerhin ein auf die Übernahme der Einstellungen nach einem Update.
Ursprünglich trat das auf nach einem Upgrade von der 2.1.5 auf die 2.2.6 jetzt trat es auf nach Rücksichern der Settings auf eine Neuinstallation der 2.2.6.
Beidesmal ist das: Settings Racoon --> Settings StrongSwan.
Evtl. müssten die User mit den PSK's neu angelegt werden (?)
Oder das komplette IPSec?
Da AES-128 sowieso nur eingerichtet wurde um ein iPhone zu supporten, das anders gar nicht wollte und der User aktuell noch nicht gemotzt hat mal abwarten...
So ist es erstmal erledigt mit der Anpassung des Shrews auf AES-256. (Was ja eh besser ist)
Trotzdem: Gut zu wissen!!!
Und orcape: Wir reissen uns hier am Rechner den A... auf und du sitzt mit einem Bier im Liegestuhl???
Na gut, nicht ganz, aber so ähnlich...
Mach ma, jeden Tag ist grad Gewitter.
Buc
