Beiträge von X-Dimension

Hallo,

die RDP Verbindung war schon nur auf 16Bit Farbtiefe gesetzt, wie ich gerade feststellen musste.
Bei 24 oder gar 32 ist sie nahezu unbenutzbar, es dauert dann rund eine halbe Minute und länger bis ein Mausklick umgesetzt wird.

Nebenbei habe ich auch feststellen müssen, das neu hinzugefügte Source NAT Regeln keine Wirkung mehr
zeigen. Alle alten Regeln funktionieren weiterhin, sogar wenn ich diese in der Endian deaktiviere!
Um die Intel NIC Treiber zu installieren musste ich auf den Development Channel umstellen und dabei wurden
automatisch mehrere Pakete aktualisiert. Ich hoffe nicht dass diese jetzt die Ursache für die Probleme sind.

PS: Die CPU-Last auf der Endian liegt bei unter 10%. Ein CPU Kern hatte 13% der zweite 5%.

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?

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.

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?

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.

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

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?

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?

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!

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

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.

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.

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.

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?

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

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?