1. Aktuelles
  2. Dashboard
  3. Forum
    1. Unerledigte Themen
  4. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
  5. Community vs. Enterprise
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Forum
  • Seiten
  • Erweiterte Suche
  1. efw-forum - Endian Firewall Support Forum
  2. Mitglieder
  3. treviris

Beiträge von treviris

  • IPsec roadwarrior-Verbindung zu Android

    • treviris
    • 3. Mai 2018 um 14:18

    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.

  • IPsec roadwarrior-Verbindung zu Android

    • treviris
    • 27. April 2018 um 13:40

    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?

  • Meltdown/Spectre

    • treviris
    • 16. Januar 2018 um 15:28

    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?

  • Netzwerkdiagramme nach Neustart

    • treviris
    • 4. Mai 2015 um 17:31

    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

  • /var/efw/openvpn/settings nicht Reboot-fest

    • treviris
    • 26. Juni 2013 um 12:01

    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

  • IPSec mit dyndns-Name über selfhost.bz

    • treviris
    • 31. Mai 2013 um 19:13

    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.

  • IPSec mit dyndns-Name über selfhost.bz

    • treviris
    • 29. Mai 2013 um 17:41

    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.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 19. Februar 2013 um 15:26

    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

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 14. Februar 2013 um 17:07

    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?

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 13. Februar 2013 um 14:00

    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

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 8. Februar 2013 um 17:40

    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

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 5. Februar 2013 um 13:09

    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.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 31. Januar 2013 um 09:52

    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

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 26. Januar 2013 um 14:24

    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.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 24. Januar 2013 um 12:44

    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?

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 21. Januar 2013 um 13:04

    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.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 21. Januar 2013 um 10:24

    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.

    Code
    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.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 21. Januar 2013 um 09:41

    Ja, keinerlei Zugriff mehr möglich.
    Die top - Ausgabe werde ich mir noch ansehen, wenn ich ihn wieder zum Laufen gebracht habe.

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 21. Januar 2013 um 09:26

    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

  • Endian 2.5.1 eigenartige Ausfälle

    • treviris
    • 19. Januar 2013 um 19:13

    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

Unterstützt von

  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™