• wenn man 2 oder mehr OpenVPN Client Instanzen parallel oder
• wenn man 1 oder mehr OpenVPN Remote Access Server und 1 oder mehr OpenVPN Client Instanzen betreibt

Das hängt damit zusammen, wie man die NAT-Regeln gelbaut hat. Bei Interface “OpenVPN” nimmt er dann tatsächlich im round-robin Verfahren jeweils das eine oder andere OpenVPN TUN Device.

Abhilfe schafft, wenn man den / die OpenVPN Server Client Interfaces (z. B. ovpnc2) unter Interfaces -> Assign einem neuen OPT-Device zuordnet. Jetzt unter Interfaces -> OPT1 das Interface aktivieren mit Type = “none” (da der OVPN-Daemon dieses konfiguriert). Sinnvollerweise dem Interface noch einen aussagekräftigen Namen verpassen und unter Firewall -> NAT die Angaben zum Interface anpassen (OpenVPN durch ‘aussagekräftiger Name’ ersetzen). Ggf. auch an Interface-bezogene Regeln unter Firewall -> Rules zum Client Interface denken.

Nun den OpenVPN Client Daemon neu starten und die Paketverluste gehören der Vergangenheit an.

Round-Robin Paketverlust am pfSense bei parallelen OpenVPN-Konfigurationen ist ein Original von: Dem Commander1024 sein Blog

Dieses Gerät bietet Folgendes:

• CPU: INTEL Atom N270 mit 1,6GHz
• RAM: 1GB DDR2-SDRAM
• Chipsatz: INTEL 945GSE
• Ethernet: 4x 1GbE Realtek NIC
• 2x USB 2.0
• 1 Compact Flash Slot
• Lüfterloses Kühlsystem
• geringe Stromaufnahme von ~13W

Leider hatte die IPFire Software einige Bugs, die ich anfangs auf die Hardware geschoben hatte, auf dem Intel System aber auch wieder aufgetreten sind. Außerdem ist der IPv6 Support noch in weiter Ferne und einige Funktionen hätte ich gerne besser customizable gewünscht. Also erstmal nach einer Alternative suchen.

Meine Minimalanforderungen an ein vernünftiges Firewall/Router System:

• NAT/DNS-Forwarder (mit der Möglichkeit, eigene DNS Server anzugeben)
• konfigurierbarer DHCP-Server
• konfigurierbare QoS Prioritisierung von IP-Traffic (mit Deep Packet Inspection – l7filter)
• OpenVPN Dial-IN, IPsec Site-to-Site VPN
• mächtige Firewall mit Unterstützung komplexer Regeln
• Radius-Server mit EAP für WPA2-Enterprise Authentifizierung
• geringer Stromverbrauch (powerd)
• nice-to-have: IPv6 Support

Letzten Endes bin ich dann auf pfSense gestoßen. Da die ganz neue 2er Version damals bereits in der Version RC1 verfügbar sind (mittlerweile steht der Stable Release kurz bevor), habe ich direkt auf dieses Pferd gesattelt, zumal mir einige der neuen Funktionen sehr zusagten.

pfSense basiert auf FreeBSD, von dessen Interna ich noch keine große Kenne habe, aber es ist komplett über das Webinterface administrierbar und man muss mit der Shell kaum interagieren (von der Installation abgesehen) um das System nutzen zu können.

Alles in Allem erfüllt pfSense meine Erwartungen an ein modernes, leistungsfähiges Firewall-System sowohl für den Heimeinsatz als auch für den Schutz des Firmennetzwerkes, wo ich eine Juniper Firewall ersetzen konnte. Vorstellen könnte ich mir auch den Einsatz im Rechenzentrum vor dem Serverpark, falls man von einer gewissen Faulheit getrieben wird

Die Bedienung ist sehr intuitiv, bei Standardaufgaben wird man an komplexen Stellen (NAT-Basissetup, QoS Setup, etc.) via Wizard an die Hand genommen, für komplexe Setups, steht eine Experten-GUI zur Verfügung. Informativ sind die Graphen zu CPU-Last und Traffic, und die Zuordnung von Paketen in die QoS Queues um die gewählten Einstellungen zu überprüfen.

Lediglich die Lokalisierung (für deutsche Klientel) an die Eigenheiten der Tastatur  / des Bildschirmzeichensatzes sind verbesserungswürdig, wobei man diese eigentlich nur im Rescuefall bemühen muss. Hier ist es sinnvoll, sich das amerikanische Tastaturlayout einzuprägen. Zwar gibt es auch eine deutsche Belegung, jedoch funktionieren hier einige Sonderzeichen nicht und quittieren Ihren Dienst mit einem Piepton aus dem PC-Speaker.

Auch ist mir ein Problem aufgefallen, dass nur jeder 2. TCP-Verbindungsaufbau in das Netz hinter einem OpenVPN Client gelingt, wenn man parallel noch einen OpenVPN-Remote-Access Server parallel betreibt.

pfSense auf dem Lex Uno Barebone (Atom N270) ist ein Original von: Dem Commander1024 sein Blog

Aus Performancegründen (Upgrade Internetleitung von 20 auf 32 MBit und Ende des Jahres auf 128Mbit) habe ich meinen PC Engines Alix, der schon seit einem knappen Jahr als Router werkelt, in den Ruhestand geschickt und durch ein Intel Atom basiertes System (mit 4xGbE!) ersetzt. Dazu aber später mehr ;-)

Beeindruckend fand ich aber, was vnstat(i) in dieser Zeit an Traffic an dem externen Interface gemessen hat (klar LAN/WLAN war wegen lokalem Traffic noch weit höher aber das ist ja auch keine Kunst).

#win

Penisprotzen ist ein Original von: Dem Commander1024 sein Blog

Die allerersten Einrichtungsgegenstände der neuen Wohnung

Als ich umgezogen bin, hat Unitymedia mir einen D-LINK DIR-300 Router mitgeliefert (wie schon berichtet sogar noch vor dem offiziellen Einzugstermin :-) ) Während der Renovierungsarbeiten wurde dieser auch bereits rege vom Handy, bzw. später mit der PSP rege zum Internetradio hören genutzt, aber schon da war auffällig, dass die Musik doch relativ häufig nach 1-2 Stunden jeweils aus ging. Merkwürdig, aber 1. keine Zeit und 2. keine Mittel zum Bughuntig vorhanden gewesen.

Nach dem Einzug folgte allerdings schnell die Ernüchterung: Die Aussetzer lagen nicht am Stream-Hoster, nicht an der PSP oder dem Handy, und auch nicht an Unitymedia, denn mit nem PC, der direkt am Modem angeschlossen ist, traten diese Phänomene nicht auf.

Dazu muss ich aber auch erwähnen, dass ich in Punkto Internetverfügbarkeit und -qualität höchstwahrscheinlich etwas verwöhnt bin, da ich jahrelang vorher bei meinen Eltern einen kompletten Linux-HomeServer als Router und für diverse andere Zwecke im Einsatz hatte. Nur ist der Stromverbrauch einer solch (potenten) Kiste überhaupt nicht mit meinen finanziellen Planungen bzgl. Stromverbraucht und -kosten unter einen Hut zu bringen, da ich durch die diversen Kisten, die ich zuhause einsetze (Mediacenter, Workstation, Bastelkiste, TV) ohnehin eine happige Stromrechnung habe.

Eine schnelle Google Suche hat mich nun auf dd-wrt und openwrt aufmerksam gemacht, welche beide auf den DIR-300 geflasht werden können. Beim Durchlesen der Featureliste fand ich es zudem noch sehr spannend, dass man mit modifizierter Firmware auch Nettigkeiten wie OpenVPN darauf betreiben kann. Das Rennen machte in diesem Fall übrigens dd-wrt, der zwar nicht offen, aber für privat kostenlos ist. Die Ernüchterung folge aber bald. Der Flash-Speicher des Routers war für OpenVPN eh zu klein, der RAM arg begrenzt und die CPU für 20Mbit Durchsatz viel zu langsam, sodaß der Software Watchdog beim einfachen Runterladen bereits zuschlägt. Mit stärkerer Hardware hätte ich bestimmt Spaß an dd/open-wrt haben können.

Daraufhin habe ich mir ‘günstig’ eine Fritzbox Fon WLAN 7240 besorgt, die zwar für deutlich zuverlässigere Internetanbindung sorgen konnte, allerding in den Einstellung sehr beschränkt war, so war Traffic nur für VoIP prioritisierbar, aber auch hier nur propietäres VPN verfügbar, Das Freetz Projekt versprach da Abhilfe. Sehr schön daran fand ich, dass alles auf der Fritzbox Vorhandene bestehen bleibt und zusätzliche Software paralle ‘daneben’ (mit separater GUI) installiert wird. Leider hat AVM seine openssl-libs (welche unter der Apache License steht) verändert und den Code nicht publik gemacht (was sie durchaus dürfen), was zur Folge hat, dass jede zusätzliche Software statisch gegen eine weitere Version der libssl gegencompiliert werden muss, was im knappen Flash-ROM (16MB) schnell für Knappheit sorgt. Auch kann man die vorhandene libssl nicht durch eine Vanilla Version austauschen, da dann die AVM Tools, die SSL nutzen wollen, crashen.

Davon abgesehen, war die stark im Funktionsumfang erweiterte Fritzbox trotz aller gelösten Widrigkeiten nicht dazu zu bewegen, Laufzeiten von über 10 Tagen zu erreichen, was mich ebenfalls nicht zufrieden stellen konnte. Also musste eine ganz andere Lösung her, von der ganzen Consumer Hardware hatte ich zu dem Zeitpunkt (es waren schon mehr als 2 Monate verstrichen) die Nase voll.

Als mich ein Kumpel auf diese x86 kompatible Hardware hingewiesen hat, sah ich dann alle meine Probleme gelöst: klein, stromsparend und mehr als 4x so kräfig wie Fritzbox und co. Aus Bequemlichkeit entschied ich mich für diese Variante, da sie neben 3 LAN Ports, auch noch einen minipci für die Nachrüstung einer WLAN Karte bot, und eine Echtzeituhr samt Batterie aufgelötet hat. Mit 256MB RAM und 500MHz CPU ist der Stromverbrauch von ~5W mehr als zufriedenstellend. Nur die Software fehlte noch.

Aus vergangenen Tagen kannte ich noch die IPCop Software. Allerdings war sie zu dem Zeitpunkt hoffnungslos veraltet, 2.4er Kernel und Uralt Pakete sprachen keine deutliche Sprache für vollen Hardwaresupport, eine Google suche führte mich zu u. A. zu monowall und pf-sense, allerdings hatten mir beide zu wenig Features, weil sie auf den Unternehmenseinsatz abgestimmt sind, so Sachen wie kleiner samba File-Server, IRC bouncer, oder aber auch Musikserver fehlten mir dran.

Schließlich bin ich auf den IPFire gestoßen, ursprünglich ein IPCop Fork, der mir wegen der hübschen GUI ;-) und vor allem wegen der Addons besonders gut gefallen hat. Wie ich finde, werden hier notwendige Sicherheitsfeatures wie Firewall, Intrusion Detection und -prevention, Proxy, logische Netztrennung (WLAN, LAN, DMZ), DHCP, DNS+Relay, Logging + Graphing + (Hardware) Monitoring, VPN, NTP etc. mit Bequemlichkeiten wie Samba, FTP(e)S, IRC Bouncer. Nicht zuletzt wegen der  Optimierung für embedded Systeme wie PcEngines Alix*, Via Nano inkl. Support für OCF (exp.) und PadLock, WRAP, Soekris ist die Software für einen stromsparenden Home/SoHo Server sehr gut geeignet. Auf leistungsfähigerer Hardware ist natürlich entsprechend mehr möglich. Ich bin so begeistert von dem Stück Software, dass ich mittlerweile (wenn auch im Moment wieder weniger aktiv) Entwickler beim IPFire Projekt bin, und das eine oder andere Code Sniplet beigetragen habe. In dem Zuge möchte ich auch nochmal auf die Präsentationsfolien zum IPFire Talk hinweisen, den ich vor einiger Zeit in der Warpzone gehalten habe.

[Ja zugegeben, dieser Artikel lag ziemlich lange unveröffentlicht in der Pipeline, bis ich ihn nun endlich fertig gestellt bekommen habe ;-) ]

Router Odyssey: PC Engines Alix2D13 + IPFire Software ist ein Original von: Dem Commander1024 sein Blog

IPFire.org

Diese Nacht habe ich in der Warpzone einen Kurztalk über die IPFire Firewall/Router-Distribution beim Hack&Breakfast in der warpzone, Münsters erstem Hackerspace gehalten.

Qik-Stream/Archiv: Commander1024 – IPFire
Präsentationsfolien: IPFire Talk (.pdf)

Leider ist die Präsentation selbst nur in besserer Qualität gestreamed, aber nicht gespeichert worden :-(

IPFire Talk in der #warpzone ist ein Original von: Dem Commander1024 sein Blog

Dec  3 15:38:45 Commander1024 pppd[2322]: No response to 4 echo-requests
Dec  3 15:38:45 Commander1024 pppd[2322]: Serial link appears to be disconnected.
Dec  3 15:38:45 Commander1024 pppd[2322]: Connect time 518.6 minutes.
Dec  3 15:38:45 Commander1024 pppd[2322]: Sent 87572250 bytes, received 135812137 bytes.
Dec  3 15:38:51 Commander1024 pppd[2322]: Connection terminated.
Dec  3 15:38:51 Commander1024 pppd[2322]: Modem hangup
Dec  3 15:39:56 Commander1024 pppd[2322]: Timeout waiting for PADO packets
Dec  3 15:39:56 Commander1024 pppd[2322]: Unable to complete PPPoE Discovery
Dec  3 15:41:01 Commander1024 pppd[2322]: Timeout waiting for PADO packets
Dec  3 15:41:01 Commander1024 pppd[2322]: Unable to complete PPPoE Discovery
Dec  3 15:42:06 Commander1024 pppd[2322]: Timeout waiting for PADO packets
Dec  3 15:42:06 Commander1024 pppd[2322]: Unable to complete PPPoE Discovery
Dec  3 15:43:11 Commander1024 pppd[2322]: Timeout waiting for PADO packets
Dec  3 15:43:11 Commander1024 pppd[2322]: Unable to complete PPPoE Discovery
Dec  3 15:43:41 Commander1024 pppd[2322]: PPP session is 5236
Dec  3 15:43:41 Commander1024 pppd[2322]: Using interface ppp0
Dec  3 15:43:41 Commander1024 pppd[2322]: Connect: ppp0 <–> eth1
Dec  3 15:43:42 Commander1024 pppd[2322]: PAP authentication succeeded
Dec  3 15:43:42 Commander1024 pppd[2322]: peer from calling number 00:90:1A:40:DF:3C authorized
Dec  3 15:43:42 Commander1024 pppd[2322]: Cannot determine ethernet address for proxy ARP
Dec  3 15:43:42 Commander1024 pppd[2322]: local  IP address 89.244.113.173
Dec  3 15:43:42 Commander1024 pppd[2322]: remote IP address 88.130.64.1
Dec  3 15:43:42 Commander1024 pppd[2322]: primary   DNS address 62.220.18.8
Dec  3 15:43:42 Commander1024 pppd[2322]: secondary DNS address 89.246.64.8

In der Standardeinstellung des pppd, so wie er nach der Installation auf dem debian System vorzufinden ist, versucht der Daemon 10x die Wiedereinwahl, bevor er letztendlich entnervt aufgibt. Normalerweise eine durchaus sinnvolle Grenze für die meisten Provider, denn nach 10 Fehlversuchen ist die Chance, dass es noch einmal klappen sollte, eher gering und müllt sonst nur den Syslog zu.

Naja – für die meisten Provider – da scheint die Versatel nicht dazuzugehören. Heute ist dies gerade noch einmal gut gegangen, es hätten aber wieder nur 5 Versuche gefehlt, bis der Internetzugang für den Rest meiner Familie für den Rest des Tages bis zu meiner Wiederankunft unbrauchbar gewesen wäre, ebenso wäre dieser Blog, das Forum unserer WoW Gildet etc. pp. ebenfalls für diesen Zeitraum offline gewesen.

Für jeden eingerichteten Internetzugang, wird “following the debian way” eine Konfigurationsdatei unter /etc/ppp/peers/ angelegt (z. B. durch das benutzerfreundliche Tool “pppoeconf”), dort werden auch verbindungsspezifische Optionen für den ppp-Daemon gleich mit eingetragen und bei Verbindungsaufbau mit übergeben.

Hier kann man durch Auskommentieren, bzw. einfügen der Zeile “maxfail 0” das Limit für Wiederverbindungversuche vom Standardwert 10 auf “unendlich” raufsetzen.

Der Sinn dieser Änderung ist ja gar nicht so weit hergeholt und dürfte sich vermutlich bereits in den nächsten Wochen als sinnvoll erweisen, wenn der DSLAM mal wieder unerreichbar ist oder andere Probleme aufweist.

Die Versatel mal wieder… ist ein Original von: Dem Commander1024 sein Blog