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. X-Dimension

Beiträge von X-Dimension

  • Nach tausch der Netzwerkkarte extrem langsame VPN Verbindung

    • X-Dimension
    • 7. Februar 2013 um 10:39

    Ich habe nochmal ein paar Performance-Tests durchgeführt:
    DSL-Upload über sFTP Verbindung: 115 Kilobyte = 920KBit (16.000er DSL hat max 1024KBit Upload, die Geschwindigkeit geht also in Ordnung)
    Datendurchsatz der IPSec Verbindung: 93 Kilobyte (konstant)
    Datendurchsatz der OpenVPN Verbindung: 65 Kilobyte (anfangs nur 30-40)

    Zum einen finde ich den Durchsatz der OpenVPN verbindung schon recht langsam, gerade die Anfangswerte.
    Andererseits sollte das aber doch eigentlich noch für eine halbwegs flüssige RDP Verbindung reichen, oder?

  • Nach tausch der Netzwerkkarte extrem langsame VPN Verbindung

    • X-Dimension
    • 6. Februar 2013 um 16:32

    Hallo,
    ich bin genau nach dieser Anleitung vorgegangen, da die Intel Netzwerkkarte sonst nicht erkannt wurde.
    Zuvor habe ich die Schnittstelle der Grünen Zone von der alten Broadcom NIC auf eine der im Mainboard integrierten Netzwerkkarten umgestellt.
    Nachdem der Intel Server Adapter eingebaut war, habe ich die Grüne Zone auf den ersten Port der Intel Karte gelegt.
    Die WAN Schnittstelle blieb hingengen unverändert am zweiten Port der im Mainboard integrierten NIC.

    Ich habe mit Netperf mal den Durchsatz zwischen den Zonen Grün, Blau und Orange gemessen (Alle auf der Intel NIC) und
    der Durchsatz lag jeweils über 920 Mbit/s. Netperf durch die VPN zu schubsen, habe ich bisher nicht hinbekommen.
    Das Kopieren einer 18 Megabyte großen Datei durch den OpenVPN Tunnel dauerte 4:34 Sekunden und brachte max 65Kb/s.
    Über einen IPSec-Tunnel waren es immerhin konstant 93Kb/s, was eigentlich gar nicht mal so schlecht ist.

  • Nach tausch der Netzwerkkarte extrem langsame VPN Verbindung

    • X-Dimension
    • 6. Februar 2013 um 11:31

    Hallo,

    wir haben in unserer Endian 2.5.1 Community Edtion anstelle einer 2-port Broadcom 1GBit Netzwerkkarte einen 4-port Intel Server-Adapter eingebaut (ebenfalls 1GBit).
    Obwohl auf dem ersten Blick alles prima funktionierte mussten wir nun feststellen, dass sämtliche VPN Verbindungen extrem langsam sind.
    Besonders bemerkbar wird es bei RDP Verbindungen durch die VPN, denn hier wird das Bild trotz zwei 16.000er DSL Leitungen auf beiden Seiten nur in Zeitlupe
    aufgebaut, was vorher hingegen flüssig funktionierte.
    Der VSphere Client von VMWare bricht sogar neuerdings mit einem Timeout ab, wenn man durch die VPN Versucht auf einen ESXi Server zu kommen.
    In den VPN und System-Logs der Endian ist nichts auffälliges zu finden.
    An der DSL Leitung liegt es nicht, wir haben diese schon geprüft und da wir exakt das gleiche Problem
    mit einer baugleichen Endian Firewall an einem anderen Standort haben, bei der ebenfalls die gleiche 2-port Broadcom Netzwerkkerte durch eine 4-Port Intel ersetzt wurde,
    muss irgendwas mit der Endian nicht stimmen.

    Hat jemand vielleicht eine Idee?

  • Treibermodul für Endian kompilieren?

    • X-Dimension
    • 18. Juli 2012 um 16:30

    Hallo,

    hat vielleicht irgendjemand eine Idee wie ich für Endian ein Treibermodul kompilieren kann?
    Endian selbst bringt ja weder make noch kernelquellen mit, aber gibt es trotzdem eine Möglichkeit
    sich eine Built-Environment zu erstellen von der aus man dann den Treiber kompilieren kann?

    Im Speziellen geht es hier um den Intel IGB Treiber, der offenbar in der Version 2.5.1 veraltert ist
    und meine Intel i340 Netzwerkarte nicht unterstützt.

  • Zugriff aus dem VPN in die DMZ

    • X-Dimension
    • 23. Februar 2012 um 16:15

    Hast du schon eine Lösung gefunden, dass es auch über IPSEC geht?

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 17. Februar 2012 um 11:02

    Nachdem ich den Webserver in die DMZ gepackt hatte musste ich feststellen, dass die obige "Lösung" wirklich nur
    ein "Workaround" war, denn trotz entsprechendem Host Eintrag, stand ich plötzlich vor dem gleichen Problem!
    Ich konnte lokal meinen Webserver einfach nicht über die externe URL vom Browser aus erreichen!

    Nach diversen nslookups, stellte ich nun folgendes fest:
    Die Namensauflösung von http://blablup.mydomain.com/ aus Zone Grün und Blau heraus funktioniert per default wunderbar, auch
    ohne Host Einträge in der Firewall!
    ABER, gebe ich http://blablup.mydomain.com/ in den Browser ein bekomme ich ein Timeout!

    Zunächst vermutete ich, dass es am Proxy liegen könnte und deaktivierte diesen, allerdings bekam ich weiterhin ein Timeout im Browser,
    während der nslookup die korrekte IP-Adresse anzeigte!
    In der Host Konfiguration setzte ich dann wieder einen Eintrag der von blablup.mydomain.com auf die Interne IP des Webservers in der DMZ verwies
    und siehe da, die Seite wurde nun angezeigt!
    Also schaltete ich den Proxy ein und ich bekam wieder nur ein Timeout im Browser!
    Nachdem ich dann bei "Transparenten Proxy umgehen nach" die lokale IP des Webservers eingetragen hatte,
    klappte endlich alles. Allerdings ist das auch wieder nur eine Notlösung!

    Da ein dnslookup von blablup.mydomain.com korrekt auf die öffentliche IP verweist, müsste Endian es doch irgendwie gebacken kriegen auch die entsprechende Webseite im Browser anzuzeigen!?
    Dieser Umweg über Hosteintrag auf die interne IP und dann nochmal die Interne IP des Webservers im Proxy umgehen, kann ja nicht wirklich
    eine optimale Lösung sein.
    Hat jemand vielleicht noch eine Idee woran ich schrauben könnte, damit es einfacher funktioniert?

  • Wie finde ich heraus ob SNORT macht was es soll?

    • X-Dimension
    • 6. Februar 2012 um 13:21

    Hallo,

    ich möchte mit SNORT ICQ blocken lassen und habe in den entsprechenden SNORT Regeln alles was irgendwie mit ICQ zu tun hatte mit einem "roten Schild" versehen, in der Hoffnung das ICQ dadurch geblockt wird.
    In den IPS Logs werden aber weiterhin "ICQ Message" Privacy Violation Meldungen protokolliert.
    Heißt das das ICQ Nachrichten weiterhin durch gehen?

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 3. Februar 2012 um 14:01

    Hier die einfache Lösung:

    1. Menü Netzwerk -> Hosts bearbeiten -> Host hinzufügen
    2. Eintrag für den Webserver setzen
    IP Adresse: 192.168.1.100
    Hostname: blablup
    Domainname: mydomain.com
    3. Speichern -> FERTIG

    Die ganzen Source NAT Einträge, die unter 2.4.1 als Workaround dienten, kann man getrost löschen!

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 3. Februar 2012 um 10:37

    In den Firewall Logs schlagen solche Einträge auf:

    PROXIES:HTTP-PROXY:- TCP (br2) lokale-client-IP(blau/grün):46046 -> öffentliche-IP(rot):80
    MAC=aa:bb:cc:dd:00:11:22:33:44:55:66:aa:bb:cc LEN=60 TOS=00 PREC=0x00 TTL=64 ID=33045 DF SEQ=1264416413 ACK=0 WINDOW=5840 SYN URGP=0 MARK=2800

    Aber sonst nichts weiter...

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 3. Februar 2012 um 09:00

    Ja, UDP+TCP Port 53 von GRÜN/BLAU/ORANGE nach Rot ist in den ausgehenden Firewall-Richtlinien erlaubt.

    Ich habe auch schon mit Port Forwarding / Destination NAT Regeln herum gespielt,
    aber so richtig weiß ich nicht wie ich die Regel hier setzen soll.
    Bisher hat jedenfalls nichts funktioniert was ich versucht hatte.

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 2. Februar 2012 um 15:57

    Ich sehe gerade dass die Source-NAT Regel, die in der 2.4.1 das Problem mit der Namensauflösung behoben hatte, innerhalb der grünen Zone nun auch nicht mehr funktioniert! Ein Zugriff von grün auf den Webserver ist nur dann möglich, wenn lokal ein DNS Server läuft in dem die URL http://blablup.mydomain.com/ hinterlegt ist.
    Aber ohne lokalen DNS-Server funktioniert die Namensauflösung dieser "externen" URL ebenfalls nicht.

    Das Problem ist eben, dass die Endian-Firewall die Anfragen aus den Zonen erstmal ins WAN leiten muss, dort erfolgt die Namensauflösung, die dann ja wieder auf die eigene IP-Adresse zurück geht. Hier half wie gesagt bei 2.4.1 noch der Source-NAT Eintrag als "Workaround", der bei 2.5.1 offenbar das Problem nicht mehr löst.

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 2. Februar 2012 um 15:35

    Ja, der Webserver ist von außerhalb problemlos erreichbar (von rot nach grün).
    Die Interzone-Firewall erlaubt momentan den kompletten Traffic von blau nach grün und von grün nach blau.

    Das kuriose (was mir bei Endian 2.4.1 schon auffiel) ist allerdings, dass der Webserver von blau nach grün auch über die IP-Adresse erreichbar
    ist, wenn ich in der Interzone-Firewall sämtlichen Traffic von blau nach grün blocke!

    Irgendwie müsste ja eine DNS Anfrage von blau nach rot laufen, die dann wieder zurück nach grün führt.

  • *gelöst* Probleme mit Interzone-Traffic und Webserver

    • X-Dimension
    • 2. Februar 2012 um 11:14

    Hallöle, ich habe seit der Umstellung von Endian 2.4.1 auf 2.5.1 ein kleines Problem mit dem Interzone-Traffic.

    Folgendes Szenario ist vorhanden:

    Zone Grün 192.168.1.0
    Zone Blau 192.168.2.0
    In Zone Grün steht ein Webserver, der über die externe Adresse http://blablup.mydomain.com von außen erreichbar ist. (Kommt demnächst aber in die DMZ)
    Um den Webserver von der Zone Grün aus über diese Adresse erreichen zu können musste ich in Endian 2.4.1 eine Source NAT Richtlinie
    festlegen, die vom Netz 192.168.1.0/24 auf die IP des Webservers zeigt und ein NAT auf 192.168.1.1 (Endian Firewall) durchführt.

    Von der Zone Blau kam ich hingegen auch ohne Source NAT Eintrag über die obige URL auf den Webserver in Zone Grün.
    Seit der Umstelung auf Endian 2.5.1, funktioniert dies jedoch nicht mehr!

    Es ist jedoch problemlos möglich den Webserver über die IP-Adresse von Zone grün aus Anzusprechen,
    jedoch nicht über die URL!

    Ich habe in der Interzone Firewall den Traffic von Blau nach Grün erstmal komplett erlaubt und versucht eine Source NAT Regel zu erstellen
    die von 192.168.2.0/24 auf die IP des Webservers verweist und ein NAT auf 192.168.1.1 oder auch .2.1 durchführt, jedoch brachte das keinen
    Erfolg.
    Hat jemand eine Idee, wie ich wieder per externer URL von Zone blau auf den Webserver in Zone grün komme?

  • Zeitpunkt für DSL Leitungsreset einstellbar?

    • X-Dimension
    • 1. Februar 2012 um 11:04

    Hallo, das klingt gut! :)
    Werden anschließend die Uplinks auch wieder automatisch gestartet, oder ist der Befehl nur zum stoppen?

  • Zeitpunkt für DSL Leitungsreset einstellbar?

    • X-Dimension
    • 31. Januar 2012 um 13:09

    Hallo, gibt es eine Möglichkeit in der Endian Firewall einzustellen, wann die 24 Stunden DSL-Zwangstrennung
    erfolgen soll?
    In diversen Routern gibt es ja eine entsprechende Option im Web-Interface, bei Endian soweit ich weiß leider nicht.
    Lässt sich das aber ggf. durch die Bearbeitung einer Konfigurations-Datei einstellen?

Unterstützt von

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