Zitat von "Sabine"Hi, habe eben mal aus Versehen das komplette Firewall Modul gelöscht !! :?
Ich weis nicht ?
Irgendwie finde ich die efw doch besser ...... :idea:
Einfacher! Das ist EFW auf jeden Fall.
Zitat von "Sabine"Hi, habe eben mal aus Versehen das komplette Firewall Modul gelöscht !! :?
Ich weis nicht ?
Irgendwie finde ich die efw doch besser ...... :idea:
Einfacher! Das ist EFW auf jeden Fall.
Das muss man dem Endian lassen, stabil läuft er. Seit fast 1.5 Jahren mit nur einem Reboot.
Mal sehen wie lange es mit Pfs gut geht.
Es gibt auf jeden Fall Firewall-Rules für PPTP- und OpenVPN-Networks. Damit lässt sich das bestimmt einstellen.
IPsec muß ich noch durch, sieht aber auf den ersten Blick auch besser als beim Endian aus.
Und die OpenVPN-Konfi bei Endian war ja ein Graus wenn du Zertifikate nutzen wolltest.
Beim PS ists ein Kinderspiel wenn man OpenVPN-Export-Plugin dazu installiert.
Ja, jetzt nach zwei Wochen pfsensen muss ich leider zu dem Schluß kommen, dass der echt besser ist als endian.
Bietet mehr Möglichkeiten und sogar bessere. Nutzt nicht so viel Ressourcen, sieht nur nicht so hübsch aus.
Auch alles super dokumentiert.
Schade, bye bye endian!
Die Erstverbindung in der Standartausprägung, also mit 3DES und PSK funktioniert tadellos.
Ist in Endian als Roadwarrior konfiguriert.
Eine nochmalige Verbindung nach dem normalen Sessionende kann nicht wieder aufgebaut werden. Dieses funktioniert nur nach Neustart/Reset des Endian. Die Verbindung scheint in der Phase 2 (Sicherungs-Parameter für den Datenkanal) nicht neu aufgebaut werden zu können.
Versuche mit Shrewsoft laufen einwandfrei. Aber der Funkwerk scheint ein Problem damit zu haben.
Proxy mit LDAP geht wohl über zusätzliche Pakete.
Die sind auch schnell integriert. Aber konfigurieren ist ja der Hammer.
Endian ist das echt simpel.
Danke für eure Beiträge!
Unternehmenseinsatz ist schon angedacht. Bisher läuft ja Endian 2.41 ganz sauber.
Aber IPsec klapt nicht immer und PPTP gibts nicht.
TrafficShaper auch nicht.
Hat jemand Erfahrungen mit PFsense?
Sieht zwar auf den ersten Blick komplizierter aus als Endian, aber irgendwie auch besser.
Hmm. Denke schon. Schaue gleich mal nach.
Ist denn 2.4.1 nicht die aktuelle Fassung?
Mit Endian 2.3 habe ich IPsec nie an den Start bekommen.
Mit 2.41 läuft es ganz gut, wobei ich einen PreSharedKey und keine Zertifikate nutze.
Die habe ich lediglich unter OpenVPN eingesetzt und das war richtig viel Arbeit, siehe hier:
https://www.efw-forum.de/www/forum/view…hp?f=9&t=66
Ähnlich sollte es auch mit IPsec gehen.
Nutze Endian 2.4.1
Baue mit einem FunkwerkRouter eine Verbindung zu Endian ala Roadwarrior mit PReSharedKey auf.
Funktioniert auch super.
Zwecks Vermeidung DeadPeer wird auch fleissig vom Funkwerk gepingt.
Nach ca. 1h wird der Tunnel abgebaut und lt. Protokoll sieht das so aus:
Feb 24 16:03:04 pluto[32260] "testRoad"[1] 80.153.182.222 #3: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Feb 24 16:03:04 pluto[32260] "testRoad"[1] 80.153.182.222 #3: ignoring unknown Vendor ID payload [810fa565f8ab14369105d706fbd57279]
Feb 24 16:03:04 pluto[32260] "testRoad"[1] 80.153.182.222 #3: ignoring unknown Vendor ID payload [5cbeb399eb835a7d7a2eb495905db061]
Feb 24 16:03:04 pluto[32260] "testRoad"[1] 80.153.182.222 #3: ignoring unknown Vendor ID payload [0048e2270bea8395ed778d343cc2a076]
Feb 24 16:03:04 pluto[32260] "testRoad"[1] 80.153.182.222 #3: initiating Main Mode to replace #1
Feb 24 16:01:02 fcron[8867] Job [ -x /bin/run-parts ] && run-parts --report /etc/cron.hourly completed
Feb 24 16:01:00 fcron[8867] Job [ -x /bin/run-parts ] && run-parts --report /etc/cron.hourly started for user root (pid 8868)
Lt. Funkwerk scheitert danach ein erneuter Verbindungsaufbau in Phase 2.
Hängt das damit zusammen, dass die IKE-Lebensdauer nur eine Stunde beträgt? ESP-Lebensdauer sind 8 Stunden.
Wir haben zwei DSL-Leitungen. Einmal A-DSL (bislang nicht über ENDIAN) und einmal S-DSL für VPN über Endian.
Am Main-Uplink RED hängt das S-DSL für VPN usw.
Wenn ich über einen zweiten Uplink RED die A-DSL-Leitung verbinde, kann ich über QOS die HTTP-Anfragen aus dem LAN, also von GrÜN über diesen Uplink steuern?
Es geht mir primär darum, dass Downloads aus dem LAN nicht die VPN-Sitzungen behindern.
Zitat von "horst"Zitat:
Frage:
Das gleiche Problem habe ich auch. Ich habe das Zertifikat unter Windows XP erstellt. Das Zertifikat scheint ok (ist größer als 0KB). Das Kennwort habe ich auf "123456" gesetzt (also keine Zeichen die Probleme machen könnten. Wofür ist eingetlich dieses "Export-Passwort" nachdem zum Schluss der Zertifikaterstellung gefragt wird? Das Challange-Passwort wird ja vorher auch schon abgefragt!?Hat jemand eine Ahnung, was ich falsch gemacht haben könnte?
Ich wäre über jede Info dankbar!
Horst
Da ich das Zertifikat in Verbindung mit einem Login nutze, habe ich auf ein EIGENES Kennwort FÜR das Zertifikat verzichtet. Gab auch nur Problem damit - wie von dir geschildert.
Stimmt. Die Antwort bin ich noch schuldig.
Bei einem Update von 2.3 auf 2.41 erfolgt dieser Fehler nicht mehr.
Während es bei 2.4 eigentlich nur Fehler gab, verlief 2.41 geradezu perfekt.
IPsec klappt wunderbar, die Logs werden mitgenommen, die Graphen laufen einwandfrei.
Nur die Firewall-Diagrams öffnen sich irgendwie nicht, wenn man auf die Thumps klickt.
Und die manuellen backups haken auch, wobei es die autom. problemlos tun.
Mit dieser Shresoft-Config bekomme ich eine Verbindung von meinem Win7 Client zum Endian hin.
Im Endian unter Firewall/NAT/Source-NAT musste ich auch ALLE an GRÜN NATen.
n:version:2
n:network-ike-port:500
n:network-mtu-size:1380
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:client-banner-enable:0
n:network-notify-enable:0
n:client-wins-used:0
n:client-wins-auto:0
n:client-dns-used:0
n:client-dns-auto:0
n:client-splitdns-used:0
n:client-splitdns-auto:0
n:phase1-dhgroup:2
n:phase1-life-secs:3600
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:1
n:client-addr-auto:0
s:client-ip-addr:192.xxxx
s:client-ip-mask:255.255.255.0
s:network-host:92.xxxx
s:client-auto-mode:disabled
s:client-iface:direct
s:network-natt-mode:enable
s:network-frag-mode:disable
s:auth-method:mutual-psk
s:ident-client-type:fqdn
s:ident-server-type:fqdn
s:ident-client-data:1234567
s:ident-server-data:12345678
b:auth-mutual-psk:MTIz
s:phase1-exchange:aggressive
s:phase1-cipher:3des
s:phase1-hash:md5
s:phase2-transform:esp-3des
s:phase2-hmac:sha1
s:ipcomp-transform:disabled
n:phase2-pfsgroup:2
Was heisst das?
initial Aggressive Mode message from 8x.13x.4x.19x but no (wildcard) connection has been configured with policy=PSK+AGGRESSIVE
Ok - jetzt klappt es.
Source NAT ist das Stichwort. Habe eine Portweiterleitung für die Client-IP auf das grüne Netzwerk gebaut. Jetzt gehts!
Das gleiche Problem haben wir auch! Kann vom IPsec-Client zwar die Endian anpingen, aber nicht das Netztwerk dahinter. Habe schon zig Routen erstellt, Firewall-Regeln für VPN,System usw. Nichts!
Der Shrew-Soft-Client bietet m.E. die besten Möglichkeiten einen freien IPsec-Client zu konfigurieren. Aber selbst mit dem geht es nicht.