Wer schon mal in die USA geflogen ist, kennt sicher das Electronic System for Travel Authorization (ESTA). Jeder Fluggast, der in die USA einreist, dort umsteigt oder sie sogar nur überfliegt, muss sich dort anmelden und eine Erlaubnis einholen. Dieser Spaß kostet 14 US-Dollar und wird via pay.gov bezahlt.

Als ich letztes Jahr für eine Reise in die USA einen ESTA-Antrag gestellt habe, war pay.gov für mich über die Telekom nicht erreichbar. Via Mobilfunk ging es merkwürdigerweise problemlos, also lag für mich das Problem bei der Telekom. Ein kurzer Austausch mit @telekom_hilft bei Twitter brachte leider keine Besserung, da der Zugriff auf pay.gov für den Support-Mitarbeiter einwandfrei funktionierte.

Ich hatte das Problem nicht groß weiter verfolgt, aber immer wieder mal ausprobiert, ob die Seite erreichbar ist. Bisher war das nie der Fall und es hat mich dann in den letzten Tagen der Ehrgeiz gepackt, endlich die Ursache zu finden.

Nach ein paar Google-Recherchen stand schnell fest, dass die Probleme nur mit IPv6 auftreten. Über IPv4 ging alles einwandfrei. IPv6 kam für mich als Ursache nicht in Frage, weil die DNS-Einträge für pay.gov keinen AAAA Resource Record aufweisen. Da man im Browser den Request nicht im Inspector verfolgen kann, weil die Verbindung bzw. der TLS Handshake gar nicht erst aufgebaut werden konnten, musste Wireshark ran.

Siehe da, der Zugriff erfolgt über IPv6 und die Pakete von pay.gov werden verworfen, weil sie ungültig sind. Nach weiteren Google-Suchen stand fest, dass die Ursachen mit der Maximum Transfer Unit (MTU) bzw. der Maximum Segment Size (MSS) zusammenhängen können. Die MTU-Größe liegt bei DSL-Zugängen bei 1.492 Byte: maximale MTU-Größe abzüglich PPPoE-Header-Größe, also 1.500 Byte - 8 Byte. Zur Berechnung des Schwellenwertes für MSS Clamping, wird von der tatsächlichen MTU-Größe zusätzlich die maximale TCP/IP-Header-Größe abgezogen: 1.492 Byte - 40 Byte = 1.452 Byte

Ich hatte daher die MTU- und MSS-Werte im EdgeRouter überprüft und sie waren in Ordnung. Nach weiteren Recherchen war klar, dass der EdgeRouter den Wert für MSS Clamping standardmäßig nur für IPv4 einstellt, da der Wert für IPv6 separat eingestellt werden muss. Gesagt, getan. Und? Nichts, der Verbindungsaufbau misslingt nach wie vor.

Blöderweise hatte ich vergessen, dass TCP/IPv6-Header eine maximale Länge von 60 Byte haben können und daher die MSS auf 1.432 Byte gestellt werden muss. Kaum war das erledigt, ließ sich pay.gov problemlos aufrufen.

Dieses Problem betrifft offenbar alle Seiten der US-Regierung unter der TLD .gov, kann aber auch bei anderen Websites auftreten. Es muss nicht zwangsläufig zum Totalausfall führen, da ein Client via ICMP mitteilen kann, dass der Server die Pakete weiter fragmentieren soll. In diesem konkreten Fall funktioniert das aber nicht korrekt, weil die Infrastruktur von pay.gov jegliche ICMP-Pakete ignoriert. Solche Maßnahmen werden oft getroffen, um kritische Systeme vor DDoS-Attacken zu schützen.

MSS Clamping ist eine Art Hack, um dieses Problem anderweitig zu lösen. Paket-Header werden bei der Verarbeitung im Router entsprechend angepasst und so dem Server mitgeteilt, dass er bitte kleinere Pakete als Antwort schicken soll.

So sehr ich die Motivation verstehe, ICMP-Pakete aus Sicherheitsgründen abzuweisen, ist es in diesem Fall eine ungünstige Entscheidung, da IPv6 für seine Funktionen wesentlich stärker von ICMP abhängig ist, als es IPv4 je war.

TL;DR

Sollte jemand merkwürdige Probleme mit nicht aufrufbaren Websites haben oder immer wieder bestimmte Seiten beim ersten Laden sehr lange brauchen, z.B. weil der TLS-Handshake ungewöhnlich viel Zeit beansprucht, kann MSS Clamping Abhilfe schaffen.

Für IPv4 sollte es der EdgeRouter bereits richtig einstellen. Für IPv6 lässt es sich, wie üblich, nur via CLI konfigurieren:

set firewall options mss-clamp6 interface-type pppoe
set firewall options mss-clamp6 mss 1432

Für IPv4 sollte es so aussehen:

ubnt@ubnt# show firewall options mss-clamp
 interface-type pppoe
 mss 1452

Statt des Interface Types pppoe kann auch all aktiv sein, das betrifft neben PPPoE dann z.B. auch relevante VPN-Protokolle.

Commit und speichern, Problem gelöst.

Hinweis: Die MSS-Werte beziehen sich nur auf DSL-Verbindungen. Bei allen anderen Verbindungstypen, die kein PPPoE nutzen (z.B. Kabel), muss man die 8 Byte für den PPPoE-Header nicht abziehen und kommt auf 1.460 bzw. 1.440 Byte.

Summary in English

Do you have strange loading problems with certain websites? They do not work at all or the first request takes a long time? Then consider MSS Clamping as a possible solution.

In my case, pay.gov was impossible to reach via IPv6. If the server sends too big packets, your system can’t process them correctly. Wireshark will help you to detect such faulty packets.

MSS clamping will alter the packet headers within your router to tell the server the max allowed packet size without the usage of ICMP. It’s kind of a hack, but it works fine and is sometimes the only solution, if the server blocks ICMP, as US government websites do.

In case of IPv4, the EdgeRouter’s wizards did already all the work for you or you can use the MSS clamping GUI wizard after a manual configuration. Unfortunately and as always, there are no ways to configure any IPv6 features via the GUI. You have to rely on the CLI instead:

set firewall options mss-clamp6 interface-type pppoe
set firewall options mss-clamp6 mss 1432

Your IPv4 MSS clamping config should look like this:

ubnt@ubnt# show firewall options mss-clamp
 interface-type pppoe
 mss 1452

Beware: the above mentioned values are for DSL connections using PPPoE and are based on the following calculations:

• MTU: 1,500 bytes - 8 bytes (max. allowed MTU size - PPPoE header size) = 1,492 bytes
• MSS: 1,492 bytes (MTU value) - 40 bytes (TCP/IPv4 header size) or 60 bytes (TCP/IPv6 header size) = 1,452 bytes (IPv4) or 1,432 bytes (IPv6)

For other connection types without PPPoE, you don’t have to subtract the PPPoE header size. Cable connections should work fine with 1,460 bytes for IPv4 and respectively 1,440 bytes for IPv6.

The following commands work on macOS or a Linux distribution only.

ssh user@edgerouter_ip 'sudo tcpdump -f -i eth0 -w -' | wireshark -k -i -

If you’re monitoring the interface with your SSH connection to the EdgeRouter, you may want to ignore traffic on port 22.

ssh user@edgerouter_ip 'sudo tcpdump -f -i eth1 -w - not port 22' | wireshark -k -i -

Update for Windows users

After some fiddling around, I found a working solution for Windows 10 users. You just have to install the SSH client beta and Wireshark for Windows.

ssh user@edgerouter_ip "sudo tcpdump -f -i eth0 -w -" | "C:\Program Files\Wireshark\Wireshark.exe" -k -i -

Troubleshooting advice:

• The Windows SSH client will only work on command shells with admin privileges.
• Use only double quotes. The Windows command line doesn’t like single quotes as well as a shell on unixoid operating systems.
• Adjust the path to Wireshark if it’s not installed in the default directory.
• CTRL + C or CTRL + X will not work to terminate the SSH connection. You have to close the window instead.

In diesem Post erkläre ich meine EdgeRouter- bzw. Netzwerk-Konfiguration, da ein IPTV-System wie EntertainTV besondere Anforderungen stellt. Damit IPTV überhaupt funktionieren kann, muss die Telekom Multicasts verwenden. Im Gegensatz zu DVB-C oder DVB-S2, wird hier nicht jedem Kunden alles geschickt, um sich auszusuchen, was man anschaut. Man bekommt nur das geliefert, was auch tatsächlich angesehen wird. Multicasts erlauben hier die effiziente Verteilung von Paketen, ohne das eigene Netz zu überlasten.

Damit Multicasts funktionieren, muss auch die lokale Netzwerk-Hardware mitspielen. Darum empfiehlt die Telekom u.A. ihre IPTV-Receiver direkt mit dem Router zu verbinden. Das ist sicher kein Problem, wenn der Telefonanschluss im Wohnzimmer ist, aber gerade in älteren Wohnungen, ist das eher selten der Fall und Kabelkanäle sind auch rar. Sobald Switches oder Access Points ins Spiel kommen, müssen die Geräte das Internet Group Multicast Protocol in Version 3 (IGMPv3) unterstützen. Wenn sie das nicht tun, wird aus dem Multicast ein Broadcast an alle Geräte ins Netzwerk. Bei einem HD-Stream mit 10 Mbit/s und 20 Geräten im Netzwerk, würde man so 200 Mbit/s Last erzeugen. Das mag im LAN noch evtl. verschmerzbar sein, aber in einem WLAN sieht die Sache anders aus. Leider unterstützt insbesondere Consumer-Netzwerk-Hardware oft kein IGMP oder nur eine ältere Version, die ebenfalls in Broadcasts resultiert.

Eine wirklich günstige Lösung gibt’s dafür leider nicht. Man kann sich entweder mit entsprechend IGMP-fähiger Hardware helfen oder mit einem separaten Netz über ein VLAN. Dummerweise unterstützen Consumer-Geräte meist auch keine VLANs.

Ohne Managed Switches, die IGMPv3 und/oder VLANs unterstützen, kommt man hier leider nicht weit. Mein Netzwerk besteht daher nur noch aus Netzwerk-Hardware von Ubiquiti: ein EdgeRouter X, drei UniFi Switches und zwei UniFi Access Points.

Konfiguration

Folgende Punkte beschreiben die Konfiguration der UniFi-Hardware und des EdgeRouters. Wie immer gilt: ich verwende einen EdgeRouter X, aber es sollte auch problemlos mit jedem anderen EdgeRouter funktionieren.

UniFi

Der einfache Teil vorweg: für die UniFi-Geräte reicht es, IGMP Snooping in den Einstellungen unter Networks bzw. Wireless Networks für das jeweilige Netz zu aktivieren und die Geräte neu zu provisionieren.

Falls jemand ein UniFi Security Gateway als Router verwenden sollte, müssen noch weitere Einstellungen im CLI des Controllers vorgenommen werden, damit der IGMP Proxy läuft. Eine Anleitung dazu gibt’s hier.

EdgeRouter

Wie auch für das USG gilt, dass auf dem EdgeRouter ein IGMP Proxy laufen muss. Das verlangt Einstellungen, die nur über das CLI erfolgen können. Der Einfachheit halber, werde ich auch die entsprechenden Firewall-Regeln über das CLI beschreiben, da man die einfach kopieren und nach seinen Wünschen anpassen kann – im Gegensatz zu einer Screenshot-Orgie.

Firewall

Grundsätzlich sollte jeder EdgeRouter min. zwei Firewall-Rulesets haben, in und local. Bei mir heißen sie WAN_IN sowie WAN_LOCAL und werden daher auch in diesem Beispiel verwendet. Das Modem hängt an eth0 und die Verbindung wird über eth1 ins restliche Netzwerk verteilt.

Die folgenden Firewall-Regeln richten sich an Nutzer von EntertainTV bzw. Telekom-Kunden im BNG. Wer noch nicht im BNG ist bzw. das alte Entertain nutzt, muss teilweise andere IP-Adressen freigeben und dazu VLAN 8 verwenden, weil im alten Netz die Internetverbindung (VLAN 7) und Entertain (VLAN 8) getrennt laufen, siehe den Beitrag von TauSys.

Als erstes müssen IGMP und Multicast UDP-Pakete für WAN_IN erlaubt werden:

set firewall name WAN_IN rule 1 action accept
set firewall name WAN_IN rule 1 description 'Allow IGMP'
set firewall name WAN_IN rule 1 log disable
set firewall name WAN_IN rule 1 protocol igmp
set firewall name WAN_IN rule 2 action accept
set firewall name WAN_IN rule 2 description 'Allow IPTV Multicast UDP'
set firewall name WAN_IN rule 2 destination address 224.0.0.0/4
set firewall name WAN_IN rule 2 log disable
set firewall name WAN_IN rule 2 protocol udp

Anschließend werden Multicast UDP-Pakete lokal für WAN_LOCAL erlaubt:

set firewall name WAN_LOCAL rule 1 action accept
set firewall name WAN_LOCAL rule 1 description 'Allow Multicast'
set firewall name WAN_LOCAL rule 1 destination address 224.0.0.0/4
set firewall name WAN_LOCAL rule 1 log disable
set firewall name WAN_LOCAL rule 1 protocol all

Bitte beachtet, dass die Reihenfolge der Regeln entsprechend passt und die neuen Regeln immer vor der Drop-Regel stehen, die nicht erlaubte Pakete entsorgen soll.

Was hat es mit dem Netz 224.0.0.0/4 auf sich? Sehr vereinfacht gesagt: ein Bereich bestimmter IPv4-Adressen, die für Multicast-Verwaltung genutzt werden können.

IGMP Proxy

Der schon mehrfach genannte IGMP Proxy ist ein vergleichsweise simples Tool, um IGMP-Pakete an die entsprechenden Stellen weiterzuleiten. Ohnehin würden die Pakete im Router quasi hängenbleiben.

set protocols igmp-proxy interface eth1 alt-subnet 0.0.0.0/0
set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth1 threshold 1
set protocols igmp-proxy interface eth1 whitelist 232.0.0.0/16
set protocols igmp-proxy interface pppoe0 alt-subnet 0.0.0.0/0
set protocols igmp-proxy interface pppoe0 role upstream
set protocols igmp-proxy interface pppoe0 threshold 1

Das Beispiel geht davon aus, dass die restlichen Geräte über eth1 am EgdeRouter hängen. Falls jemand ein VLAN verwendet, wie ich es im vorherigen Post beschrieben habe, muss an das Interface noch die VLAN-ID angehängt werden, z.B. eth1.10.

Entertain bzw. EntertainTV funktionieren aktuell nur via IPv4, daher ist eine IPv6-Konfiguration nicht notwendig.

Das war’s eigentlich schon. Ihr müsst nur noch einen Commit machen und speichern. Der IGMP Proxy sollte damit automatisch starten.

Ich hatte die ganze Konfiguration bereits anhand diverser Blog- und Foren-Posts im Voraus gemacht und erstaunlicherweise hat sie auf Anhieb funktioniert. Es treten keinerlei Broadcast-Probleme auf.

Falls Ihr den Verdacht habt, dass etwas nicht stimmt, lässt sich das mit Wireshark sehr einfach überprüfen: einfach die aktive Netzwerk-Schnittstelle abfragen und auf Broadcasts bzw. ungewöhnlich viele UDP-Pakete achten, die von den EntertainTV-IP-Adressen kommen.

The following configuration shows my VLAN setup for IPTV services, since the receivers do not need access to the other networks and an isolated network for IPTV can avoid trouble with multicast/IGMP. You don’t use IPTV? No problem, you could use the config to create a guest network or for other untrusted devices.

I’m using an EdgeRouter X, but this configuration will work on any other EdgeRouter. The general approach should even work on a UniFi router like the USG.

Update (15. February 2018)

I have completely rewritten the firewall configuration guide, since the first version had a substantial flaw: it will cut the access from the VLAN to your LAN, but the VLAN can connect to all router services. So, someone could open an SSH connection to your EdgeRouter and that’s bad.

If you have already followed the old guide, please delete the ruleset and use the new guide to create a proper firewall config.

Network Setup

• 10.0.0.0/24: home network on eth1
• 192.168.1.0/24: management LAN for my DSL modem on eth0
• 10.0.1.0/24: eth2, eth3 and eth4 as switched ports on the EdgeRouter X

My management LAN is connected to the other networks via a custom NAT rule.

The main LAN consists of the three UniFi switches (US-8 and US-8 POE) and two UniFi access points (AP AC Lite). UniFi switches are fully supporting VLANs, so I can terminate a VLAN to any switch port within the network.

Why private class A networks? Well, why not? And I like short IP addresses.

But the management LAN is a private class C network? Yeah, I’m leaving the modem on its default network configuration to avoid trouble, if I ever have to reset its config. I like to experiment with other firmware versions. Currently I’m trying a firmware for Australian ISPs. So far it’s working great and it disables some of the VDSL error corrections from my ISP that can cause higher latencies.

Here we go

The IPTV VLAN will be on eth1 with VLAN ID 10 and will be terminated on a UniFi switch in the living room. If you need a guide, how to setup a VLAN on a UniFi switch and to assign it to a switch port, just click here.

Create the VLAN

1. Go to the dashboard of your EdgeRouter, click on Add Interface and select VLAN:

   

2. Go to section SERVICES and click Add DHCP server:

   

3. Stay in SERVICES, go to the tab DNS, Add Listen interface and choose the interface of your VLAN:

   

VLAN 10 is now ready to use, but it’s not isolated from the other networks. The EdgeRouter’s job is to route between networks. A device on VLAN 10 could access the LAN, your NAS for example.

Create network group

1. Go to FIREWALL/NAT, then to Firewall/NAT Groups and create a new network group:

   

2. Edit the new network group and add all networks except the VLAN:

   

A quick guide to firewall directions

Before you create the firewall rulesets, you should know and understand the firewall ruleset directions:

• IN: traffic entering the router from an interface
• OUT: traffic exiting the router to an interface
• LOCAL: traffic entering the router and destined to router itself (internal services, like DNS, DHCP, VPN etc.)

I will also provide a short explanation for each firewall ruleset and its direction.

If you’re having trouble to understand the directions, there is a very helpful diagram in the Ubiquiti forums.

Create firewall ruleset VLAN10_ISOLATION_IN

The following firewall ruleset blocks traffic into all networks of your network group, but will allow already established connections.

Direction IN means any traffic from eth1.10 to any other of your EdgeRouter’s interfaces.

1. Go to Firewall Policies and click Add Ruleset:

   

2. Edit the new ruleset and setup the interfaces:

   

3. Add a new firewall rule to allow established and related packets:

   

   

4. Add a new firewall rule to drop packets into network group LAN:

   

   

5. Your firewall ruleset should look like this:

   

Create firewall ruleset VLAN10_ISOLATION_LOCAL

This ruleset will block any traffic to your EdgeRouter’s services, with the exception of DNS and DHCP.

Direction LOCAL means any traffic from eth1.10 directly to your EdgeRouter and its services.

1. Create another firewall ruleset like VLAN10_ISOLATION_IN:

   

2. Edit the new ruleset and setup the interfaces:

   

3. Add a new firewall rule to allow DNS:

   

   

4. Add a new firewall rule to allow DHCP:

   

   

5. Your firewall ruleset should look like this:

   

Optional: assign network groups to custom NAT rules

If you’re using custom NAT rules, you have to add your new network group to the rules to exclude the VLAN. Firewall rules alone will not isolate any networks from custom NAT rules.

That’s it. VLAN 10 is now fully isolated from all other networks. The firewall will drop all packets from eth1.10 to the network group and my custom NAT rule will only work from networks of the group.

MikroTik ist ein Netzwerkausrüster aus Lettland. Wie Ubiquiti bieten sie professionelle Netzwerk-Hard- und Software zu bezahlbaren Preisen an. Man kann sogar Einzelteile wie Boards, Ports, Gehäuse usw. einzeln kaufen und sich damit seinen Traum-Router zusammenbauen.

Die Kontrahenten

Sie könnten zwar von außen nicht unterschiedlicher sein, ihre inneren Werte sind jedoch sehr vergleichbar. Beide bieten fünf Gigabit-Ports und können an Port 1 über 24 V Passive PoE mit Strom versorgt werden. Außerdem nutzen beide den gleichen SoC von MediaTek und damit die gleiche CPU: einen 880 MHz MIPS Dual Core (4 Threads). Preislich liegen sie mit ca. 55 - 60 Euro natürlich auch gleich auf.

Ubiquiti EdgeRouter X

Putzig, was? Der ER-X ist wirklich klein, aber davon sollte man sich nicht täuschen lassen. Er bietet fünf völlig frei konfigurierbare Gigabit-Ports. Einmal WAN, einmal LAN und drei Switch-Ports mit separatem Netz? Kein Problem. Zweimal WAN mit automatischem Fail Over? Klar. Reiner Switch-Betrieb? Und ob, auch wenn er alleine dafür zu schade ist.

Auf dem ER-X läuft eine Linux-Distribution namens EdgeOS, die auch auf allen weiteren EdgeMAX-Geräten von Ubiquiti eingesetzt wird. Auf Einschränkungen im Vergleich zu den größeren Brüdern verzichtet man dankenswerterweise.

EdgeOS bietet ein recht umfangreiches Web-Interface mit dem sich viele Aufgaben schnell und einfach erledigen lassen. Für die wichtigsten Standard-Anwendungsfälle stehen Assistenten (Wizards) bereit. Ein simples Setup für WAN mit vier LAN-Ports als Switch und PPPoE inkl. Firewall ist damit in einer Minute erledigt. IPv6 wird leider bisher vom Web-Interface kaum unterstützt, bis auf eine Option in den Wizards für ein Standard-Setup mit Firewall, das aber ohne weitere manuelle Konfiguration nicht funktioniert, kann es nur noch IPv6-Adressen für die Interfaces anzeigen.

Alles weitere inkl. der tiefgreifenderen Konfigurationsmöglichkeiten muss über das CLI erledigt werden. Klingt nun schlimmer als es ist. EdgeOS basiert auf Vyatta, einer Linux-Distribution speziell für Netzwerkgeräte. Vyatta hat ein übersichtliches, recht einfach zu erlernendes Interface. Änderungen werden nicht sofort aktiv, erst nachdem man den Befehl commit abgeschickt hat werden sie aktiv aber noch nicht gespeichert. Sollte man sich also z.B. mal bei einer Firewall-Änderung aussperren, reicht ein Neustart des ER-X und alles läuft wie zuvor. Um zu speichern wird der Befehl save genutzt.

Man muss also keine Angst vor dem CLI haben. Kaputt machen kann man nichts, sofern man nicht gleich jede Änderung speichert.

Zusätzlich bietet der EdgeRouter X via CLI zuschaltbare Hardware-Beschleunigung für NAT und IPsec (aktuell Beta). Lt. eines Mitarbeiters auf Reddit überlegt Ubiquiti derzeit außerdem Deep Packet Inspection (DPI) in Hardware zu unterstützen – da fehlt wohl noch ein passender Treiber. Damit wäre er fast auf dem Niveau des nächst größeren Bruders, dem EdgeRouter Lite (ca. 90 - 100 Euro).

MikroTik hEX

Zugegeben, das Gehäuse wirkt im Vergleich zum ER-X etwas billig, es stört aber auch nicht. Ich habe jedenfalls noch niemanden gesehen, der Router wegen ihres Gehäuse-Designs kauft. Die Metallhülle des ER-X mag Hitze besser ableiten, aber da beide Geräte nicht sonderlich heiß werden, spielt das eine untergeordnete Rolle.

Die Ports lassen sich genauso frei konfigurieren wie bei der Konkurrenz. Selbst Port Mirroring in Hardware ist möglich, was meines Wissens nach aktuell beim ER-X nur via Software geht.

Zusammen mit dem hEX kommt eine Lizenz für RouterOS, MikroTiks Gegenstück zu EdgeOS. Es kann allerdings auch separat lizenziert und auf x86-Hardware betrieben werden. Wer sich das Web-Interface (WebFig) vorab ansehen möchte, kann das hier tun.

Der hEX wird vorkonfiguriert geliefert: WAN liegt auf Port 1, die restlichen Ports sind dem Switch zugeordnet. Ein DHCP-Server, DNS-Forwarding usw. sind bereits eingerichtet. Assistenten für andere Konfigurationen gibt es aber nicht. Wenn man lieber selbst Hand anlegen möchte, besteht beim ersten Login die Möglichkeit einfach per Klick alle vordefinierten Einstellungen zurückzusetzen.

WebFig ist standardmäßig an LAN-Port 2 über die IP-Adresse 192.168.88.1 erreichbar. Alternativ bietet MikroTik mit WinBox ein Windows-Programm, das wie eine Art Wrapper für WebFig aussieht, sich aber durch Fenster-Unterstützung innerhalb der Software besser und schneller bedienen lässt. Für Mac-User gibt es WinBox inkl. Wine als fertiges Bundle – funktioniert bei mir bisher problemlos.

Im Gegensatz zum Web-Interface von EdgeOS kann WebFig alle Funktionen konfigurieren. Über einen Paket-Manager lassen sich außerdem weitere Möglichkeiten nachrüsten, u.A. IPv6, das als inaktives Paket mitgeliefert wird.

Die Oberfläche erschlägt einen auf den ersten Blick durch die vielen Optionen und ist etwas gewöhnungsbedürftig, wenn man vorher nur mit EdgeOS zu tun hatte. Nach ein paar Problemen komme ich aber mit WebFig ziemlich gut klar. Die grundsätzlichen Vorgänge unterscheiden sich ja nicht. Umgekehrt ist sicherlich auch EdgeOS für einen MikroTik-Nutzer erstmal sehr ungewohnt.

Das CLI von RouterOS ist ebenso logisch und einfach strukturiert wie in EdgeOS, auch wenn natürlich die Syntax anders aussieht. Änderungen sind im Gegensatz zu EdgeOS sofort aktiv und werden direkt gespeichert. Um Probleme zu verhindern, bietet RouterOS den Safe Mode für das CLI und WebFig. Darin gemachte Änderungen werden auch sofort umgesetzt, aber erst gespeichert, wenn man das entsprechende Kommando gibt. Im Zweifelsfall reicht ein Neustart und nichts ist passiert.

In Sachen Hardware-Beschleunigung zeigt sich der hEX knausriger als der ER-X, da aktuell nur IPsec unterstützt wird. Ob da weitere Planungen anstehen, konnte ich leider nicht in Erfahrung bringen. Bleibt die Frage, ob das überhaupt geht? Offiziell unterstützt der SoC beider Geräte nur Hardware-IPsec. Es ist also wahrscheinlich, dass der ER-X zusätzliche Hardware für NAT und DPI besitzt.

Benchmark

Mein Benchmark-Szenario basiert auf iPerf3 mit einer, zehn und 100 gleichzeitigen TCP-Verbindungen und ist damit eher theoretischer Natur. Einen ausgefeilten Test mit zigtausenden HTTP-Downloads in verschiedenen Größen wie Ars Technica kann ich leider derzeit nicht bieten. Vielleicht sollte ich “routerperf” entwickeln. :D

Der Benchmark fand zwischen meinem PC und dem MacBook Pro statt. Der Windows-Rechner verfügt über eine Intel-LAN-Schnittstelle, während der Mac über einen Thunderbolt-Ethernet-Adapter mit dem LAN verbunden war. Sind also beides keine Krücken.

Als Referenzwerte dienen Durchläufe an beiden Rechnern, die über einen Cisco SoHo-Switch verbunden waren.

In allen anderen Szenarien war der Mac als Server am WAN-Port des jeweiligen Routers und der PC am entsprechenden LAN-Port in einem separaten Netz. Das NAT findet via Masquerading in IPTables statt.

Ergebnis

Das Hardware-NAT des ER-X schlägt richtig ein, während die Leistung ohne Hardware-Unterstützung ungewöhnlich inkonsistent ist. Das volle Potenzial wird erst mit mehreren Verbindungen wirklich genutzt. Der hEX dagegen skaliert in dieser Situation wie man es erwartet.

Da beide die gleiche CPU verwenden ist das Ergebnis bei nur einer Verbindung umso erstaunlicher. Es wäre durchaus möglich, dass es sich hier um einen Bug handelt. Ein ähnliches Problem gab es im Sommer mit dem UniFi Security Gateway, das auf der Hardware des EdgeRouter Lite basiert.

In der Realität dürfte die Differenz zwischen dem hEX und ER-X ein Stück kleiner ausfallen, denn nicht jede Verbindung läuft über TCP und die Paketgröße hat hier auch ein Stück mitzureden.

Fazit

Ich bin mit beiden Geräten sehr zufrieden. Für knapp 60 Euro bekommt man in beiden Fällen ein überzeugendes Produkt, das auch gehobenen Ansprüchen im Heimnetz mehr als gerecht wird.

Nur wer sich glücklich schätzen kann eine Gigabit-Internetverbindung zu besitzen, dürfte mit dem ER-X die schlauere Wahl treffen – auch wenn in der Realität der Unterschied geringer ausfallen wird. Ganz nebenbei: der hEX hat natürlich auch größere Brüder.

Letztendlich dürfte es für die meisten von uns eine reine Geschmacksfrage sein. Ich werde beide im Wechsel einsetzen und die Entwicklung beobachten. Da beide praktischerweise 24 V Passive PoE unterstützen, lassen sie sich sehr einfach tauschen. Kabel bei einem abstecken, beim anderen anstecken – fertig.

Wie im Guide zum Vigor 130 bzw. EdgeRouter X schon angedeutet, bin ich von meiner bisherigen Vodafone/Kabel Deutschland-Verbindung zur Telekom mit VDSL 100 gewechselt.

Damit halbiert sich mein Downstream, da Vodafone hier 200 Mbit/s anbietet und VDSL mit Vectoring bekanntlich nur max. 100 Mbit/s hergibt. Als Trostpflaster gibt’s aber immerhin 15 Mbit/s mehr Upstream.

Für die Entscheidung war das aber alles zweitrangig. In den letzten Monaten gab es immer mehr Probleme mit der Kabel-Verbindung, sei’s durch merkwürdiges Verhalten der Fritzbox 6490, zunehmender Last im Kabelsegment oder mit Routing/Peering der Kabel-Infrastruktur.

Gerade letzteres habe ich eigentlich erst richtig gemerkt, als der Vergleich zur Telekom möglich war.

Die Symptome:

• Als der Anschluss auf 200 Mbit/s geschaltet wurde, waren stabile Downloadraten von 23 - 25 MB/s in Steam die Regel. Inzwischen sind sie nur noch die Ausnahme und nur außerhalb der Hauptlastzeiten möglich. Gilt nicht nur für Steam, generell für alle Downloads.

• Wenn Steam die Bandbreite nicht auslasten kann, öffnet es zusätzliche TCP-Verbindungen. Können schon mal an die 50 - 70 Stück sein. Ab dem Punkt steigt die Fritzbox langsam aus, weil sie mit NAT nicht mehr hinterher kommt. Ping-Zeiten steigen deutlich an, Surfen nebenbei macht keinen Spaß mehr … der EdgeRouter X lächelt dank Hardware-NAT nur müde.

• Teils massive Probleme mit Ping-Zeiten und Packet Loss in Battlefield 1, manchmal völlig unspielbar. Lag für mich immer an EA, bis ich ein paar Runden via VDSL gespielt habe …

• Apple Music war richtig lahm, Streaming von Filmen aus dem iTunes Store war auf PC und Mac ein Graus bis unbrauchbar, Downloads im App Store waren mal pfeilschnell, dann wieder unglaublich langsam usw. – hatte ich alles auf Apple geschoben, aber wie schon bei Battlefield 1 lag’s an Vodafone. Gleiches gilt auch für teils extrem langsame Downloads aus dem PlayStation Network.

• Ich schaue gerne die Reviews von SF Debris, es war aber zunehmend schwer sich die Videos überhaupt anzusehen. Die Seite lädt im Vodafone-Netz extrem lahm und die Videos brauchen gefühlte Ewigkeit, bis mal ein bisschen matschiges 240p zu sehen ist. Über die Telekom starten die Videos sofort – in HD.

• Vermehrt Probleme mit YouTube, manchmal so schlimm, dass selbst Videos in SD nicht mehr flüssig liefen.

• Starke Schwankungen bei den Ping-Zeiten, auch ohne Last.

Ein Vergleich:

Vodafone

~ ❯❯❯ ping -c 100 google.de
PING google.de (172.217.21.195): 56 data bytes
64 bytes from 172.217.21.195: icmp_seq=0 ttl=53 time=21.271 ms
...
64 bytes from 172.217.21.195: icmp_seq=99 ttl=53 time=28.892 ms

--- google.de ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 19.163/30.845/111.265/15.526 ms

Telekom

~ ❯❯❯ ping -c 100 google.de
PING google.de (172.217.21.163): 56 data bytes
64 bytes from 172.217.21.163: icmp_seq=0 ttl=57 time=21.731 ms
...
64 bytes from 172.217.21.163: icmp_seq=99 ttl=57 time=21.594 ms

--- google.de ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.482/21.760/22.146/0.156 ms

Mit IPv6 schaut’s für Vodafone sogar noch etwas schlechter aus.

Diese Ping-Messungen habe ich an einem frühen Nachmittag ausgeführt, also sollte sich die Last im Segment bzw. Netz doch in Grenzen gehalten haben.

Meine Diagnose:

1. Die Fritzbox 6490 mag für Normalnutzer okay sein, aber nicht für mich. Den Bridge-Modus lässt Vodafone leider durch Einschnitte in FritzOS nicht mehr zu und ein reines Kabelmodem für EURODOCSIS 3.0 zu finden ist ein Ding der Unmöglichkeit.

2. Mein zuständiges Kabel-Segment wird zunehmend überlastet. Früher war ich hier der einzige weit und breit mit einer Internet-Verbindung über Kabel. Da es zumindest bis Dezember 2016 auch keine Alternativen für anständige Bandbreiten gab, geht in dem Segment nun zunehmend die Post ab.

3. Das interne Routing von Vodafone geht z.T. über sehr viele Hops, sowohl mit IPv4 als auch IPv6. Das ist grundsätzlich nicht weiter schlimm, aber es erhöht die Anfälligkeit für Fehler und Packet Loss.

4. Der vermutlich schwerwiegendste Punkt: das Peering in andere Netze ist z.T. eine Katastrophe. Alle og. Probleme mit den Servern von Apple, EA, Google/YouTube, Sony usw. liegen daran. Über den Punkt kann ich nicht mehr hinwegsehen. Bandbreiten und Ping-Schwankungen sind eine Sache, aber wenn ich für mich wichtige Dienste nicht mehr richtig nutzen kann, ist der Ofen wirklich aus.

Kabel Deutschland bzw. jetzt Vodafone hatte ich fast acht Jahre ohne größere Probleme, aber da ich auch beruflich auf die Internetverbindung angewiesen bin, muss ich an der Stelle den Stecker ziehen.

Vodafone wird mit Sicherheit an den Problemen arbeiten – dauert halt. Eine Segment-Aufteilung kann sich über mehrere Monate bis ein Jahr ziehen. Internes Routing lässt sich auch nicht von heute auf morgen verbessern, ebenso das Peering.

Man hat es hier mit den Angeboten für 200 Mbit/s bzw. in vielen Haushalten auch schon 400 Mbit/s wohl übertrieben ohne die Infrastruktur dahinter auszubauen.

Zumindest im Mobilfunk-Bereich hat Vodafone in den letzten Jahren einiges deutlich verbessert. Schaffen sie im Kabelnetz hoffentlich auch noch. Konkurrenz belebt das Geschäft.

Solange bin ich aber wieder Telekom-Kunde. VDSL mit Vectoring ist nur eine Übergangslösung bis FTTH im großen Stil kommt, aber ich bin nicht mehr auf ein Shared Medium wie Kabel angewiesen und ab dem MSAN hängt man im BNG, dem neuen, verdammt flotten Backbone-Netz der Telekom.

Außerdem kann ich meine Wunsch-Hardware nutzen, auch wenn es nicht viele Vectoring-taugliche DSL-Modems da draußen gibt.

Für die meisten tut’s der übliche Speedport, der mir zumindest in seinem Verhalten unter Last besser gefällt als die Fritzbox. Der Vergleich hinkt natürlich etwas, da die Fritte deutlich mehr kann.

In Sachen WLAN sind sie beide ziemlich meh, besonders im Vergleich zu meinen früheren AirPorts oder jetzt UniFi Access Points – ist natürlich wieder unfair. Gibt weit teurere Consumer-Geräte, die viel schlimmer sind, siehe Ars Technica.

Nachtrag vom 13.1.2017:

Nach diesem Bericht von Golem ist mir dann auch klar, warum ich die Probleme mit Vodafone hatte. Traffic Shaping verzögert oder verwirft Pakete einfach, je nach Konfiguration bzw. Last. Das erklärt die schwankenden Ping-Zeiten, den Packet Loss in Spielen, die inkonsistenten Download-Raten usw.

Es ist zwar logisch, dass Vodafone QoS einsetzt, damit das Netz nicht komplett zum Teufel geht. Man kann aber nicht einfach den Backbone-Ausbau verschlafen oder gar sogar absichtlich verzögern, während man den Kabel-Kunden immer mehr Bandbreite anbietet und die DSL-Kunden ins Kabelnetz lockt bzw. mancherorts wohl sogar drängt.

Bisheriges Netzwerk

Die Internet-Verbindung wird über die Fritzbox 6490 aufgebaut, die sonst außer VoIP nichts tut. An der Fritte hängt ein Ubiquiti EdgeRouter X, der dann das eigentliche Netzwerk aufbaut. Das Netz verteilt sich vom Wohnzimmer aus über drei SoHo-Switches von Cisco und zwei Ubiquiti UniFi AC Lite Access Points an die jeweiligen Endgeräte.

Diese Konstellation führt zu doppeltem NAT. Hässlich, aber auch nicht weiter tragisch. Der EdgeRouter X kann Hardware-NAT und kostet höchstens 400 - 500 µs. Ein geringer Aufpreis für wesentlich mehr Kontrolle über mein Netzwerk. Nur die IPv6-Konfiguration zwischen Fritzbox und EdgeRouter wollte einfach nicht klappen – diese unendliche Geschichte will ich hier aber nicht weiter ausbreiten, hat sich eh erledigt.

Neues Netzwerk

Mit VDSL sieht die Sache natürlich etwas anders aus. Der Telefonanschluss ist im Flur, also mussten erstmal Kabel gelegt werden … bei dem Thema sind Mietwohnungen dezent scheiße. Von Kabelkanälen hatte zum Bauzeitpunkt kein Mensch was gehört.

Zum Testen der Verbindung kam erstmal ein Speedport 724 V von der Telekom zum Einsatz. Klingt doof? So übel ist die Kiste gar nicht, allerdings ging’s auch nur mit doppeltem NAT, weil die Speedports leider keinen Modem-Betrieb mehr können und generell ist mein Nutzungsprofil doch etwas anspruchsvoller. Daher habe ich einen Vigor 130 von DrayTek gekauft und als Vectoring-taugliches VDSL-Modem im Einsatz. Der EdgeRouter wird nun einfach per PPPoE über den Vigor versorgt.

Konfiguration

Kommen wir zum Herzstück des Posts, denn die Konfiguration ist zwar grundsätzlich einfach, hat aber auch ein paar Tücken – insbesondere wenn IPv6 im Spiel ist.

DrayTek Vigor 130

Der gute Vigor wird bereits als Modem inkl. VLAN-Tagging für die Telekom vorkonfiguriert geliefert. Man muss eigentlich nur die neueste Firmware einspielen und das war’s.

Falls der Vigor wider Erwarten doch nicht als Modem vorkonfiguriert geliefert wird, findet man bei iDomiX Hilfe (Text und Video).

Ubiquiti EdgeRouter

Ausgangsbasis ist der EdgeRouter X mit EdgeOS 1.9.1. Es sollte grundsätzlich genauso mit einem größeren EdgeRouter und neueren EdgeOS-Versionen funktionieren.

Netzwerk-Setup

Ich gehe hierbei davon aus, dass jemand, der diesen Post liest zumindest Grundkenntnisse im Umgang mit einem EdgeRouter hat, also Default-IP, Default-Login-Daten, Web-Interface-Zugang usw.

Für die grundsätzliche Konfiguration bietet Ubiquiti zum Glück entsprechende Assistenten (Wizards) an, die den ganzen Vorgang vereinfachen und mir auch ersparen hier monströse Listings mit Firewall-Regeln zu posten.

Der Wizard “Basic Setup” macht grundsätzlich alles, was man braucht:

Als WAN-Port habe ich mich für eth0 entschieden. Die Einwahl erfolgt über PPPoE mit den entsprechenden Login-Daten der Telekom. VLAN-Tagging ist hier nicht nötig, das übernimmt der Vigor bereits (VLAN 7). Die Default-Firewall sollte auf jeden Fall aktiviert werden, genauso wie DHCPv6 PD. Die Prefix Length ist mit /56 bereits korrekt voreingestellt und auch hier gilt, dass die Firewall an sein sollte.

Die Option “Only use one LAN” wird deaktiviert. Anschließend wird das Netz für eth1 konfiguriert. Ich nutze hier ein privates Klasse A-Netz. Für die Switching-Ports eth2, eth3 und eth4 gibt es ein separates Klasse A-Netz.

Unter “User Setup” verwende ich meine bestehenden User weiter. Sollte der EdgeRouter bisher nie konfiguriert worden sein, empfehle ich aber dringend einen neuen Nutzer mit eigenem Passwort anzulegen. Ein Router sollte nie über seine Standard-Zugangsdaten zugänglich sein.

Nach dem Speichern startet sich der EdgeRouter neu und ist anschließend über die IP 10.0.0.1 an eth1 wieder erreichbar. Im Dashboard sollte nun relativ bald unter pppoe0 die öffentliche IPv4-Adresse sichtbar sein und damit auch die Internet-Verbindung bestehen.

Grundsätzlich ist’s damit getan, wenn einem IPv4 ausreicht.

Für mein privates Netzwerk nehme ich anschließend noch ein paar Einstellungen an der Firewall (Port-Weiterleitungen) und am DHCP-Server vor. Wenn man zufrieden ist, sollte man ein Backup der Konfiguration machen. Das geht unter “System” -> “Back Up Config”.

IPv6

Leider unterstützt das Web-Interface bisher kaum IPv6, daher muss man ein paar Einstellungen via CLI vornehmen.

Unter macOS und Linux ist das einfach im Terminal im SSH möglich. Unter Windows bleibt einem aktuell nur das Linux Subsystem von Windows 10 oder ein SSH-Client wie PuTTY.

Beispiel:

ssh user@10.0.0.1

Anschließend wird nach dem Passwort des Users gefragt.

Bei mir sieht die Sache so aus (Login über SSH-Alias mit Key):

~ ❯❯❯ ssh edge                                                                                                                              
Welcome to EdgeOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement (available in the Web UI at, by default,
http://192.168.1.1) and agree to be bound by its terms.

Linux 3.10.14-UBNT #1 SMP Mon Nov 14 03:56:39 PST 2016 mips
Welcome to EdgeOS
webcodr@ubnt:~$

Damit ist nun das CLI des EdgeRouters offen und man kann loslegen.

Folgendes muss eingegeben werden:

configure

set interfaces ethernet eth1 ipv6 dup-addr-detect-transmits 1
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 host-address '::dead:beef'
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 no-dns
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 prefix-id 42
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 service slaac
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 prefix-length 56
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd prefix-only
set interfaces ethernet eth0 pppoe 0 dhcpv6-pd rapid-commit enable
set interfaces ethernet eth0 pppoe 0 ipv6 address autoconf
set interfaces ethernet eth0 pppoe 0 ipv6 dup-addr-detect-transmits 1
set interfaces ethernet eth0 pppoe 0 ipv6 enable
set system offload hwnat enable
commit
save

Erläuterungen:

• configure startet das Konfiguration-System von EdgeOS/Vyatta
• set interfaces ethernet eth1 ipv6 dup-addr-detect-transmits 1 legt die Anzahl fest, wie oft versucht wird doppelte IPv6-Adressen herauszufinden
• set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 host-address '::dead:beef' legt die Host-Adresse nach dem Adress-Prefix der Telekom fest. Ich finde ::dead:beef ziemlich witzig, aber hier kann sich jeder selbst austoben, solange es im Hexadezimal-Bereich liegt.
• set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 prefix-id 42 legt die Prefix-ID fest, die zusätzlich in die Adresse aufgenommen wird. Was außer 42 sollte es sonst sein? :D
• set interfaces ethernet eth0 pppoe 0 dhcpv6-pd pd 0 interface eth1 service slaac SLAAC steht für Stateless Address Autoconfiguration – damit erzeugt der Port seine IP-Adresse anhand des Prefixes selbst
• set interfaces ethernet eth0 pppoe 0 ipv6 address autoconf aktiviert die automatische IPv6-Adress-Konfiguration für das PPPoE-Interface
• set interfaces ethernet eth0 pppoe 0 ipv6 enable aktiviert dann letztendlich IPv6
• set system offload hwnat enable aktiviert Hardware-NAT für IPv4
• commit wendet die neue Konfiguration an
• save speichert die neue Konfiguration ab

Nach commit starten sich die betroffenen Interfaces neu und es erfolgt eine neue Einwahl über PPPoE. Anschließend befinden sich im Dashboard unter pppoe0 die IPv4-Adresse sowie die entsprechenden globalen und lokalen IPv6-Adressen.

Alternativ lässt sich das via CLI anschauen (außerhalb von configure):

webcodr@ubnt:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description
---------    ----------                        ---  -----------
...
eth1         10.0.0.1/24                       u/u  Local 2
             2003:xxxx:xxxx:xx42::dead:beef/64
...

Alle Geräte im Netzwerk sollten nun eine oder mehrere IPv6-Adressen besitzen und via IPv6 ins Internet kommen. Das lässt sich sehr einfach über die Seite test-ipv6.com herausfinden.

Zugang zum Vigor-Web-Interface

Da der Vigor auf der IP-Adresse 192.168.1.1 rumhängt, kommen wir nun leider erstmal nicht an sein Web-Interface ran. Das lässt sich aber recht einfach in EdgeOS ändern:

Dazu muss eth0 (über diesen Port hängt der EdgeRouter ja am Vigor 130) eine IP-Adresse aus dem Netz des Vigors zugewiesen werden. Ich verwende hier 192.168.1.2/24.

Das alleine reicht noch nicht, da die NAT bisher die Verbindung in das andere Netz nicht kennt. Unter “Firewall/NAT” -> “NAT” -> “Add Source NAT Rule”, trägt man daher folgendes ein und speichert.

Anschließend sollte der Zugriff über die IP-Adresse 192.168.1.1 auf den Vigor sofort funktionieren.

So, das war’s dann eigentlich schon. Ich hoffe, diese kleine Anleitung konnte dem ein oder anderen etwas weiterhelfen.

Da nicht alles davon auf meinem Mist gewachsen ist, möchte ich mich an dieser Stelle noch beim Autor des Blogs TauSys bedanken. Falls jemand in og. Konfiguration noch Entertain miteinbeziehen möchte, sei ihm dieser Post wärmstens empfohlen.