Turris Omnia 2020 mit OpenWRT am Telekom VDSL-Anschluss betreiben

Seit Ende letzten Jahres bin ich glücklicher Besitzer eines Turris Omnia (ver. 2020) Routers. Das Gerät wurde von der tschechischen CZ.nic entwickelt und unterstützt nicht nur das freie Linux-Betriebssystem OpenWrt, sondern ist selbst auch quelloffene Hardware. Das macht den Turris Omnia ideal für meine Basteleien.

In diesem Beitrag will ich erklären, wie ich den Router an meinen Telekom VDSL2-Anschluss angebunden habe.

Die AVM FritzBox als externes Modem nutzen

Während einige Nutzer den Turris Omnia (TO) hinter einem bestehenden DSL-Router betreiben, habe ich mich dazu entschieden, den Open Source Router so nah wie möglich direkt an meinem Anschluss zu betreiben, um Ärger mit Doppel-NAT und anderen Hindernissen aus dem Weg zu gehen. Erst so entfaltet der Omnia sein volles Potential. “Direkt am Anschluss” soll hier heißen: Die öffentliche IPv4-Adresse soll am Turris Omnia anliegen und auch das öffentliche IPv6-Netz soll hier geroutet werden.

Es gibt verschiedene Möglichkeiten, das Gerät ohne vorgeschaltetes NAT am Anschluss zu betreiben.

  1. Über ein VDSL-SFP-Modul (z.B. ALLNET ALL4781V)
  2. Über ein externes VDSL-Modem mit Bridge-Funktion (z.B. DrayTek Vigor 166)

Der Omnia selbst verfügt über kein DSL-Modem. Da entsprechende SFP-Module ziemlich teuer sind und ich mir auch ein weiteres DSL-Modem als “Bridge” zunächst sparen wollte, habe ich meine FritzBox kurzerhand zu einem reinen DSL-Modem umfunktioniert - auch wenn der Hersteller das nicht offiziell vorsieht. Die FritzBox übernimmt somit nur noch die Übermittlung der Ethernet-Frames über die unteren Protokollschichten des DSL und natürlich die physikalische Übersetzung in entsprechende Signale.

FritzBox Einstellungen in der Expertenansicht. Besonderheit: VLAN-Tagging (Tag 7) wird hier gesetzt, um es nicht auf dem WAN-Port des TO berücksichtigen zu müssen.

Die FritzBox wird versuchen, eine Internetverbindung ohne Zugangsdaten herzustellen, was selbstverständlich scheitern wird. Daher die Info-LED an der FritzBox rot leuchten und im Systemlog Fehler erscheinen. Leider kenne ich keine Möglichkeit, die LED abzuschalten - auch die “LEDs abschalten” Funktion nützt in diesem Fall nichts.

Wen das stört, der ist mit einem reinen DSL-Modem mit Bridge-Funktion wahrscheinlich besser beraten.

Eine Internetverbindung über die FritzBox herstellen

Der WAN-Port des Turris Omnia wird physisch mit einem der LAN-Ports der FritzBox verbunden. Alles, was sich auf den höheren IP-Layern abspielt, läuft nicht mehr auf der FritzBox, sondern auf dem Turris Omnia. Dazu wird via PPPoE eine Tunnelverbindung zur Telekom hergestellt.

Eine PPPoE-Verbindung herstellen

In der Netzwerkkonfiguration /etc/config/network habe ich mein wan und wan6 interface wie folgt konfiguriert:

config interface 'wan'
    option ifname 'eth2'
    option proto 'pppoe'
    option ipv6 'auto'
    option username '<zugangsnummer>@t-online.de'
    option password '<persönliches Kennwort>'

config interface 'wan6'
    option ifname '@wan'
    option proto 'dhcpv6'
    option reqprefix 'auto'
    option reqaddress 'try'

<zugangsnummer> und <persönliches Kennwort> müssen selbstverständlich durch die eigenen Telekom-Zugangsdaten ersetzt werden.

Über option proto 'dhcpv6' und die beiden darauf folgenden Zeilen wird OpenWrt angewiesen, via DHCPv6 eine öffentliche IPv6-Adresse und ein öffentliches /56 IPv6-Netz vom Provider zu beziehen.

Firewall-Regeln für DHCPv6 und ICMP6

Damit der Telekom-Router am anderen Ende regelmäßig Updates zu den von ihm entliehenen IPv4-Adressen, IPv6-Adressen und -Netzen senden kann, werden in der Firewall noch ein paar Ausnahmen für Verbindungen gemacht.

Die folgenden Regeln stammen aus der Default-Konfiguration des Turris Omnia - sie sollten auf eurem System also schon vorhanden sein. Bei mir war das nicht der Fall, sodass ich in einige Problem gelaufen bin, die nicht aufgetreten wären, wenn ich die Firewall in der Vergangenheit einfach so gelassen hätte, wie sie ausgeliefert wurde … ;-)

Hier also der Vollständigkeit halber nochmal alle wichtigen Regeln zum WAN-Interface:

/etc/config/firewall:

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
    option name		Allow-DHCP-Renew
    option src		wan
    option proto        udp
    option dest_port	68
    option target	ACCEPT
    option family	ipv4

# Allow IPv4 ping
config rule
    option name		Allow-Ping
    option src		wan
    option proto	icmp
    option icmp_type	echo-request
    option family	ipv4
    option target	ACCEPT

config rule
    option name		Allow-IGMP
    option src		wan
    option proto	igmp
    option family	ipv4
    option target	ACCEPT

# Allow DHCPv6 replies
# see https://dev.openwrt.org/ticket/10381
config rule
    option name		Allow-DHCPv6
    option src		wan
    option proto	udp
    option src_ip	fe80::/10
    option src_port	547
    option dest_ip	fe80::/10
    option dest_port	546
    option family	ipv6
    option target	ACCEPT

config rule
    option name		Allow-MLD
    option src		wan
    option proto	icmp
    option src_ip	fe80::/10
    list icmp_type	'130/0'
    list icmp_type	'131/0'
    list icmp_type	'132/0'
    list icmp_type	'143/0'
    option family	ipv6
    option target	ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
    option name		Allow-ICMPv6-Input
    option src		wan
    option proto	icmp
    list icmp_type	echo-request
    list icmp_type	echo-reply
    list icmp_type	destination-unreachable
    list icmp_type	packet-too-big
    list icmp_type	time-exceeded
    list icmp_type	bad-header
    list icmp_type	unknown-header-type
    list icmp_type	router-solicitation
    list icmp_type	neighbour-solicitation
    list icmp_type	router-advertisement
    list icmp_type	neighbour-advertisement
    option limit	1000/sec
    option family	ipv6
    option target	ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
    option name		Allow-ICMPv6-Forward
    option src		wan
    option dest		*
    option proto	icmp
    list icmp_type	echo-request
    list icmp_type	echo-reply
    list icmp_type	destination-unreachable
    list icmp_type	packet-too-big
    list icmp_type	time-exceeded
    list icmp_type	bad-header
    list icmp_type	unknown-header-type
    option limit	1000/sec
    option family	ipv6
    option target	ACCEPT

Konfiguration der lokalen Netzwerke

Das /56 Netz wird nun in kleinere Teilnetze (/64) aufgeteilt und auf die internen Interfaces verteilt. In meinem Fall auf das lan Netzwerk und das SRV Netzwerk und seine Interfaces:

config interface 'lan'
    option type 	'bridge'
    option proto 	'static'
    option ipaddr 	'192.168.1.1'
    option netmask 	'255.255.255.0'
    option ip6ifaceid 	'::1'
    option ip6assign 	'64'
    option ip6hint	'01'
    [...]

config interface 'SRV'
    option type 	'bridge'
    option proto 	'static'
    list ipaddr 	'192.168.3.1/24'
    option netmask 	'255.255.255.0'
    option ip6ifaceid 	'::1'
    option ip6assign	 '64'
    option ip6hint	 '03'
    [...]

Dabei mache ich mir die “IPv6 hinting” Funktionalität zunutze, denn standardmäßig würfelt OpenWrt das letzte Oktett der beiden /64 Netze aus. Ich habe aber eine konkrete Vorstellung, mit welchen Hex-Ziffern meine Netze enden sollen, und weise OpenWrt an, sich nach der Benennung der entsprechenden IPv4-Netze zu richten.

Mein lan Netz soll dementsprechend auf 01 enden und mein SRV Netz auf 03.

2003:c6:4f12:20::/56		(Vom Anbieter delegiertes Netz)
2003:c6:4f12:2001::1/64 	=> 01 als letztes Oktett des /64 Netzes für br-lan
2003:c6:4f12:2003::1/64 	=> 03 als letztes Oktett des /64 Netzes für br-SRV

Die entsprechenden Einstellungen sind in den Interfacekonfigurationen hinterlegt (ip6hint).

Einstellungen aktivieren

Neue Einstellungen einchecken:

uci commit network
uci commit firewall

Und Services neu starten:

service firewall restart
service network restart

Nach dem Anwenden der Einstellungen sollte sich der TO nun bei der Telekom authentifizieren, nach einigen Momenten IP-Adressen bekommen und den Clients in den Hausnetzwerken die jeweiligen /64 Netze anbieten. Die Geräte generieren sich daraufhin selbst IPv6-Adressen und sind dann in der Lage, via IPv6 und IPv4 ins Internet zu kommunizieren.

(für IPv4 ist zwichen dem WAN-Interface und den internen Interfaces standardmäßig ein NAT eingerichtet. Auf IPv4 wurde in diesem Beitrag nicht weiter eingegangen, weil es in den meisten Fällen bereits konfiguriert ist und keine zusätzlichen Schritte notwendig sind.)

Noch ein Hinweis zum Schluss: Sentinel-Minipot

Das sentinel-minipot Paket stellt auf dem Turris Omnia (falls gewünscht) einen sog. Honeypot dar (Siehe: Sentinel). Also einen Server, auf dem HTTP, FTP, Mail- und Telnet Dienste laufen, und der potentielle Angreifer verraten soll. Ich empfehle, den Dienst (falls auf eurem Turris aktiviert) zu deaktivieren, weil sonst das Telekom-Monitoring Alarm schlägt:

Sehr geehrter Herr Leister,

zu Ihrem Internetzugang haben wir Hinweise auf Sicherheitslücken oder Konfigurationsfehler erhalten, die einen Angriff auf Ihr System und/oder einen Missbrauch Ihres Systems für Angriffe auf Dritte ermöglichen. Ersteres gefährdet gegebenenfalls die Integrität und Authentizität Ihrer Daten.

Die folgende IP-Adresse war Ihrem Anschluss an dem genannten Zeitpunkt zugeordnet: IP-Adresse: 80.xxx.xxx.xxx
Zeitpunkt: 12.02.2021 14:03:07 MEZ
Offener Dienst: telnet (23) \

Weitere Angaben: banner: Username:

Wir empfehlen Ihnen, Ihren Router / Endgeräte / Netzwerkgeräte so zu konfigurieren, dass nicht relevante Ports oder Dienste geschlossen sind. Weiterhin prüfen Sie bitte, ob eine neuere Firmwareversion vorhanden ist. Diese sollten Sie gegebenenfalls einspielen.

Auch alle anderen Security-Checks, die von extern auf Netzwerksicherheit prüfen, schlagen völlig berechtigt Alarm, wie z.B. der C’t Netzwerkcheck: https://www.heise.de/security/dienste/Netzwerkcheck-2114.html

Deaktivieren lässt sich der Honeypot einfach über das Turris Foris Webinterface, oder auf der Kommandozeile via

service sentinel-minipot stop
service sentinel-minipot disable

Danach sollte Ruhe sein.

Hilfreiche Links: