Posts mit dem Label ipfire werden angezeigt. Alle Posts anzeigen
Posts mit dem Label ipfire werden angezeigt. Alle Posts anzeigen

Sonntag, 29. Dezember 2013

DNS im lokalen Netzwerk

Namensauflösung im lokalen Netzwerk mittels DNS


Wer seinen eigenen Server betreibt, möchte diesen gelegentlich von extern wie auch vom internen Netz aus erreichen. Üblicherweise geschieht dies über den FQDN, sei es einer der eigenen Domain oder die eines DDNS Anbieters.
Der Zugriff von einem externen Netzwerk auf einen Server in einem genateten Privaten Netzwerk hängt einerseits von einer korrekten Portweiterleitung und von einer funktionierenden Namensauflösung im Internet ab. Dieser Blog Beitrag geht auf diesen Fall aber nicht näher ein. Viel mehr soll er eine Hilfestellung und einen Lösungsansatz für all jene geben, bei denen der Zugriff von extern funktioniert, vom LAN aus, in dem sich der Server befindet, aber nicht.
Goggle liefert dazu auch schnell mal die Ursache des Problems:
Kann man vom LAN aus über den FQDN den Server im eigenen Netzwerk nicht erreichen, so blockiert mit ziemlicher Sicherheit der Router diesen Zugriff. Goggle gibt im gleichen Atemzug dazu auch noch die Lösung, der Router muss NAT-Loopback auch bekannt als Port-Reflection können.
Viele Hersteller von Routern deaktivieren dieses Feature aus Sicherheitsgründen per Default oder implementieren es schon gar nicht mehr. Ausgenommen sind natürlich die Hersteller welche auf Gedöns ihrer Kunden wieder einen Rückzieher gemacht haben, man will ja schliesslich verkaufen. Namen nenne ich keine ;) Wer sich näher mit der Sicherheitsproblematik auseinandersetzen möchte, empfehle ich dieses Video.


OK kein NAT-Loopback, was nun?

Der Router kann nun kein NAT-Loopback, trotzdem möchte man auf den Komfort der Namensauflösung auch im LAN nicht verzichten. Gut man könnte sich jetzt einen Router eines bekannten Herstellers kaufen welcher dies noch unterstützt oder man macht sich Gedanken wie man die Namensauflösung selber in die Hand nehmen könnte. Damit mich in Zukunft zumindest virtuell keiner mehr verstört anschauen muss wenn ich das Wörtchen DNS in den Mund nehme, habe ich diesen Post geschrieben :)

DNS yourself

Dieser Artikel soll in keiner Weise Anspruch auf eine professionelle DNS Konfiguration haben, sondern Anwendern welche mit der oben genannten Problematik anstehen eine Hilfe leisten.

dnsmasq

Eventuell hat man Glück un betreibt einen Router welcher bereits den dnsmasq Service benutzt und sich dieser auch konfigurieren lässt. Beispiele dazu sind die Appliances von ipfire, dd-wrt oder open-wrt.
Auch der Swisscom Centro Grande Pirelli war noch mit der openRG Version mit freigeschaltetem Admin GUI in der Lage dnsmasq zu konfigurieren.
Ich gehe davon aus das der Router auch gleichzeitig als DNS Resolver im LAN agiert. Dank dnsmasq kann man in der sogenannten Host Datei gezielt "Manipulationen" vornehmen. So wie in unserem Fall nötig die lokale IP eines Servers bei einer Namensauflösung. Wir würden also zu jeder FQDN welche wir nutzen möchten eine entsprechende IP hinterlegen. 
Macht nun ein Client eine Namensabfrage zB. auf  www.DEINSERVER.org, würde der Router die IP Adresse nun nicht mehr bei seinem eingetragenem DNS Server (idR. die des Providers) nachfragen, sondern die IP direkt selber liefern also zB. 192.168.1.10

Hierzu ein Beispiel einer Konfiguration in ipfire:

Hosts Konfiguration in ipfire


Zugegeben, viele welche diese Seite wohl besuchen werden, haben gerade nicht so einen Router im Einsatz, darum Möglichkeit 2 (von vielen anderen)

DNS Server auf der Synology Diskstation


Vielen Usern wird sich das Problem stellen, wenn sie auf ihr NAS zugreifen möchten. Darum und weil ich gerade eine zur Hand habe, zeige ich hier noch die Möglichkeit mittels Synology Diskstation

Mittels Paketmanager lässt sich ganz komfortabel ein DNS Server installieren.
Die Installation selber ist also eigentlich kein Problem. Kümmern wir uns also um die richtige Konfiguration für das lokale Netzwerk.

 

Für die eigene Domain erstellt man im DNS Server eine eigene Master Zone.
In dieser Master Zone belässt man den Domänentyp auf Forward Zone.
Als Domainname gibt man die eigene Domain an zB. myroot.noip.com
Als Master DNS-Server trägt man die IP der Diskstation ein. Den Rest kann man wie im Screenshot gezeigt belassen. 



Nun muss man noch die Eintrage der Zone den eigenen Bedürfnissen entsprechend anpassen.
Für einen IPv4 Eintrag kann man in diesem Fall einen A-Record erstellen. Möchte man wie im Screenshot gezeigt mail.tuxone.ch auf die IP 192.168.3.11 auflösen, muss man dies so konfigurieren. Möchte man die ganze Domain also einfach tuxone.ch auf nur eine IP aufgelöst haben, müsste man das Feld bei Name einfach leer lassen. Die TTL kann man so hoch belassen, ich nehme nicht an das hier gross Fluktuationen im Gange sind.


So, nun hat man einen bereits funktionierenden DNS im lokalen Netzwerk. Damit dieser den Clients aber auch bekannt ist, muss man noch die DHCP Einträge, im einfachen Fall auf dem Router, ändern.
Bei den meisten Consumer Routern gibt der DHCP Server auf dem Router als Namensserver gleich sich selber an. Damit man in Zukunft auch den DNS Server der Diskstation benutzen kann, müssen wir dies auch mitteilen. In der Regel kann man bei den DHCP Einstellungen des Routers manuell mindestens 2 IP Adressen angeben. Beim Nameserver 1 ist die IP der Diskstation einzutragen, beim Nameserver 2 die IP des Routers oder die IP eines öffentlichen Providers.
Für Swisscom Kunden ist im folgenden Screenshot noch eine Beispielkonfiguration zu sehen.
Bei den Centro Routern ist die nötige Einstellung unter Einstellungen > Grundeinstellungen Netzwerk zu finden. Hier kann man die DNS-Server IP Adressen manuell zuteilen:


Nach dem Speichern dieser Einstellung und einem DHCP/release/renew der Clients sollte die Namensauflösung nun auch im LAN wie gewünscht funktionieren.


Samstag, 21. Dezember 2013

ALIX Nachfolger im Test

PC Engines mit neuem APU System Board


PC Engines arbeitet an einem Nachfolger der erfolgreichen ALIX Serie, welche von vielen sehnlichst erwartet wird.
Mit seinem 500Mhz Geode LX Prozessor, den 3 Fast Ethernet Ports und 256MB RAM war und ist das ALIX Board ins besonderem unter den Firewall bauern sehr beliebt. So gibt es von den bekannten Firewall Appliances pfsense, m0n0wall, ipfire und den wrt's, Images welche direkt auf einem ALIX funktionieren.
Mit immer schnelleren Internetanschlüssen und höheren Anforderungen ist das ALIX mit seinen Fast Ethernet Ports und dem dürftigen RAM mittlerweile doch eher knapp bemessen ;)

apu.b1 der Nachfolger

Erfreulich das PC Engines nun wieder mit etwas neuem kommen wird. Natürlich mit Giga Ethernet Ports, natürlich mit mehr RAM. Aktuell hat PC Engines Interessierten eine erste Serie an Beta Boards geliefert. 

Hier die Spezifikationen des Beta Boards

  • Applications:
  • Routers, firewalls, VOIP, dedicated servers, special purpose network plumbing, education tools...
  • CPU:
  • AMD G series T40N or T40E APU, 1 GHz dual core (Bobcat core) with 64 bit support, 32K data + 32K instruction + 512KB L2 cache per core
  • DRAM:
  • 2 GB DDR3-1066 DRAM
  • Storage:
  • Boot from SD card (connected through USB), external USB or m-SATA SSD. 1 SATA data + power connector.
  • Power:
  • About 6 to 12W of 12V DC power depending on CPU load.
  • Expansion:
  • 2 miniPCI express (one with SIM socket for 3G modem), LPC bus, GPIO header, I2C bus, COM2 (3.3V RXD/TXD).
  • Connectivity:
  • Gigabit Ethernet (Realtek RTL8111E), 1 DB9 serial port (console).
  • Firmware:
  • CoreBoot open source system BIOS with support for iPXE and USB boot.
  • Form factor:
  • 6"x6" (152.4 x 152.4 mm), fits in our case1d2*u enclosures.
  • Cooling:
  • Conductive cooling from the CPU and south bridge to the enclosure using a 3 mm alu heat spreader. Please contact us for advice if you want to integrate this board in your own enclosure.


Preislich ist das das Board im selben Rahmen wie der Vorgänger ALIX. Für Rund Fr. 150.- ist man also mit einem Board, AC Adapter, Gehäuse und einer 16GB m-sata SSD dabei. Somit könnte der Erfolg also bereits wieder vorprogrammiert sein.
In Zukunft plant der Hersteller gemäss Webseite die definitive Version mit bis zu 2Ghz und 4GB RAM zu bringen. Das Board verfügt noch über 2 PCI-e Steckplätze für Zusatzhardware. Das System kann von einer SD Karte (Slot vorhanden), über ein externes USB Medium oder über den m-sata Anschluss booten.
Wer Installationen auf ALIX Boards kennt, wird auch hier schnell einen Weg finden. Man kennt's, es gibt keinen VGA Anschluss, die Konfiguration erfolgt über den seriellen Port.

Hands-On

Sofern man ein Gehäuse bestellt hat, wird das Board bereits darauf montiert beliefert. Weil die CPU passiv über das Gehäuse gekühlt wird, ratet der Hersteller zur vorgängigen Kontaktaufnahme. Ich denke nicht umsonst, den das Ding kann ganz schön warm werden :) So ist auch im mitgelieferten Sheet bemerkt, dass man in Zukunft wohl von der T40N CPU (9W TDP) auf die T40E (6W TDP) wechseln möchte.

Als OS habe ich mich für ipfire entschieden, weil dies sowieso meine präferierte Appliance ist.
Die Installation habe ich auf eine 16GB m-sata SSD, welche man direkt bei PC Engines bestellen kann, getätigt. Dazu habe ich das gewöhnliche ALIX Image von ipfire genommen, weil hier die serielle Schnittstelle, welche man zur Installation benötigt, bereits aktiviert ist. Da ich keinen m-sata Leser habe, musste ich einen kleinen Workaround anwenden um das Image auf die m-sata zu bekommen. Da mir nichts besseres eingefallen ist, habe einfach zuerst eine ipfire Installation über einen USB Stick vorgenommen und danach von diesem Hostsystem das Image auf die SSD kopiert. So konnte ich im 2ten Schritt die eigentliche Installation vornehmen.

Bereits beim Feeling handelt es sich mit der neuen CPU im Vergleich zum Geode Prozessor um Welten.
Auch im Vergleich mit meinem Hauptsystem einem Intel Atom D2500 muss sich der T40N 1Ghz dual Core nicht verstecken. So ist das Navigieren im WUI sehr flüssig, der Web-Proxy schnell gestartet.
Gerne würde ich an dieser Stelle iperf Messungen zwischen den LAN Schnittstellen liefern. Leider bin ich aber nicht fähig hier realistische Werte zu liefern, zudem bockt ipfire ohne richtigen WAN Anschluss ein wenig rum.
So habe ich einfach das ganze Setup welches ich von meiner Atom Firewall her habe auf das apu Board transferiert um eventuelle Unterscheide festzustellen. 
Das Gerät läuft an einem VDSL Anschluss eines Schweizer Providers mit einer Servive Geschwindigkeit von
40'000/8'000 kbps,
parallelen IPTV Streams,
Snort, Guardian (IDS),
Web-Proxy, inkl. URL-Filter, Virusscanner,
OpenVPN Server für Roadwarriors und einer Net2Net Verbindung,
und der Forward Firewall "block all"
absolut problemlos. Hier hätte das Alix mit dem IDS und der Proxy Geschichte bereits seine Mühe.
Da in dieser Konstellation noch genügend Luft vorhanden ist, habe ich auch gleich noch das TOR Relay aktiviert, welches ~40GB Bidirektionalen Traffic pro Tag generiert und besonders viele Verbindungen aufbaut.
Jetzt kommt die CPU ins Schwitzen und läuft gegen den Anschlag, was in diesem Fall aber auch beim Atom Board so wäre.
Trotzdem bleibt das Ding und alle Services stabil. Hier meine Profil-ID von ipfire: http://fireinfo.ipfire.org/profile/7378c5927b73fafd9bd170e460667f6c080e9e19


Obwohl das Board noch in der Beta Phase ist und es noch Anpassungen an der Hardware geben wird, ist das Board auf einem überzeugendem Stand.
Ich hoffe das sich die Installation in Zukunft noch ein wenig vereinfachen lässt. Auch ein ein WLAN Adapter im AC Standard wäre für die Zukunft nett. Ich sehe hier für dieses Board und ipfire, Potential weitere User zum Umstieg zu motivieren. Der Erfolg von solchen Appliances auch bei weiteren Usern Fuss zu fassen, hängt meiner Meinung nach auch von einer einfachen Installation und guter Hardware ab. 
Das dass Interesse besteht, sehe ich immer wieder an den Mails welche mich erreichen. An dieser Stelle möchte ich bei allen bedanken und mich bei denen entschuldigen welche keine Antwort bekommen. So macht es mir zB. auch besonders Freude, pfsense Usern zu helfen, obwohl dies nicht meine Hauptfirewall ist.

Ich werde über die Feiertage noch 2-3 Artikel vorbereiten. So viel sei schon gesagt. Es wird spannend, es wird geil und es wird Netz Impact haben. ;D

Frohe Festtage und es Guets Nois

lg Thomas


Samstag, 14. Juli 2012

IPFire: Openvpn for Android

OpenVPN für Android (kein root)

Wer mit seinem Android Smartphone eine VPN Verbindung über OpenVPN erstellen wollte, musste bis anhin sein Gerät rooten.
Sicher nicht jedermanns Geschmack.
Google hat ab Android 4.0 eine VpnService API welche sich Entwickler zu nutze machen können.
OpenVPN for Android von Arne Schwabe ist eines dieser Apps.
In diesem Blogpost zeige ich die Konfiguration dieser App im Zusammenspiel mit IPFire.



Vorbereitung: OpenVPN Server

Ohne VPN Server geht nichts. In diesem Fall verbinde ich mich mit meiner IPFire Firewall. Dazu existieren bereits hervorragende offizielle Wikis. Die Client zu Netzwerk Konfiguration (Roadwarrior) findet man also bereits hier: http://wiki.ipfire.org/de/configuration/services/openvpn/roadwarrior_config
 In wenigen Schritten hat man mit einer IPFire einen OpenVPN Server konfiguriert.

  1. Zuerst erstellt man ein Zertifikat
  2. Danach konfiguriert man das VPN
  3. Falls gewünscht gibt man noch DHCP push options mit (zB DNS für interne Namensauflösung)
  4. Zuletzt erstellt man eine Verbindung für einen Client (Roadwarrior). Ich empfehle ein PKCS12 Datei Passwort zu setzen.
Nachdem man Punkt 4 erledigt hat, kann man unter "client status und kontrolle", Die VPN Konfiguration herunterladen. Dazu klickt man auf das Diskettensymbol. Dadurch lädt man eine ZIP Datei herunter welche die OpenVPN Konfiguration wie auch eine PKCS12 Datei enthält.

Diese Dateien benötigt man um später den VPN Client auf dem Android Smartphone zu konfigurieren. Also entzippt man die Datei und kopiert diese auf das Android Gerät zb unter einem eigenen Ordner wie /
mnt/sdcard/openvpn

OpenVPN Server Synology

Wer keine IPFire Firewall hat, der kann natürlich auch einen anderen VPN Server verwenden. So sind auch die gängigen NAS wie zB von Synology in der Lage als VPN Server zu agieren.

Auch beim Synology Server kann man kann man eine Konfigurationsdatei herunterladen. Statt einer PKCS12 Datei, beinhaltet diese Konfiguration ein Zertifikat. Mann muss also bei der Konfiguration der App als Typ Nutzer/PW + Zertifikat wählen. Nutzer und Passwort ist ein Synology User, welcher VPN Berechtigung hat.


Android Client

Nun aber zur eigentlichen App.
Wie schon Eingangs erwähnt, können Besitzer eines Geräts mit Android 4.0 oder neuer, auf das rooten im Zusammenhang mit OpenVPN verzichten!
Openvpn for Android findet sich im Google Play Market hier: https://play.google.com/store/apps/details?id=de.blinkt.openvpn&hl=de

Ein Start der App bringt einem zur Startseite.
Hier kann man unter VPN Liste, die VPN's konfigurieren. Zudem kann man allgemeine Einstellungen vornehmen, zB das Aktivieren von Traffic Statistiken. Zudem findet man auf der Startseite ein kleines FAQ und Informationen über die Software.

Um das VPN zu konfigurieren, drückt man also auf die VPN Liste.
Diese ist anfangs noch leer. Da man aber bereits eine Konfiguration auf das Gerät kopiert hat, kann man diese mit einem Klick auf das Ordnersymbol hinzufügen.

Hat man die Konfigurationsdatei gefunden, klickt man auf diese und bestätigt diese durch Auswählen.

Nun verfügt man bereits über das Importierte Profil. Allerdings möchte man dieses sicher noch umbenennen und der Pfad zur PKSC12 Datei fehlt auch noch. Um diese Einstellungen vorzunehmen drückt man in der VPN Liste auf das entsprechende Regler Symbol und auf den Stift zur Bearbeitung. Zu den relevanten Einstellungen gelangt man im folgenden Fenster beim Punkt "Basic".




















Unter Basic kann man nun dem Profil einen treffenden Namen verpassen. Falls der VPN Server auch so konfiguriert ist, lässt sich die LZO Komprimierung aktivieren. Ebenfalls fügt man in dieser Maske die PKCS12 Datei hinzu. In meinem Fall ist dies noch Passwort geschützt.

Mit diesen Einstellungen kann man bereits eine VPN Verbindung mittels openvpn zu einer IPFire herstellen.
 Es genügt in der VPN Liste das entsprechende Profil zu wählen.
Nach dem Absegnen einer Sicherheitsmeldung wird die Verbindung aufgebaut und man ist über eine gesicherte Leitung mit dem Heimnetz verbunden.




Falls man die Möglichkeiten dazu hat, wäre es vor den Ferien doch noch eine Idee, so etwas einzurichten, um von Unterwegs eine sichere Verbindung nach Hause zu haben.

Viel Spass :)


Freitag, 1. Juni 2012

Next Generation CPE Firmware Swisscom

IPv6, der nächste Schritt


6 Juni 2012, IPv6 World Launch Day. An diesem Datum wird das Internet der zweiten Generation "eingeschaltet". Bereits am 3 . Februar 2011 wurde von der IANA der letzte freie IPv4 Adressraum vergeben, dennoch funktioniert das Internet noch immer :) also, kein Grund zur Panik
Gerade weil es für den normalen Gebrauch noch keinen Effekt hat, kümmert es den normalen User nicht ob er nun IPv6 ready ist oder nicht. Trotzdem, Swisscom ist seit einiger Zeit bereit ihren Kunden eine IPv6 Verbindung zu ermöglichen.

IPv6 bei Swisscom



Am 21.04.2011 startete der offizielle Trial für Privatkunden um IPv6 zu erproben bzw zu nutzen.
Als Technik setzt Swisscom momentan auf 6RD. Wie es der Name schon sagt ist 6 rapid deployment eine Technik, um Kunden durch einen Provider durch relative einfache Art und Weise, schnell kostengünstig eine IPv6 Konnektivität zu geben. Entwickler Rémis Després (6RD kann auch für seine Initialen stehen) hat bereits 2007 bei Free, einem Französischen Provider bewiesen das er dies innert 5 Wochen einführen konnte!

Auch Swisscom verwendet diese Tunneltechnik erfolgreich um den Privatkunden IPv6 anzubieten.
Bei den Centro Routern haben die Kunden seit einiger Zeit die Möglichkeit IPv6 zu aktivieren. Dies muss bewusst via Kundencenter geschehen (auch wenn es natürlich andere Möglichkeiten dazu gibt). Durch die Aktivierung wird dies dem Router provisioniert. CWPM sei Dank :)
In einer späteren Phase wird IPv6 per Default aktiviert sein!

Es spielt dabei keine Rolle ob man einen Centro Grande oder einen Centro piccolo besitzt. Anfänglich war nur der Centro Grande von Pirelli/ADB in der Lage eine 6RD Verbindung herzustellen. Mittlerweile sind die Motorola Router dazu aber auch fähig.
Auf die Technik selber möchte ich hier an dieser Stelle nicht weiter eingehen.
Wer sich dafür interessiert dem empfehle ich mal die Swisscom labs und deren Trial zu besuchen. http://labs.swisscom.ch/de/trial/ipv6-sneak-preview

IPv6 ist das sicher?

Genau diese Frage stellt sich relativ bald, sofern man sich etwas mit IPv6 beschäftigt. Schauermärchen des übelsten tun noch ihr übriges um ein mulmiges Gefühl zu hinterlassen.
Bisher war man sich gewohnt das man durch das NAT eines Routers zumindest einigermassen sicher im Internet unterwegs ist. Im Zusammenhang mit IPv6 wird auch immer wieder die Privatsphäre genannt.
Heikle Themen, für die es Lösungen gibt, unerfahrene Anwender aber mal zunächst sicher abhalten IPv6 anzuwenden bzw zu aktivieren.
Daher auch der primäre Wunsch der Anwender, dass das CPE des Provider, zumindest mal für den grundsätzlichen Schutz sorgen soll. Hier war bisher wenig bis gar nichts vorhanden. So verteilt der Centro Grande von Pirelli/ADB zwar fleissig Adressen, lässt aber sämtlichen IPv6 Traffic ungehindert durch. Beim Centro von Motorola sah es bisher etwas "besser" aus. Dieser Verteilt auch seine Adressen, blockiert aber sämtlichen nicht aus dem LAN initiierten Verkehr. Ausnahmen sind auf einfache Art keine zu realisieren.
Kein Zustand der wirklich Freude macht.
Schritt 1, die Adressverteilung und ein funktionierendes 6RD wurden also schnell mal erreicht.
Zeit nun für Schritt 2. Gewinne die normalen User durch Sicherheit.

Sicherheit durch Router

Um Sicherheit bei IPv6 zu gewährleisten gehören sauber konfigurierte Client Firewalls zum wichtigsten.
Mit einer  aktivierten Windows Firewall ist man also schon mal gut unterwegs.
Um einen ähnlichen Schutz zu haben wie bei NAT, braucht es aber eine Hardware Firewall, zB im Router.

Die Zeit ist gekommen, auch Swisscom wird sie haben :)

In einer Vorversion der Centro Motorola Firmware, habe ich dieses neue Feature unter die Lupe genommen. Die Roadmap sieht momentan vor, dass ab Juli 2012 die Motorola Geräte mit dieser neuen Firmware ausgestattet werden. Bei Pirelli/ADB wird es länger dauern, man geht von November aus.
Interessierte müssen keine Beziehung zu Swisscom haben um diese Firmware von Motorola zu testen.
Das Wissen wie Swisscom die Firmwares speichert und ein wenig offene Augen an den richtigen Stellen reichen zum Download. Aus Integrität gebe ich den Link hier nicht an und bitte dies auch nicht in den Kommentaren zu tun. Mir hat keiner von Swisscom geholfen diese Firmware zu finden, es kann also nicht so schwer sein :D
Ansonsten abwarten und Tee trinken. Die Firmwares sollten ja bald mal ausrollen.

NAT IPv4

Wer den Centro Grande Motorola kennt, wird auch die gewohnte Portweiterleitung wieder finden. IPv6 bei Swisscom wird im Dual Stack angeboten. Sprich IPv4 steht immer noch zur Verfügung. Logisch, das Internet wäre teilweise noch relativ langweilig ;) Darum ist es auch wichtig und wird es auch noch lange bleiben, dass man seine IPv4 Server versorgen kann.
Unter Einstellungen > Port- Weiterleitung findet man das gewohnte Menü um vorkonfigurierte Dienste auf einen Host zu leiten.
Ist ein Dienst nicht vorhanden, kann man diesen im Menü Einstellungen > Dienste, eröffnen.
An dieser Stelle sei gesagt. Was man von jedem 08-15 Router gewohnt ist, dass sogenannte NAPT, steht im WUI immer noch nicht zur Verfügung. Einer der Hauptgründe warum die Centros als DAU Geräte angesehen werden. Es sind die DAU's die nicht verstehen das die Möglichkeit via Shell trotzdem besteht. Trotzdem unverständlich warum dies via WUI aber nicht möglich ist.
Swisscom, hier bitte endlich mal nachbessern! Früher war es ja auch möglich :) Die Router an sich, sind ja ansonsten i.O.


IPv6 Firewall

Soweit so gut. Nun aber zur Neuerung, der IPv6 Firewall. Sobald man im Kundencenter IPv6 aktiviert hat, steht im WUI ein neuer Menüpunkt zur Verfügung.
Dieser nennt sich Sicherheit.

Sicherheit in 3 Stufen




Mittel

Defaultmässig ist die IPv6 Firewall auf Mittel Hoch gestellt.

Falls die IPv6 Firewall Stufe ""Mittel"" aktiviert ist, wird der IPv6 Datenverkehr in beide Richtungen (ankommend und abgehend) zugelassen. Davon ausgenommen ist eine Gruppe von Standard Protokollen (Gruppiert in ""Fernwartungs-Protokolle"" und ""LAN-Protokolle) und alle benutzerdefinierten Regeln, welche Sie definieren. TCP Ports, welche zur Kategorie "Fernwartungs-Protokolle" gehören, werden nicht aus dem ankommenden Datenverkehr gefiltert. UDP und TCP Ports, welche zur Kategorie "LAN-Protokolle" gehören werden im abgehenden und ankommenden Datenverkehr blockiert.
Andere grundlegende Datenverkehrs-Kontrollen sind aktiviert um vor ungültigem und schädlichem Verkehr zu schützen.
Falls Sie eine Regel durch deaktivieren des Kontrollkästchens ausschalten, wird automatisch der Firewall-Status "Mittel" angewendet, welcher für die spezifizierten Ports den Datenverkehr in beiden Richtungen (ankommend und abgehend) erlaubt.

Hier ist das Standardverhalten auf "erlauben". Die Firewall lässt Traffic durch. Ausgenommen ist aber ein ganzes Set an wichtigen Protokollen, die eigentlich nur im LAN verwendet oder als Remote Zugang genutzt werden. Diese Protokolle und Ports sind gesperrt, lassen sich aber mittels einfachem Klick auf erlaubt setzen.
Wichtig: Erlaubter Traffic bezieht sich immer auf alle Hosts im LAN. Erlaubt man zB. FTP wird dies für alle Adressen nicht mehr geblockt. Darum ist Client Sicherheit immer nach das A und O.
Hier die gesperrten Dienste und Protokolle

Fernwartungs-Protokolle    

AktivierenDienstProtokollPortsBlockieren
Secure Shell (SS)TCP22Eingehend
TelnetTCP23Eingehend
Apple Airport PPP Status etc.TCP192Eingehend
Mac OS X Server AdminTCP311Eingehend
rloginTCP513Eingehend
TCP ShellTCP514Eingehend
Mac OS X Server AdministrationTCP660Eingehend
Mac OS X Server AdministrationTCP687Eingehend
Samba Web Administration ToolTCP901Eingehend
Telnet over TLS/SSLTCP992Eingehend
QT Server AdministrationTCP1220Eingehend
VNC ListenerTCP5500Eingehend
VNC over HTTPTCP5800Eingehend
VNC remote desktop protocolTCP5900Eingehend
TeamViewer remote desktop proto.TCP5938Eingehend
WBEM HTTP, Apple Remote DesktopTCP5988Eingehend


LAN Protokolle

AktivierenDienstProtokollPortsBlockieren
WINSBeide42Ankommend/Abgehend
TACACSBeide49Ankommend/Abgehend
Trivial File Transfer ProtocolBeide69Ankommend/Abgehend
Mac OS X Server Password ServerBeide106Ankommend/Abgehend
ONC RPC (SunRPC)Beide111Ankommend/Abgehend
SQL ServicesBeide118Ankommend/Abgehend
DCOM Service Control ManagerBeide135Ankommend/Abgehend
NetBIOS Name ServiceBeide137Ankommend/Abgehend
NetBIOS Datagram ServiceBeide138Ankommend/Abgehend
NetBIOS Session ServiceBeide139Ankommend/Abgehend
SQL ServiceBeide156Ankommend/Abgehend
SNMPBeide161Ankommend/Abgehend
SNMP TrapsBeide162Ankommend/Abgehend
Print-srv, Network PostScriptBeide170Ankommend/Abgehend
X Display Manager Ctrl (XDMCP)Beide177Ankommend/Abgehend
Service Location Protocol (SLP)Beide427Ankommend/Abgehend
Microsoft-DS SMB file sharingBeide445Ankommend/Abgehend
Kerberos Change/Set passwordBeide464Ankommend/Abgehend
Rexec, Remote Process ExecutionBeide512Ankommend/Abgehend
Line Printer DaemonBeide515Ankommend/Abgehend
RIPngBeide521Ankommend/Abgehend
RPCBeide530Ankommend/Abgehend
DHCPv6 clientBeide546Ankommend/Abgehend
DHCPv6 serverBeide547Ankommend/Abgehend
AFP over TCPBeide548Ankommend/Abgehend
Internet Printing ProtocolBeide631Ankommend/Abgehend
LDAP over TLS/SSLBeide636Ankommend/Abgehend
Kerberos administrationBeide749Ankommend/Abgehend
iSCSI (RFC 3720)Beide860Ankommend/Abgehend
MSSQL ServerBeide1433Ankommend/Abgehend
MSSQL MonitorBeide1434Ankommend/Abgehend
RADIUS authenticationBeide1812Ankommend/Abgehend
RADIUS accountingBeide1813Ankommend/Abgehend
SSDPBeide1900Ankommend/Abgehend
NFSBeide2049Ankommend/Abgehend
MySQL ServerBeide3306Ankommend/Abgehend
Web Services DiscoveryBeide3702Ankommend/Abgehend
UPnPBeide5000Ankommend/Abgehend
NAT Port Mapping ProtocolBeide5351Ankommend/Abgehend
NAT Port Mapping ProtocolBeide5353Ankommend/Abgehend
Link-Lcl Mcast Name ResolutionBeide5355Ankommend/Abgehend
WSDAPI over HTTPBeide5357Ankommend/Abgehend
WSDAPI over HTTPSBeide5358Ankommend/Abgehend
PostgreSQLBeide5432Ankommend/Abgehend

Hoch


Falls die IPv6 Firewall Stufe ""Hoch"" aktiviert ist, wird der IPv6 Datenverkehr nur in abgehender Richtungen zugelassen. Davon ausgenommen sind ""LAN-Protokolle"" und benutzerdefinierte Regeln, welche Sie definieren. UDP und TCP Ports, welche zur Kategorie "LAN-Protokolle" gehören werden im abgehenden und ankommenden Datenverkehr blockiert.
Andere grundlegende Datenverkehrs-Kontrollen sind aktiviert um vor ungültigem und schädlichem Verkehr zu schützen.
Falls Sie eine Regel, durch deaktivieren des Kontrollkästchens ausschalten, wird automatisch der Firewall-Status "Hoch" angewendet, welcher für die spezifizierten Ports den Datenverkehr nur in abgehender Richtung erlaubt.
Benutzerdefinierte Regeln mit der Richtlinie "Erlaube ankommenden Datenverkehr" erlauben gleichzeitig Verkehr in abgehender Richtung, entsprechend dem Verhalten der Firewall in der Einstellung "Hoch".

Hier ist das Standardverhalten "verbieten" Auf Stufe Hoch agiert hier die Stateful Firewall ähnlich wie ein NAT Router. Nicht aus dem LAN initiierter Verkehr wird verworfen. Auch hier die Möglichkeit Dienste von extern zu erlauben, indem man auf einen der vordefinierten Dienste klickt oder selber eine Regel erstellt.

Standardregeln  

LAN Protokolle

AktivierenDienstProtokollPortsBlockieren
WINSBeide42Blockiere gesamten Verkehr
TACACSBeide49Blockiere gesamten Verkehr
Trivial File Transfer ProtocolBeide69Blockiere gesamten Verkehr
Mac OS X Server Password ServerBeide106Blockiere gesamten Verkehr
ONC RPC (SunRPC)Beide111Blockiere gesamten Verkehr
SQL ServicesBeide118Blockiere gesamten Verkehr
DCOM Service Control ManagerBeide135Blockiere gesamten Verkehr
NetBIOS Name ServiceBeide137Blockiere gesamten Verkehr
NetBIOS Datagram ServiceBeide138Blockiere gesamten Verkehr
NetBIOS Session ServiceBeide139Blockiere gesamten Verkehr
SQL ServiceBeide156Blockiere gesamten Verkehr
SNMPBeide161Blockiere gesamten Verkehr
SNMP TrapsBeide162Blockiere gesamten Verkehr
Print-srv, Network PostScriptBeide170Blockiere gesamten Verkehr
X Display Manager Ctrl (XDMCP)Beide177Blockiere gesamten Verkehr
Service Location Protocol (SLP)Beide427Blockiere gesamten Verkehr
Microsoft-DS SMB file sharingBeide445Blockiere gesamten Verkehr
Kerberos Change/Set passwordBeide464Blockiere gesamten Verkehr
Rexec, Remote Process ExecutionBeide512Blockiere gesamten Verkehr
Line Printer DaemonBeide515Blockiere gesamten Verkehr
RIPngBeide521Blockiere gesamten Verkehr
RPCBeide530Blockiere gesamten Verkehr
DHCPv6 clientBeide546Blockiere gesamten Verkehr
DHCPv6 serverBeide547Blockiere gesamten Verkehr
AFP over TCPBeide548Blockiere gesamten Verkehr
Internet Printing ProtocolBeide631Blockiere gesamten Verkehr
LDAP over TLS/SSLBeide636Blockiere gesamten Verkehr
Kerberos administrationBeide749Blockiere gesamten Verkehr
iSCSI (RFC 3720)Beide860Blockiere gesamten Verkehr
MSSQL ServerBeide1433Blockiere gesamten Verkehr
MSSQL MonitorBeide1434Blockiere gesamten Verkehr
RADIUS authenticationBeide1812Blockiere gesamten Verkehr
RADIUS accountingBeide1813Blockiere gesamten Verkehr
SSDPBeide1900Blockiere gesamten Verkehr
NFSBeide2049Blockiere gesamten Verkehr
MySQL ServerBeide3306Blockiere gesamten Verkehr
Web Services DiscoveryBeide3702Blockiere gesamten Verkehr
UPnPBeide5000Blockiere gesamten Verkehr
NAT Port Mapping ProtocolBeide5351Blockiere gesamten Verkehr
NAT Port Mapping ProtocolBeide5353Blockiere gesamten Verkehr
Link-Lcl Mcast Name ResolutionBeide5355Blockiere gesamten Verkehr
WSDAPI over HTTPBeide5357Blockiere gesamten Verkehr
WSDAPI over HTTPSBeide5358Blockiere gesamten Verkehr
PostgreSQLBeide5432Blockiere gesamten Verkehr

Aus

Es ist nur eine grundlegende Datenverkehrs-Kontrolle aktiviert um vor ungültigem und schädlichem Verkehr zu schützen, da die IPv6 Firewall ausgeschalten ist. Schalten Sie die Firewall ein um sämtliche Funktionen des Experten Modus zu benützen.

Selbstverständlich kann man die Firewall auch deaktivieren und eine eigene Schutzlösung verwenden.

Regeln erstellen

Ähnlich wie bei der Portweiterleitung bei IPv4 kann man auch eigene Regeln für IPv6 erstellen um diese zu erlauben oder explizit zu blocken. Wie schon erwähnt leitet man hier nicht auf einen einzelnen Host, sondern schaltet diesen Traffic allgemein ein oder aus.


What else?

Hmm es gibt da schon noch was :)

Leider hat sich seit dem Update auf SOC OS 9.0.7 die IP-Weiterleitungs Funktion in eine Nichtfunktion verwandelt. Mann kennt die Workarounds und das ist auch gut so.
Allerdings ist der sogenannte Data pump ein wichtiger Teil eines DSL Routers. Es macht also durchaus Sinn auch einen Router der mal im Bridge Mode ist irgendwann wieder mal eine neue Version zu spendieren.
Nun gut, leider ist der Bridge Mode immer noch nicht vorhanden. Als Trostpflaster funktioniert nun aber die IP Weiterleitung wieder einwandfrei.
Dazu geht man unter Einstellungen auf das Menü IP-Weiterleitung und wählt, richtig, IP-Weiterleitung. Der gewünschte Host muss seine IP via DHCP beziehen und bereits an den Router angeschlossen sein. Ist dies der Fall, lässt sich der Host auswählen. Der Centro Router weisst noch darauf hin das der Centro Router selber einen neustart braucht, sowie der IP-Weiterleitungs Host einen neuen DHCP request machen muss.




Tux0ne machen die Centro Router selber wie auch die Witzboxen von AVM keine Freude. Klar, dass die ipfire für den Test hinhalten muss. Selbstverständlich funktioniert auch Swisscom TV in diesem Modus auch noch einwandfrei (hinter meiner ipfire).
Luft für Spielereien ist auch noch vorhanden. Da ipfire 2.11 noch nicht wirklich IPv6 ready ist (was aber in ipfire3 noch kommt), ist der Centro Router als IPv6 Gateway in meinem Netz durchaus vorstellbar.

Ansonsten sind auch Kommentare erlaubt.



Kommt Zeit, kommt Rat, kommt Attentat.