Hallo wolfili,
wahrscheinlich hast du recht, aber wo liegt mein Fehler? Ich habe doch einen PSK vorgegeben und die Einstellungen wie in "Connecting to an Endian UTM Appliance Via IPsec XAUTH Using Android" durchgeführt.
Hallo wolfili,
wahrscheinlich hast du recht, aber wo liegt mein Fehler? Ich habe doch einen PSK vorgegeben und die Einstellungen wie in "Connecting to an Endian UTM Appliance Via IPsec XAUTH Using Android" durchgeführt.
Hallo,
ich möchte eine IPsec-Verbindung von einer Endian 3.2.5 Firewall zu einem Android Smartphone aufbauen. (Warum IPsec? Die Verbindung soll in einem anderen Anwendungsfall auch auf Custom-ROMs wie Sailfish und UbuntuTouch laufen. Und dort gibt es keine openVPN-App).
Nun gibt es eine schöne Client-Anleitung "Connecting to an Endian UTM Appliance Via IPsec XAUTH Using Android", aber eine entsprechende Anleitung zur Einstellung der Endian-Box finde ich nicht. Meine Versuche mit Hilfe einer PSK-Verschlüsselung eine roadwarrier Verbindung vom Smartphone aus aufzunehmen enden dort mit den Fehlermeldungen:
ipsec: 09[NET] received packet from 80.xxx.xxx.xxx[500] to 80.yyy.yyy.yyy[500] (476 bytes)
ipsec 09[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V ]
ipsec 09[IKE] received NAT-T (RFC 3947) vendor ID
ipsec 09[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
ipsec 09[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
ipsec 09[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
ipsec 09[IKE] received XAuth vendor ID
ipsec 09[IKE] received Cisco Unity vendor ID
ipsec 09[IKE] received FRAGMENTATION vendor ID
ipsec 09[IKE] received DPD vendor ID
ipsec 09[IKE] 80.xxx.xxx.xxx is initiating a Main Mode IKE_SA
ipsec 09[ENC] generating ID_PROT response 0 [ SA V V V V ]
ipsec: 09[NET] sending packet from 80.yyy.yyy.yyy[500] to 80.xxx.xxx.xxx[500] (156 bytes)
ipsec: 05[NET] received packet from 80.xxx.xxx.xxx[500] to 80.yyy.yyy.yyy[500] (228 bytes)
ipsec 05[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
ipsec 05[IKE] remote host is behind NAT
ipsec 05[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
ipsec: 05[NET] sending packet from 80.yyy.yyy.yyy[500] to 80.xxx.xxx.xxx[500] (244 bytes)
ipsec: 12[NET] received packet from 80.xxx.xxx.xxx[16305] to 80.yyy.yyy.yyy[4500] (92 bytes)
ipsec 12[ENC] parsed ID_PROT request 0 [ ID HASH ]
ipsec 12[CFG] looking for XAuthInitPSK peer configs matching 80.yyy.yyy.yyy...80.xxx.xxx.xxx[10.28.83.185]
ipsec 12[IKE] found 1 matching config, but none allows XAuthInitPSK authentication using Main Mode
ipsec 12[ENC] generating INFORMATIONAL_V1 request 4154280180 [ HASH N(AUTH_FAILED) ]
Kann mir jemand weiterhelfen?
Hallo,
hat jemand eine Information darüber ob und wann ein Software-Update zur Umgehung der neu aufgetauchten Sicherheitslücken Meltdown bzw. Spectre in Intel Prozessoren geplant ist?
Hallo,
nach dem Neustart eines Endian (2.5.2) sind leider alle Netzwerkdiagramme leer gefegt. Wir würden aber gerne diese Informationen trotz eines Neustarts weiterführen. Kennt jemand eine Möglichkeit dies zu umgehen, z.B. dadurch, dass man Dateien (welche?) vor dem Neustart sichert und danach wiede zurückspeichert?
Grüße
Hallo Valentin
Zitat von "valentin"So, kurz etwas Feedback
Wie bereits vermutet lag die Ursache in get_tap() im Script /usr/lib/python2.4/site-packages/endian/restartscripts/openvpnjob.py mit seiner Funktion get_tap().Meine Änderung hat zwar zur Folge, dass die Variable PURPLE_DEVICE ganz aus der Settings-Datei verschwindet, allerdings bleibt dies ohne Konsequenzen.
Den Thread markiere ich jetzt als gelöst
Eigenartigerweise wird diese Nachricht nicht im Thread angezeigt, erst wenn man eine Antwort verfasst. Und als gelöst ist er auch nicht markiert.
Aber jetzt zu meiner Frage, da ich das gleiche Problem habe:
Ich habe das Script nie gesehen, kann man es nicht schaffen PURPLE_DEVICE=tun0 zu setzten? Was meinst du genau mit "ohne Konsequenzen", hat's mit tap noch funktioniert oder nicht mehr?
Was wird wohl passieren, wenn man das tun-Device tatsächlich anspricht, gibte es das dann auch?
Grüße
treviris
Vielen Dank ffischer.
Ich habe das jetzt auch nachvollzogen und es funktioniert - mit meinem Kabelmodem, openVPN und no-ip einwandfrei.
Die Aussagen von Kabel Deutschland kann man vergessen.
Hallo ppc,
zunächst eine Gegenfrage: steht deine Verbindung zwischen zwei Endians, obwohl einer davon hinter einem Kabelmodem liegt?
Ich habe ein ähnliches Problem, allerdings will ich eine OpenVPN-Verbindung zu einem Endian hinter einem THG540K-Kabelmodem herstellen. Ein dynamische DNS konnte ich mit Hilfe von no-ip aufbauen, allerdings hilft es mir bisher nicht viel. Ich kann die aufgelöste Adresse nicht einmal anpingen, obwohl ich die Pings im Endian Firewall freigegeben habe - nicht einmal dann, wenn ich sämtliche Firewalls vorübergehend außer Betrieb setze.
Kabel Deutschland sagt dazu, im müsse mir die neue Homebox Fritz Box 6360 anschaffen, nur dann ginge das. Aber ich bin nicht sicher, ob ich dann dahinter mit meinem Endian noch eine OpenVPN-Verbindung herstellen kann.
So, ich habe jetzt 2 Versionen ohne Ausfälle am Laufen, die beide die "Nur fixed Leases" im DHCP beherrschen:
Einmal Version 2.4.1 mit meinem alten Motherbord Jetway 7F21G2ES-LF (1,2 GHz, VIA Prozessor) und
einmal Version 2.5.1 mite einem neuen Motherboad Jetway JNF9D-2550-LF (1,86 GHZ Intel Prozessor
warum das so ist, ist mir immer noch nicht ganz klar. Aber damit kann ich leben.
Reinhold
Von 2.3 bin will ich weg, da diese Version die "Fixed Leases" im DHCP nicht unterstützt. Man kann den Punkt zwar ankreuzen, aber er funktioniert nicht. Deswegen die Version 2.4.1 als Ziel. Weiß jemand, ob es da funktioniert?
Hallo Sabine,
es handelt sich um ein Mini-ITX Motherboard Jetway 7F21G2ES-LF mit VIA Eden 1.2GHz Processor mit VIA CN700 + 8237RP Chipset und 1GB Memory
beziehungsweise zum Test auch um ein Mini-ITX Jetway 7F21G5D-OC-LF 1,5Ghz mit VIA C7 und Eden (V4) Prozessoren mit VIA CN700 + VT8237RP Chipset und 1GB Memory
jeweils mit einem sog. Daugthterboard Jetway Adapter 3x10/100 Lan.
Wieviel Rechner daran hängen? Im Moment gar keine. Alle LAN-Inteface sind ohne Verbindung. Das war natürlich nicht immer so - zunächst hatte ich den Fehler mit anhängenden Rechnern festgestellt.
Zum Testen installiere ich einfach Endian 2.5.1 und ein zuvor erstelltes Backup und schaue mir auf einem Monitor die Ausgabe an. Solange sich beim Drücken auf "Return" da noch was ändert, lebt das System noch. Doch ich brauche nur einige Stunden (manchmal sogar Tage) zu warten, dann rührt sich nichts mehr, es hilft nur noch der Restart-Knopf.
Wie schon zuvor erwähnt, habe ich auf gleichartigen Systemen schon jahrelang Version 2.3 stabil am Laufen, teilweise mit über 50 daran hängenden Rechnern.
Der Fehler schein mir erst mit Version 2.5.0 entstanden zu sein.
Gruß Reinhold
Leider keine gute Nachricht:
Inzwischen (von Dienstag bis Freitag) hatte ich wieder 2 Ausfälle an meinem Testgerät - trotz ausgeschaltetem ACPI.
Ein schönes Wochenende wünscht
Reinhold
Hallo,
wenn ich nach einem Absturz und Neustart die CPU-Auslastung ansehe, so sieht es auch bei mir etwa so aus: studenlang ca. 10 % und dann plötzlich "Null" bis zum nächsten Neustart. Ich mache jetzt einen Versuch, wie Knut, ACPI abzuschalten.
Suspendmodi und Hyperthreading kann ich in meinem Bios leider nicht finden.
Wollen wir mal schauen.
Hallo zusammen,
also an der SSD liegt es nicht. Inzwischen habe ich ein Gerät, das unter 2.3 (mit SSD) einwandfrei läuft, mit 2.5.1 und einer rotierenden Festplatte ausgestattet - und da war der Fehler wieder. Nach ein paar Stunden Trockentest: Totalausfall. Reproduzierbar.
Ich warte jetzt auf die neue Hardware. Vielleicht muss es ein Mehrkern-Prozessor sein?
Grüße
Hallo,
dass es an den Patches liegt, glaube ich nicht. Im englischsprachigen Forum werden mehrere derartige Abbrüche bei Version 2.5.1 beschrieben, teilweise schon ab April 2012:
http://www.efwsupport.com/index.php?topic=3088.0
Dass es etwas mit den "Fixed Leases" zu tun hat, glaube ich jetzt, nach meinen letzten Abbrüchen, auch nicht mehr.
Ich habe jetzt neue, schnellere Hardware bestellt - und auch die SSD als Fehlerquelle sollte man nicht außer Acht lassen.
Ja, ich meine Version 2.3. Die Prozessor-Auslastung liegt sowohl bei 2.3 aus auch bei 2.5.1 bei etwa 10%.
2.3 lief und läuft auf 9 anderen Systemen mit der gleichen Hardware schon jahrelang ohne Probleme. Die Anforderung war jetzt, DHCP so zu konfigurieren dass nur noch fixe Lease erlaubt sind. Das kann man bei 2.3 zwar auswählen, aber es funktioniert nicht.
Bei 2.5.1 habe ich es von vorneherein angeklickt, es war ja das Hauptziel des Upgrades.
Jetzt - bevor ich wieder auf 2.3 bei dem bewussten Gerät zurückging - habe ich testweise den Haken bei "Nur fixe Lease zulassen" rausgenommen. Und siehe da: das Problem, die häufigen Aufälle waren weg. Nach einem Restart lief das Gerät jetzt seit 3 Tagen einwandfrei - bis es vor 5 Minuten wieder einen Ausfall gab.
Hat jemand ein System mit "Nur fixe Lease zulassen" am Laufen?
Ich habe jetzt zwei gleichartige und gleich programmierte Geräte in Betrieb - das eine davon vollkommen offline mit nur einem Client auf der grünen Seite. Und auch da tritt der Fehler schon auf! :nerv: Ich gehe jetzt für das in Anwendung befindliche Gerät auf Version 3.3 zurück.
Ja, ich kann ihn nur noch ausschalten oder den Restart-Knopf drücken.
In den Logs kann ich auch nichts brauchbares finden, hier eine typische Ausgabe vom Auftreten des Fehlers bis zum Restart.
Jan 21 09:01:02 fcron[16665] Job [ -x /bin/run-parts ] && run-parts --report /etc/cron.hourly completed
Jan 21 09:12:45 sudo root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/monit status
Jan 21 09:15:56 dhcpd DHCPDISCOVER from 00:19:d1:48:a0:7e via br0
Jan 21 09:15:56 dhcpd DHCPOFFER on 172.20.95.127 to 00:19:d1:48:a0:7e via br0
Jan 21 09:15:56 dhcpd DHCPREQUEST for 172.20.95.127 (172.20.95.249) from 00:19:d1:48:a0:7e via br0
Jan 21 09:15:56 dhcpd DHCPACK on 172.20.95.127 to 00:19:d1:48:a0:7e via br0
Jan 21 09:18:02 dhcpd DHCPDISCOVER from 00:18:fe:9c:ad:a1 via br0
Jan 21 09:18:02 dhcpd DHCPOFFER on 172.20.95.231 to 00:18:fe:9c:ad:a1 via br0
Jan 21 09:18:02 dhcpd DHCPREQUEST for 172.20.95.231 (172.20.95.249) from 00:18:fe:9c:ad:a1 via br0
Jan 21 09:18:02 dhcpd DHCPACK on 172.20.95.231 to 00:18:fe:9c:ad:a1 via br0
Jan 21 09:47:01 kernel [ 0.000000] Linux version 2.6.32.43-57.e43.i586 (root@andrew) (gcc version 4.1.2 20070626 (Endian 4.1.2-14)) #1 SMP Wed Aug 10 05:05:15 EDT 2011
Jan 21 09:47:01 kernel [ 0.000000] KERNEL supported cpus:
Alles anzeigen
Es handelt sich um ein System mit einem Mini-ITX Board von Jetway
CPU: Embedded VIA CN700 NANO BGA prozessor, Memory 1GB, Host Clock 100 MHZ, Festplatte: SSD 16 GB
Mit Endian V 2.3 ist das System über ein Jahr einwandfrei gelaufen.
Ja, keinerlei Zugriff mehr möglich.
Die top - Ausgabe werde ich mir noch ansehen, wenn ich ihn wieder zum Laufen gebracht habe.
Ja, ich habe die selbe Hardware genommen. Aber ich habe inzwischen eine neue Installation durchgeführt, ohne ein Backup zu verwenden. Mit dem gleichen Ergebnis: irgendwann nach stundenlangem Betrieb steigt das System aus. Nach einem Neustart ist im System-Status-Diagramm z. B. für die CPU keine Aktivität von diesem Zeitpunkt bis zum Neustart verzeichnet.
Ich gehe jetzt eher davon aus, dass meine Hardware für die Version 2.5.1 zu langsam ist.
Grüße Reinhold
Hallo,
nach dem Übergang (Neuinstalltion, kein Upgrade, auf der selben Hardware) von V. 2.3 auf V. 2.5.1 haben wir eigenartige Ausfälle zu verzeichnen.
Nach stunden- bis tagelangem Betrieb ist steigt das System vollkommen aus, meist zu vollen Stunden: im Protokoll sind keine Aktivitäten zu erkennen und es ist kein Zugriff mehr möglich, weder über Bildschirm/Tastatur noch über das gui. Das letzte, was im Protokoll zu erkennen ist: eine Zeile mit "--report /etc/cron.hourly completed".
Um die Installation zu vereinfachen bin ich den Weg gegangen, aus dem Gerät unter V. 2.3 ein Backup zu ziehen und dieses Backup habe ich dann unter V. 2.5.1 wieder eingelesen. Hat jemand schon etwas ähnliches durchgeführt und ist das keine erlaubte Vorgehensweise?
Grüße