URL: https://www.overclockers.at/netzwerktechnik/eigenbau-linux-router-mit-ipfire_239501/page_5 - zur Vollversion wechseln!
Mit der OpenVPN App für Android und einer echten IPv4-Adresse sollte die Einrichtung keine Hexerei sein. Ich kanns nicht testen wegen DS-Lite.
Apropos OpenVPN und DS-Lite: Weisz jemand von euch, WARUM letzteres ersteres bricht? Ist das wirklich einfach der Umstand dass das Ordering von saemtlichen UDP-Datagrammen, die ueber das Carrier-NAT von UPC flieszen, gebrochen wird (hab ich mal auf xdsl.at gelesen, und halte ich fuer Wahnsinn, aber ich kenne UPC...)?
Ich hab "leider" kein DS-Lite taugliches Endgeraet daheim und bin deshalb persoenlich verschont geblieben, wuesste aber gerne, womit man es im Endeffekt eigentlich zu tun hat. Hilft es z. B., OpenVPN einfach via TCP zu betreiben, um die Probleme zu umschiffen?
Ich dachte OpenVPN auf Andriod funktioniert nur mit root? OK, na wenn es dafür eine App ohne rooten gibt, dann ist das ok.
Vielen Dank!
Ich habs mit dieser App und meiner ipfire ohne Probleme zum laufen gebracht.
Bei mir hat die OpenVPN Verbindung mit UDPv4 und MTU 1400 zur ipfire an einem DS-Lite Anschluss mittels DynDNS A-Record gestern nicht funktioniert. Ich werde noch testen mit kleinerer MTU, bzw. per TCP und berichten.
Der Verbindungsaufbau des Clients läuft einfach in ein Timeout und beim OpenVPN Server kommt nichts an, ich vermute die Verbindung kann nicht von außen aufgebaut werden, was mich bei einem dynamischen NAT des Providers nichtmal groß wundern würde.
Ja, klar dass das nicht gehen kann, wenn der OpenVPN-Server an einem DS-Lite-Anschluss haengt. Offenbar ist es aber auch so, dass DS-Lite nutzende Clients keine Verbindung zu einem OpenVPN-Server aufbauen koennen, auch wenn letzterer mit einer tatsaechlich oeffentlich gerouteten IPv4-Adresse im Internet haengt...
Hier findet man ein paar Infos, diesbezüglich:
http://www.unitymediakabelbwforum.d...=53&t=23755
Mit einer MTU von 1432 soll es bei denen funktionieren.
Okay, also ein OpenVPN Server ist hinter einem DS-Lite Anschluss mit UDPv4 und TCPv4 trotz DynDNS definitiv nicht erreichbar. Falls jemand eine Idee hat, mit welcher Art von Tunnel das funktionieren könnte, bitte her damit.
Um zumindest einen gewissen Erfolg zu haben, habe ich den OpenVPN-Server in mein WLAN-Netz gesetzt, damit meine eigenen Geräte drahtlos per VPN auch Zugriff ins interne Netz haben, die ohne VPN-Zugang aber nicht, klappt wunderbar :=)
Entweder du nutzt nur Clients die auch über IPv6 kommen, oder du benötigst einen Zwischenpunkt im www der das IPv4 VPN annimt und dann über ein IPv6 VPN weiterroutet.
IPFire 2.17 Update 90 ist vor kurzem erschienen.
Neuigkeiten
GeoIP-Filter wurde implementiert
SSLv2 und SSLv3 wurden deaktiviert
Strongswan in Version 5.3.0 mit Patch für besseren Windows Support
CA-Root-Certs haben eine Schlüssellänge von 4096 Bit, mit SHA-512 oder SHA-256
Clientzertifikate haben eine Schlüssellänge von 2048 Bit
libcrypto.so.10 von Openssl 1.0.2a ist mit und ohne SSE- bzw. SSE2-Support an Bord
Performancesteigerungen beim AES-Cypher und anderen
Entfernung von Legacy-Code
Download gibt es hier:
http://downloads.ipfire.org/latest
Update 91 ist draußen:
Openssl 1.0.2b mit Logjam fix.
StrongSwan 5.3.1
Patches für: CVE-2014-8176, CVE-2015-1788, CVE-2015-1789, CVE-2015-1790, CVE-2015-1791, CVE-2015-1792, CVE-2015-3991, CVE-2015-4171
Alle Details:
http://www.ipfire.org/news/ipfire-2...ate-91-released
Download gibt es hier:
http://downloads.ipfire.org/latest
Seit Update 90 ist meine ipsec vpn Verbindung via iphone kaputt. Ich hatte noch nicht die Zeit mir die Ursache genauer anzusehen, aber ein einfaches Update auf 91 hat das Problem jedenfalls leider nicht behoben.
Ich tippe darauf, dass ältere Zertifikate mit einer Schlüssellänge < 2048 Bit Schwierigkeiten machen könnten.
Das könnte sein. Mein erster Verdacht ging dahin, dass /etc/ipsec.user.conf nicht mehr eingebunden wird und nur mehr /var/ipfire/vpn/ipsec.conf eingelesen wird. Aber wie gesagt fehlt mir die Zeit und der Leidensdruck mich näher damit zu beschäftigen. ;-)
Sodala.. IPFire ist jetzt auch bei mir eingezogen. Ich hatte noch ein Dual Core Sandy Bridge µATX Motherboard mit CPU und 2x2GB RAM, Netzteil, eine SSD und Netzwerkkarte und hab nur das Gehäuse benötigt. Somit war das hardwareseitig kein Problem. Stromverbauch werde ich noch posten.
http://fireinfo.ipfire.org/profile/...1168bfc0f02a08d
Die erste Einrichtung war echt easy: IPFire 2.17 - Core Update 94 ISO geladen, auf meinem Linux Mint Laptop einen USB Stick erstellt, damit gestartet, vom Schleppi grundsätzlich eingerichtet, den alten Router ersetzt und voila, rennt auf Anhieb. So weit so erfolgreich.. aber dann.
1. Problem: Nur 3GB RAM??
IPFire ist ja ein 32bit OS. Damit mehr als 3GB genutzt werden können muss die PAE Erweiterung geladen werden. IPFire hat das auch gleich standardmäßig erledigt. Aber: Es war eine alte Version, GRUB hat daher den neueren nicht PAE Kernel genommen und damit gabs nur 3GB Ram. Abhilfe: Im Menü Pakfire gibts den Update Button. Den sollte man nach der Installation vielleicht ausführen..
Danach erkennt IPFire die vollen 4GB RAM.
2. Problem: Snort
Ich will das auch haben - ich brauchs sicherlich nicht aber eben darum..
Natürlich hab ich mich auf snort.org registriert und wollte die Rules downloaden. Geht aber nicht wie mr.nice. gepostet hat. Nachdem er netterweise auch gleich die Abhilfe gepostet hat, habe ich genau das probiert.
Zur Erinnerung:
Ging auch nicht. Also habe ich händisch mit wget die Dateien geladen und mit tar entpackt.ZitatMan editiert die Download-Rules der Datei ids.cgi in ./srv/web/ipfire/cgi-bin/. Sucht z.B. im vi mit /2961 und ersetzt die beiden Einträge mit 2962, speichert ab mit einem simplen !wq und kann schon wieder updaten!
Den Linux Mint Client händisch konfiguriert (wer braucht schon Automatismen?) und... er verbindet sich. Juchuuu also mal Gateway pingen: Nix geht.. Kein Ping, kein SMB, kein redirect, ...Code:openssl pkcs12 -in IPFIRE.p12 -clcerts -nokeys -nodes -out user.pem openssl pkcs12 -in IPFIRE.p12 -nocerts -nodes -out keys.pem openssl pkcs12 -in IPFIRE.p12 -cacerts -nodes -out ca.pem
Es freut mich, dass du die Herausforderung angenommen und durchgehalten hast! Die aktuelle Snort Version in IPFire ist afaik 2970. Ich habe das Regelpaket für Version 2975 in Verwendung, was in der ids.cgi entsprechend angepasst werden muss.
Das IDS-Webinterface ist grundsätzlich ziemlich fragil, wenn man einen Klick macht, sollte man abwarten bis die aktuelle Aktion abgearbeitet ist. Wenn man wild herumklickt kann es passieren, dass man sich die Snort-Config kaputt macht, weil ein Script nicht vollständig durchgelaufen ist. Ich spreche aus Erfahrung.
Bei mir sind es jetzt bald 18 Monate weitgehend störungsfreier Betrieb. Hin und wieder muss ich die Firewall Regeln anpassen, weil Blizzard gelegentlich neue Gameserver aufstellt, oder Snort+Guardian gewollte Downloads blockiert.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025