Zitat von "Sabine"Habe es mal probiert, funzt auf meiner Kiste nicht.
Gruß Sabine
Servus,
mal schauen - installiert und ulogd neu gestartet ist es. Ich bin gespannt ob das Log generiert wird beim ersten Firewall-Event.
Gruß,
Jens
Zitat von "Sabine"Habe es mal probiert, funzt auf meiner Kiste nicht.
Gruß Sabine
Servus,
mal schauen - installiert und ulogd neu gestartet ist es. Ich bin gespannt ob das Log generiert wird beim ersten Firewall-Event.
Gruß,
Jens
Servus,
ansonsten hättest du einfach nur das richtige Kernelmodul für den Chip selber kompilieren können und das falsch erkannte Modul blacklisten (siehe hier).
Gruß,
jeti-power
Zitat von "mschoen"Das dürfte doch aber der e1000 oder e1000e Treiber erledigen.
Was sagt lspci auf der Shell?
Servus,
ja, also der e1000e Treiber müsste funktionieren und wie man den kompiliert, hab ich in meinem Blog beschrieben.
Gruß,
jeti-power
Hallo,
Zitat von "Grenzwert"Ich stehe vor der Situation ein Kabelmodem 100M und ein DSL Modem 6M am Dual Wan Router mit Ausfall rollover angeschlossen zu haben.
eine ähnliche Konstellation wie hier
Hier läuft eine 50 Mbit/s Leitung via KabelBW und 6 Mbit/s als Fallback via DSL.
Zitat von "Grenzwert"Dieser Netgear FVS336G schafft aber nur max. 59-60MBit/s. Und dabei beschränkt er sich schon nur auf NAT.
Was sogar etwas mehr ist als mein ~3 Jahre alter Lancom Router
Zitat von "Grenzwert"Die Endian Firewall unterstützt ja Dual Wan, wie ich las.
Dual WAN und Quality Based Routing.
Zitat von "Grenzwert"Eine erste Probeinstallation führte ich schon durch. PIII/700MHz. Ist trotz aller Hilfe lernintensiv.
Jetzt stellt sich aber die grundsätzliche Frage nachdem ich hier die Austattung und den Durchsatz lese:
Für 100MBit/s Durchsatz, eingeschalteter Wörterüberwachung, Adressfilterung, Proxy, Macsperren,Portforwarding, und was man halt sonst noch so alles braucht.(Kein VPN)
Meine Vorstellung eines Intel Atom Prozessors mit 3 Gigabitnetzwerkkarten ist wohl zu niedrig gegriffen ?
Also ich hab als Basis den SuperServer 5015A-H von Supermicro basierend auf einem Intel Atom 330 Dual-Core 1.6GHz Prozessor und einer zusätzlich verbauten Intel Netzwerkkarte. Zusätzlich zu dem, was du aufgeführt hast habe ich noch das extrem leistungshungrige Snort aktiv (unnötige Regeln allerdings sind deaktiviert) und einem etwas umfangreicheren Inhaltsfilter für den HTTP Proxy. Die 50 Mbit/s können dabei hier relativ gut bedient werden.
Wieviel effektiv als maximum möglich ist, kann ich dir leider nicht sagen - aber wenn man Snort noch eingewenig optimiert (oder besser noch deaktiviert lässt), sollten für 4-5 Nutzer auch 100 Mbit/s eigentlich kein größeres Problem darstellen. Der Inhaltsfilter könnte hier maximal der Knackpunkt werden (je nach Umfang des Filters). Aber hier wirst du wohl um eigene Tests nicht herum kommen.
Die Daten vom System habe ich einmal im meinem Blog veröffentlicht. Der einzige Knackpunkt war bei dem System, was für die meisten Atom Systeme gilt, die Unterstützung der meistens verbauten Netzwerkchipsätze. Hier wirst du wohl nicht auf etwas Handarbeit verzichten können. Aber eine Anleitung gibts dafür natürlich auch in meinem Blog.
Gruß,
jeti-power
Servus,
noch eine kleine Warnung was 2.3RC1 angeht. Durch ein Fehler bei der Logrotate Konfiguration werden die Logfiles immer größer und gerade bei Routern mit wenig Speicherplatz, kann schnell /var/log überlaufen
Gruß,
jeti-power
Zitat von "Lownex"update:
wenn ich insmod "/pfad zur tg3.ko.gz", also das was mir modprobe ausgibt, eingebe, dann bekomme ich als Antwort: invalid module format
dies sollte eigentlich nur funktioniert, wenn das Kernelmodul entpackt ist. Du kannst es ja mal temporär mal mit gunzip entpackt speichern und per insmod laden. Ob danach das Modul geladen wurde, sollte man danach primär erstmal unter lsmod sehen.
Gruß,
Jens
Zitat von "mschoen"Nettes System.
Ich hatte auch ein MSI Board am Haken, dass hatte auch den 2 e1000e Chips on Board, da ich in Verbindung mit Endian keine Unterstützungsinformationen gefunden habe. Als Erweiterung hab ich noch Realteks liegen, die ich schon mal in einer Endian verbaut hatte, da weiß ich zumindest, dass sie funktionieren...
Hoffe die Teile kommen noch in dieser Woche...
stimmt, die e1000e laufen nur, wenn man den Treiber selber kompiliert. Irgendwie hab ich das hinbekommen, auch wenn eigentlich kein Dev-Kit existiert. :-]
Gruß,
Jens
Servus,
achso, du willst ihn unter 2.2 zum laufen bekommen?
Was insmod angeht, hm, unter Endian hab ich das ganze ehrlich gesagt noch nicht verwendet und ich ging davon aus, dass es ähnlich wie unter normalen Distris wie Debian abläuft.
Du könntest mal "modprobe -vn tg3" probieren, was eigentlich ebenfalls ein testweise laden eines Moduls bewirkt.
Gruß,
Jens
Hi,
das erinnert mich an mein System:
Als Basis-System http://www.supermicro.com/products/syste…15A-H.cfm?typ=H zusammen mit 2GB Arbeitsspeicher und von Delock folgendes Flash-Modul: http://www.delock.de/produkte/grupp…ikal_54145.html als "Festplatte". Als dritte Netzwerkkarte steckt im System eine Intel PCIe Netzwerkkarte. Die beiden Onboard Karten laufen als WAN Ports und die Intel Karte ist für die LAN Anbindung.
Zur Zeit läuft es absolut problemlos, allerdings hatte ich Anfangs mit den Netzwerktreibern doch etwas zu kämpfen, da nicht nur die Realteak falsch erkannt wurden, sondern auch die Intel Karte nicht unterstützt wurde (e1000e). Ich denke, das ist auch bei der Hardware-Unterstützung das Hauptproblem - die Unterstützung von neueren Netzwerkkomponenten auf PCIe Basis.
Gruß,
Jens
Zitat von "Lownex"danke... ich versuch das gleich mal. Ich gebe eine Rückmeldung am Nachmittag. Warum wird das denn nicht automatisch gemacht, und wie kann ich das automatisieren?
Normalerweise sollte das Modul automatisch geladen werden. Zumindest war es bei einem Dell-Testserver, auf dem ich hier mal IPCop testete, so und IPCop verwendet eigentlich einen älteren Kernel als efw. Von daher hoffe ich eigentlich, dass beim "manuellen" laden des Moduls es zu einer Fehlermeldung kommt, die evntl. hilft das Problem einzugrenzen.
Gruß,
Jens
Zitat von "mschoen"Hat jemand nun schon Erfahrungen mit den Realtek 8111 Chipsätzen auf den Atom-Boards gemacht? Laufen die mit der 2.3 RC1?
nope, per Default erstmal leider nicht. Wie man es zum laufen bekommt, hab ich in einem anderen Thread mal gepostet:
https://www.efw-forum.de/www/forum/view…mp;p=1479#p1479
Gruß,
Jens
Hi,
hmm, okay:
# vendor: 14e4 ("Broadcom Corporation"), device: 1698 ("NetLink BCM5784M Gigabit Ethernet PCIe")
Also die Karte wird erkannt vom Kernel, das Kernel Modul für "tg3" sollte die Karte unterstützen. Allerdings wird das Kernel Modul nicht geladen. Der nächste Schritt wäre das manuelle testweise laden des Treibers. Das sollte mit insmod -lv tg3 machbar sein.
Gruß,
Jens
Hi,
lsmod wäre noch von Interesse um zu sehen, welche Kernelmodule geladen sind mittels lsmod. Vorhin vergessen hatte ich im übrigen noch "lspci -n" um die Hardware-IDs zu sehen. Mit letzterem wäre ein Vergleich mit http://cateee.net/lkddb/web-lkddb/TIGON3.html möglich um zu sehen, ob der Chipsatz auch tatsächlich abgedeckt wird mit dem Kernel Modul.
Aktuell kann man eigentlich nur sagen, dass die Karte zumindest aktiviert scheint.
Gruß,
Jens
Zitat von "wolfili"Hallo,
manche Befehle werden auch nicht funktionieren.
Da die Sourcen fehlen, die kann man bei der 2.2 installieren. Für die 2.3 sind bisher noch keine aufgetaucht.gruß
das interessantere dabei ist, dass eigentlich sowohl bei 2.2 als auch 2.3 das "tg3" Kernelmodul vorhanden ist. In der Theorie müsste die Karte eigentlich erkannt werden.
Interessant wäre, was lsmod und lspci ausspuckt.
Gruß,
Jens
Servus,
zumindest der aktuelle RC leidet noch an einem Bug bei den Realtek Gigabit-Treibern, welcher verhindert, dass die r8111/r8168 richtig erkannt werden.
Bei der 2.3 RC1 Version ist es etwas tricky das Problem zu umgehen:
Die Datei http://www.tf-network.de/customer/endian/r8168.ko.gz in /lib/modules/2.6.22.19-72.e18/kernel/drivers/net/ laden. Im gleichen Ordner die existierende Datei r8169.ko.gz einmal am besten sichern und danach löschen (sollte dies nicht möglich sein, muss evntl. das r8169 Kernelmodul mit rmod entladen werden). Die gerade hochgeladene Datei r8168.ko.gz in r8169.ko.gz umbenennen und ein depmod -ae ausführen. Ein abschließender Reboot und die Realtek-Karte sollte nicht mehr vom "falschen" Kernelmodul erkannt werden.
Möchte man auf das löschen des r8169 Kernelmoduls verzichten, so sollte noch ein weiterer Weg funktionieren. Man läd wie oben erklärt das Verzeichnis mit den Netzwerk-Kernelmodulen. Aber anstatt die Datei umzubenennen, trägt man in /etc/modprobe.d/blacklist zusätzlich folgende Zeile ein: "blacklist r8169". In /etc/modprobe.conf sollte man zusätzlich noch die Zeile "alias eth r8169" in "alias eth r8168" ändern, damit die Karte gleich richtig zugeordnet wird. Im Anschluss noch ein depmod -ae und reboot. Danach sollte normalerweise ebenfalls das erkennen der Karte durch das falsche Kernel Modul verhindern worden sein. Selber getestet hab ich allerdings nur den ersten Weg.
Gruß,
Jens
Servus,
könnt ihr mal schauen, ob ihr folgende Fehler nachvollziehen könnt?
a) Proxy aktivieren und den Content-Filter einrichten. Dabei soll der Content-Filter die Zugriffe loggen. Danach mal eine paar Seiten aufrufen (auch potentiell gesperrte) und schauen, ob das Logfile unter Protokolle / Inhaltsfilter sich mit Inhalt füllt
b) IDS aktivieren und im Dashboard schauen, ob unter Dienste das IDS System als On geführt wird. Hier bleibt es auf OFF stehen, aber die Zähler steigen.
Gruß,
jeti-power
Servus,
stimmt, jetzt im nachhinein ist der Weg absolut logisch. Die Firewallregeln verbieten ja den direkten Zugriff auf das Router-System selber und die Ausnahmen werden als Systemzugriff in der WebGUI geregelt. Manchmal steht man nur auf dem Schlauch
thx jedenfalls für deine Hilfe
Gruß,
jeti-power
Hallo,
momentan bin ich hier am testweise einrichten eines Routers basierend auf dem Endian Firewall System (2.3RC1 - wegen dem Dashboard *g*). Es gab zwar kleinere Probleme, da die verbaute Realtek Karte falsch erkannt wurde (RTL8111/8168B) und für die Intel e1000e das Kernelmodul fehlte. Aber die die problematischen Kernelmodule konnte ich problemlos tauschen (also falls jemand die beiden Kernelmodule braucht -> PN).
Woran ich aktuell allerdings aktuell scheitere ist eigentlich etwas relativ simples. Ich möchte einfach nur, dass von außen meine IP angepingt werden kann - also ICMP Echo beantwortet und nicht gedroppt wird. Erst vermutete ich, dass Snort an der Sperre schuld ist, aber war es nicht. Irgendwo in den iptables-Regeln scheint wohl ICMP Echo blockiert zu werden. Allerdings finde ich irgendwie die dazugehörige Stelle nicht.
Hat jemand daher eine Idee, wie ich ICMP Ping wieder freigeben kann? Ob jetzt via Web-Oberfläche oder durch Modifikation einer Datei, wär mir dabei egal.
Gruß,
jeti-power