[{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/","section":"CubelaPetar","summary":"","title":"CubelaPetar","type":"page"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/ds-lite/","section":"Tags","summary":"","title":"Ds-Lite","type":"tags"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/series/home-network-with-ipv6/","section":"Series","summary":"","title":"Home Network With IPv6","type":"series"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/ipv6/","section":"Tags","summary":"","title":"Ipv6","type":"tags"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/categories/network/","section":"Categories","summary":"","title":"Network","type":"categories"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/opnsense/","section":"Tags","summary":"","title":"Opnsense","type":"tags"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/categories/tutorial/","section":"Categories","summary":"","title":"Tutorial","type":"categories"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/vpn/","section":"Tags","summary":"","title":"Vpn","type":"tags"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/vps/","section":"Tags","summary":"","title":"Vps","type":"tags"},{"content":" Einleitung # Ich schreibe das gerade in einem Zug nach Zürich, im WLAN des Zuges — einem reinen IPv4-Netz. Und trotzdem erreiche ich alle meine Heimdienste per VPN, obwohl mein Heimnetzwerk hinter einer DS-Lite-Verbindung steckt und keine öffentliche IPv4 hat. Wie man OPNsense damit einrichtet, beschreibe ich in einem anderen Artikel.\nDie Lösung: ein VPS mit Dual-Stack als WireGuard-Hub. Mein Heimrouter verbindet sich über IPv6 mit dem VPS, ich verbinde mich von überall über die öffentliche IPv4 des VPS. Gebraucht habe ich das hauptsächlich für die Arbeit — bei uns im Büro gibt es nur IPv4, und ich wollte Zugriff auf meinen selbst gehosteten LLM-Server zu Hause. Ich habe das Problem mit Claude besprochen, der einen Site-to-Site-WireGuard-Tunnel zwischen Heimnetz und VPS über IPv6 vorschlug — Road Warriors verbinden sich dann über IPv4 mit dem VPS.\nÜberblick # Das Ergebnis: Ich erreiche jede Heimadresse aus einem IPv4-only-Netz — auch VLANs, die nur IPv6 haben. Es läuft seit der Einrichtung stabil.\nDer VPS ist der Hub:\n[Heimnetz 10.56.0.0/20 + fde4:ed21:b2c0:5600::/56] [Road Warrior] | | [OPNsense Firewall] WireGuard Client WireGuard Peer 10.0.0.3/24 10.0.0.2/24 fde4:ed21:b2c0:56dd::3/64 fde4:ed21:b2c0:56dd::2/64 | | | └──── IPv6-Tunnel ──────[VPS]────── IPv4-Tunnel ───┘ 10.0.0.1/24 fde4:ed21:b2c0:56dd::1/64 WireGuard Hub Netzwerkplan # Rolle Gerät WireGuard IPv4 WireGuard IPv6 (ULA) Öffentlicher Endpunkt Hub VPS 10.0.0.1/24 fde4:ed21:b2c0:56dd::1/64 VPS_PUBLIC_IPv4 (statisch) / VPS_PUBLIC_IPv6 (statisch) Heimgateway OPNsense 10.0.0.2/24 fde4:ed21:b2c0:56dd::2/64 vpn.petarcubela.de (dynamisches IPv6 via DDNS) Road Warrior Laptop/PC 10.0.0.3/24 fde4:ed21:b2c0:56dd::3/64 CLIENT_PUBLIC_IPv4 (IPv4) Heimnetz IPv4-Subnetz: 10.56.0.0/20 (umfasst alle Heim-VLANs) Heimnetz IPv6-ULA-Block: fde4:ed21:b2c0:5600::/56 (umfasst alle Heim-VLANs) WireGuard-Tunnel IPv4-Subnetz: 10.0.0.0/24 WireGuard-Tunnel IPv6-Subnetz: fde4:ed21:b2c0:56dd::/64 WireGuard-Port: 51822/udp Teil 1 — VPS-Einrichtung # Alle folgenden Befehle werden als root-Benutzer ausgeführt. 1.1 Schlüssel generieren # Das Schlüsselpaar mit wg generieren und im Standard-WireGuard-Verzeichnis ablegen. Der private Schlüssel braucht eingeschränkte Berechtigungen.\nwg genkey | tee /etc/wireguard/vps_private.key | wg pubkey \u0026gt; /etc/wireguard/vps_public.key chmod 600 /etc/wireguard/vps_private.key 1.2 IP-Weiterleitung aktivieren # Da der VPS Pakete zwischen dem Tunnel und dem Internet weiterleiten muss, IP-Weiterleitung aktivieren:\ncat \u0026gt;\u0026gt; /etc/sysctl.conf \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; net.ipv4.ip_forward=1 net.ipv6.conf.all.forwarding=1 EOF sysctl -p 1.3 WireGuard-Konfiguration /etc/wireguard/wg0.conf # Die PostUp-Hooks werden nach dem Hochfahren des Interfaces ausgeführt und erledigen zwei Dinge: Sie öffnen die Kernel-Firewall für weitergeleiteten Traffic (FORWARD-Regeln) und aktivieren NAT für ausgehenden IPv4-Traffic über das physische Interface (MASQUERADE auf eth0). Die PreDown-Hooks machen dies vor dem Herunterfahren des Interfaces sauber rückgängig. Sowohl die FORWARD-Regeln als auch die sysctl-Einstellungen aus §1.2 sind erforderlich: sysctl aktiviert die IP-Weiterleitung auf Kernel-Ebene, aber die Firewall (UFW setzt die Forward-Policy standardmäßig auf DROP) blockiert weitergeleitete Pakete weiterhin, bis die FORWARD-Chain explizit geöffnet wird.\nEs gibt keine IPv6-MASQUERADE-Regel, weil dieses Setup ULA-Adressen (fd...) verwendet — sie werden nur innerhalb des WireGuard-Tunnels geroutet und verlassen den VPS nie in Richtung Internet.\nVor dem Speichern dieser Konfiguration den Namen des Internet-Interfaces mit ip -br link prüfen und eth0 bei Bedarf ersetzen (übliche Alternativen: ens3, ens18, venet0).\n[Interface] Address = 10.0.0.1/24, fde4:ed21:b2c0:56dd::1/64 ListenPort = 51822 PrivateKey = \u0026lt;vps-private-key\u0026gt; # MTU = 1360 # auskommentieren bei Problemen mit großen Dateiübertragungen # eth0 durch das eigene Internet-Interface ersetzen PostUp = iptables -A FORWARD -i wg0 -j ACCEPT PostUp = iptables -A FORWARD -o wg0 -j ACCEPT PostUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT PostUp = ip6tables -A FORWARD -o wg0 -j ACCEPT PreDown = iptables -D FORWARD -i wg0 -j ACCEPT PreDown = iptables -D FORWARD -o wg0 -j ACCEPT PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE PreDown = ip6tables -D FORWARD -i wg0 -j ACCEPT PreDown = ip6tables -D FORWARD -o wg0 -j ACCEPT # ── Heimnetz (OPNsense) ─────────────────────────────────────────── [Peer] PublicKey = \u0026lt;opnsense-public-key\u0026gt; # Kein Endpoint — OPNsense initiiert die Verbindung, VPS lernt die Adresse dynamisch # AllowedIPs: Tunnel-IPs + gesamtes Heimnetz-IPv4-LAN + gesamter Heimnetz-ULA-/56-Block AllowedIPs = 10.0.0.2/32, fde4:ed21:b2c0:56dd::2/128, 10.56.0.0/20, fde4:ed21:b2c0:5600::/56 # ── Road Warrior / Client ───────────────────────────────────────── [Peer] PublicKey = \u0026lt;client-public-key\u0026gt; AllowedIPs = 10.0.0.3/32, fde4:ed21:b2c0:56dd::3/128 # Kein Endpoint nötig — Client initiiert die Verbindung OPNsense erscheint hier wie jeder andere WireGuard-Peer. Was dieses Setup zum Site-to-Site-Tunnel macht — statt einem gewöhnlichen Client-VPN — sind die AllowedIPs für den OPNsense-Peer: Durch die Aufnahme der gesamten Heimnetz-Subnetze (10.56.0.0/20 und fde4:ed21:b2c0:5600::/56) erstellt der VPS Routing-Tabelleneinträge für diese Prefixe, die auf OPNsense zeigen. In WireGuard fungiert AllowedIPs sowohl als Route als auch als ACL: Pakete für diese Subnetze werden an OPNsense gesendet, und nur Pakete aus diesen Subnetzen werden von OPNsense akzeptiert.\n1.4 Aktivieren und starten # Den Tunnel aktivieren:\nsystemctl enable --now wg-quick@wg0 wg show # Interface und Peers überprüfen 1.5 UFW-Firewall # Ich nutze ufw auf meinem VPS. Zunächst den WireGuard-Port freischalten:\nufw allow 51822/udp comment \u0026#34;WireGuard\u0026#34; Falls UFW noch nicht aktiv ist, sicherstellen, dass Port 22/TCP erlaubt ist, bevor ufw enable ausgeführt wird — sonst sperrt man sich aus der SSH-Verbindung aus.\nAußerdem muss UFW die Paketweiterleitung erlauben. /etc/default/ufw bearbeiten und die Forward-Policy ändern:\nDEFAULT_FORWARD_POLICY=\u0026#34;ACCEPT\u0026#34; Dann UFW neu laden:\nufw reload Teil 2 — OPNsense (Heimgateway) # Alle Schritte werden in der OPNsense-Weboberfläche durchgeführt.\n2.1 WireGuard-Instanz erstellen # VPN → WireGuard → Instances → Add\nFeld Wert Name wg-vps-tunnel Listen Port 51822 Tunnel Address 10.0.0.2/24, fde4:ed21:b2c0:56dd::2/64 Generate keypair öffentlichen Schlüssel für die VPS-Konfiguration kopieren 2.2 VPS als Peer hinzufügen # VPN → WireGuard → Peers → Add\nFeld Wert Name vps-hub Public Key \u0026lt;vps-public-key\u0026gt; Endpoint Address VPS_PUBLIC_IPv6 Endpoint Port 51822 Allowed IPs 10.0.0.0/24, fde4:ed21:b2c0:56dd::/64 Keepalive 25 Die IPv6-Adresse des VPS als Endpunkt verwenden — die Verbindung Heimnetz→VPS läuft über IPv6, da das Heimnetz keine öffentliche IPv4 hat.\nEin Keepalive von 25 Sekunden ist notwendig, weil OPNsense hinter dem DS-Lite-CGNAT sitzt. WireGuard ist bei Inaktivität vollständig still, und NAT-State-Tabellen lassen UDP-Mappings typischerweise nach 25–30 Sekunden ablaufen. Ein Keepalive-Paket alle 25 Sekunden hält das Mapping aktiv und stellt sicher, dass OPNsense jederzeit Pakete vom VPS empfangen kann.\n2.3 WireGuard-Interface zuweisen # Interfaces → Assignments → das neue wg-Interface zuweisen und aktivieren.\n2.4 Gateway hinzufügen # System → Gateways → Configuration → Add\nFeld Wert Name wg-vps-tunnel_gw Interface wgvpstunnel Address Family IPv4 IP Address 10.0.0.1 Disable Gateway Monitoring ✅ Description WireGuard VPS Tunnel IPv4 Gateway OPNsense erstellt für WireGuard-Interfaces nicht automatisch eine Connected-Route (anders als Linux). Das Gateway-Objekt muss man manuell anlegen.\n2.5 Statische Route hinzufügen # System → Routes → Configuration → Add\nFeld Wert Network Address 10.0.0.0/24 Gateway wg-vps-tunnel_gw - 10.0.0.1 Description WireGuard VPS Tunnel IPv4 Route Diese Route ist erforderlich. Ohne sie weiß OPNsense nicht, dass Return-Traffic für 10.0.0.0/24 zurück in den Tunnel geleitet werden soll.\n2.6 IPv6-Gateway hinzufügen # System → Gateways → Configuration → Add\nFeld Wert Name wg-vps-tunnel_gw6 Interface wgvpstunnel Address Family IPv6 IP Address fde4:ed21:b2c0:56dd::1 Disable Gateway Monitoring ✅ Description WireGuard VPS Tunnel IPv6 Gateway 2.7 IPv6-statische Route hinzufügen # System → Routes → Configuration → Add\nFeld Wert Network Address fde4:ed21:b2c0:56dd::/64 Gateway wg-vps-tunnel_gw6 - fde4:ed21:b2c0:56dd::1 Description WireGuard VPS Tunnel IPv6 Route 2.8 Firewallregeln # Firewall → Rules → [wgvpstunnel-Interface] → Add (IPv4 — Tunnel-Subnetz erlauben)\nFeld Wert Action Pass TCP/IP Version IPv4 Source 10.0.0.0/24 Destination 10.0.0.0/24 OPNsense blockiert standardmäßig den gesamten Traffic auf neuen Interfaces, sodass selbst bei aufgebautem Tunnel keine Pakete fließen, bis eine Pass-Regel vorhanden ist. Ohne diese Regel schlägt ein ping 10.0.0.2 vom VPS fehl, was eine Überprüfung der Tunnel-Konnektivität unmöglich macht. Die Regel erlaubt jedem Host im Tunnel-Subnetz, jeden anderen Host im gleichen Subnetz zu erreichen — einschließlich OPNsenses eigener Tunnel-IP 10.0.0.2.\nFirewall → Rules → [wgvpstunnel-Interface] → Add (IPv4 — Zugriff auf Heimnetz erlauben)\nFeld Wert Action Pass TCP/IP Version IPv4 Source 10.0.0.0/24 Destination 10.56.0.0/20 Firewall → Rules → [wgvpstunnel-Interface] → Add (IPv6 — Zugriff auf Heimnetz-ULA erlauben)\nFeld Wert Action Pass TCP/IP Version IPv6 Source fde4:ed21:b2c0:56dd::/64 Destination fde4:ed21:b2c0:5600::/56 Firewall → Rules → LAN → Add\nFeld Wert Action Pass TCP/IP Version IPv4+IPv6 Source 10.56.0.0/20 / fde4:ed21:b2c0:5600::/56 Destination 10.0.0.0/24 / fde4:ed21:b2c0:56dd::/64 Teil 3 — Road Warrior / Client # 3.1 Schlüssel generieren # Linux/macOS:\nwg genkey | tee client_private.key | wg pubkey \u0026gt; client_public.key Windows: Die offizielle WireGuard-GUI verwenden — sie generiert das Schlüsselpaar automatisch.\n3.2 WireGuard-Konfiguration client.conf # [Interface] Address = 10.0.0.3/24, fde4:ed21:b2c0:56dd::3/64 PrivateKey = \u0026lt;client-private-key\u0026gt; # DNS: OPNsense MGMT Interface (IPv4 + IPv6) DNS = 10.56.0.1, fde4:ed21:b2c0:5600::254 # MTU = 1360 # auskommentieren bei Problemen mit großen Dateiübertragungen [Peer] PublicKey = \u0026lt;vps-public-key\u0026gt; Endpoint = VPS_PUBLIC_IPv4:51822 AllowedIPs = 10.0.0.0/24, 10.56.0.0/20, fde4:ed21:b2c0:56dd::/64, fde4:ed21:b2c0:5600::/56 PersistentKeepalive = 25 AllowedIPs leitet den Tunnel-Traffic, das gesamte Heimnetz-IPv4-LAN, das Tunnel-IPv6-Subnetz und den gesamten Heimnetz-ULA-/56-Block über den VPS. Internet-Traffic bleibt lokal auf dem Client (Split Tunnel).\nfde4:ed21:b2c0:56dd::/64 liegt innerhalb von fde4:ed21:b2c0:5600::/56 — das /56 deckt 5600:: bis 56ff:: ab, sodass 56dd bereits enthalten ist. Man könnte den /64-Eintrag weglassen, und das /56 allein würde ihn abdecken, aber beide Einträge machen die Absicht explizit: 56dd::/64 ist das VPN-Tunnel-Subnetz, 5600::/56 ist der ULA-Block des Heimnetzes. WireGuard löst die Überschneidung über Longest-Prefix-Matching auf.\n3.3 Client-Peer zum VPS hinzufügen # Sobald der öffentliche Schlüssel des Clients vorliegt, diesen zum VPS hinzufügen:\n# Live hinzufügen ohne bestehende Verbindungen zu unterbrechen wg set wg0 peer \u0026lt;client-public-key\u0026gt; allowed-ips 10.0.0.3/32,fde4:ed21:b2c0:56dd::3/128 # In Konfiguration persistieren wg-quick save wg0 Überprüfung # Auf dem VPS # # Tunnel-Status und Peer-Handshakes prüfen wg show # Erfolgreicher Output zeigt aktuellen Handshake und Datentransfer: # peer: \u0026lt;opnsense-pubkey\u0026gt; # latest handshake: 14 seconds ago # transfer: 1.23 MiB received, 456 KiB sent # OPNsense-Tunnel-IPs anpingen ping 10.0.0.2 ping6 fde4:ed21:b2c0:56dd::2 # Ein Gerät im Heimnetz anpingen (IPv4 + IPv6 ULA) ping 10.56.0.1 ping6 fde4:ed21:b2c0:5600::254 # Client-Tunnel-IPs anpingen (sobald Client-Peer verbunden ist) ping 10.0.0.3 ping6 fde4:ed21:b2c0:56dd::3 Vom Road Warrior / Client # # VPS-Tunnel-IPs anpingen ping 10.0.0.1 ping6 fde4:ed21:b2c0:56dd::1 # OPNsense-Tunnel-IPs anpingen ping 10.0.0.2 ping6 fde4:ed21:b2c0:56dd::2 # Ein Gerät im Heimnetz per IPv4 anpingen ping 10.56.0.1 # Ein Heimgerät mit ausschließlich ULA-IPv6-Adresse anpingen ping6 fde4:ed21:b2c0:5601::\u0026lt;address\u0026gt; # z.B. ein Gerät im Server-VLAN Paketanalyse (auf dem VPS) # # ICMP-Traffic auf dem Tunnel-Interface beobachten tcpdump -i wg0 icmp # Wenn Echo Request sichtbar, aber kein Echo Reply: # → Paket erreicht den Tunnel, aber OPNsense blockiert es (Firewallregeln prüfen) # Wenn gar nichts sichtbar: # → Paket tritt nicht in den Tunnel ein (AllowedIPs und Routing prüfen) Quellen # How to setup WireGuard on Ubuntu 20.04 ","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/posts/access-dslite-net-from-ipv4-only-nets/","section":"Posts","summary":"","title":"VPS als WireGuard-VPN-Hub: DS-Lite-Heimnetzwerke aus IPv4-only-Netzen erreichen","type":"posts"},{"content":"","date":"19 Juni 2026","externalUrl":null,"permalink":"/de/tags/wireguard/","section":"Tags","summary":"","title":"Wireguard","type":"tags"},{"content":"","date":"5 Juni 2026","externalUrl":null,"permalink":"/de/tags/firewall/","section":"Tags","summary":"","title":"Firewall","type":"tags"},{"content":" Einleitung # Ich habe zuhause eine DS-Lite-Verbindung, bereitgestellt von M-Net. Ich betreibe eine OPNsense-Firewall und musste die beiden zum Laufen bringen. Mein erster Gedanke war, meinen Internetanbieter (ISP) anzurufen und nach einem richtigen Dual-Stack-Setup mit echter öffentlicher IPv4-Adresse zu fragen — hauptsächlich wegen VPN-Zugriffsproblemen aus IPv4-only-Netzwerken. Aber ich entschloss mich, das als Herausforderung anzunehmen: ich mag IPv6, weshalb ich lernen wollte mit den Einschränkungen von DS-Lite umzugehen und Lösungen für die verbleibenden Probleme finden. Es gibt einen Folgeartikel darüber, wie man aus einem IPv4-only-Netzwerk auf ein DS-Lite-Heimnetzwerk zugreift, indem man einen VPS als WireGuard-Hub verwendet.\nOPNsense unterstützt DS-Lite, aber es erfordert eine spezifische Konfiguration und es gibt einige nicht-offensichtliche Stolperfallen. Dieser Artikel führt durch die vollständige Konfiguration.\nDiese Anleitung verwendet M-Net als Beispiel-ISP. M-Net ist ein deutscher regionaler Anbieter. Die VLAN-ID (40), die AFTR-Adresse und das Format des PPPoE-Benutzernamens sind M-Net-spezifisch — dein ISP kann abweichen. Das generelle Vorgehen ist für jede DS-Lite-Verbindung gleich, aber diese Werte solltest du mit deinem Anbieter abklären. Was ist DS-Lite? # DS-Lite (Dual-Stack Lite, RFC 6333) ist eine Übergangstechnologie, die es ISPs ermöglicht, ihren Kunden IPv6 bereitzustellen und dabei öffentliche IPv4-Adressen zu schonen. Aus Kundensicht sieht es so aus:\nMan bekommt ein öffentliches, routbares IPv6-Prefix (in meinem Fall ein /56 von M-Net, delegiert via DHCPv6). Man bekommt keine öffentliche IPv4-Adresse. Stattdessen wird der IPv4-Verkehr durch die IPv6-Verbindung zu einem Gerät namens AFTR (Address Family Transition Router) beim ISP getunnelt. Der AFTR NATet dann den Verkehr aller Kunden hinter gemeinsamen öffentlichen IPv4-Adressen (CGNAT, RFC 6598). Der Tunnel zwischen dem eigenen Router und dem AFTR ist ein GIF-Tunnel (Generic tunnel Interface) — er transportiert IPv4-Traffic eingebettet in IPv6-Pakete. Innerhalb des Tunnels verwenden beide Endpunkte Adressen aus dem reservierten 192.0.0.0/29-Block (RFC 6333 §10):\nAdresse Rolle 192.0.0.2 Eigener Router (B4-Element) 192.0.0.1 ISP AFTR Gateway Die praktischen Nachteile: Man verliert eine echte öffentliche IPv4, Port-Forwarding ist nicht möglich, und VPN-Protokolle, die auf eingehende IPv4-Verbindungen angewiesen sind, benötigen eine Lösung. Jeder Host und Dienst hinter dem Router sollte im Idealfall direkt über IPv6 erreichbar sein.\nVoraussetzungen # OPNsense (getestet auf 24.x) Ein DSL-Modem im Bridge-Modus — M-Net erfordert VLAN 40 auf dem WAN. Ein DrayTek Vigor 166 funktioniert gut; eine FritzBox ebenfalls. M-Net PPPoE-Zugangsdaten (Benutzername und Passwort aus dem Kundenportal) Die AFTR-IPv6-Adresse für M-Net: 2001:a60:0:2::ffff (Hostname aftr.prod.m-online.net — muss selbst aufgelöst werden, OPNsense akzeptiert im GIF-Setup nur eine IP-Adresse) Schritt 1: Modem-Einrichtung # Das Modem muss im Bridge-Modus betrieben werden, damit OPNsense die rohen PPPoE-Frames empfängt und die Verbindung selbst verwaltet. M-Net erfordert VLAN 40 — sicherstellen, dass das Modem es korrekt durchleitet.\nSchritt 2: PPPoE-Gerät erstellen # In OPNsense: Interfaces → Devices → Point-to-Point.\nNeuen Eintrag hinzufügen:\nFeld Wert Link Type PPPoE Link Interface(s) Physischer WAN-Port (z.B. igb2) Username M-Net-Benutzername (Format: XXXXXXX@mdsl.mnet-online.de) Password M-Net-Passwort Description mnet_pppoe_dslite Alle anderen Felder auf den Standardwerten lassen. Speichern und übernehmen.\nEin neues Gerät pppoe0 (oder pppoe1, wenn bereits eines existiert) erscheint in der Geräteliste.\nSchritt 3: WAN-Interface zuweisen und konfigurieren # Unter Interfaces → Assignments sicherstellen, dass das WAN-Interface dem neu erstellten PPPoE-Gerät (pppoe1) zugewiesen ist.\nDann Interfaces → WAN öffnen und wie folgt konfigurieren:\nIPv4 Configuration Type → None DS-Lite gibt keine echte IPv4 auf dem WAN-Interface — IPv4 kommt in einem späteren Schritt durch den GIF-Tunnel.\nIPv6 Configuration Type → DHCPv6 Stellt die IPv6-Verbindung über den PPPoE-Link her und fordert die Prefix Delegation von M-Net an.\nUnter DHCPv6 client configuration folgendes einstellen:\nFeld Wert Prefix Delegation Size 56 Send prefix hint ✓ aktiviert Optional Prefix ID 9 Die Prefix ID bestimmt, welches /64-Sub-Prefix des delegierten /56 das WAN-Interface für seine IPv6-Adresse verwendet. Der konkrete Wert spielt keine Rolle, solange er sich von den Prefix IDs der LAN- und VLAN-Interfaces unterscheidet — der Wert 9 reserviert ein /64 für das WAN und lässt die IDs 0–8 für LAN und VLANs frei. Das Ergebnis ist ein WAN-Interface mit einer routbaren Global Unicast Address (GUA), die der GIF-Tunnel in Schritt 5 braucht.\nSpeichern und übernehmen. OPNsense stellt nun die PPPoE-Verbindung her und fordert ein IPv6 /56-Prefix von M-Net an.\nSchritt 4: IPv6 auf LAN und VLANs tracken # Für jedes interne Interface (LAN, VLANs) unter Interfaces → [Interface] folgendes einstellen:\nFeld Wert IPv6 Configuration Type Track Interface (legacy) Parent Interface WAN Assign Prefix ID Ein eindeutiger Wert pro Interface (z.B. 0 für LAN, 1–8 für VLANs) Damit wird OPNsense angewiesen, die IPv6-Adresse jedes Interfaces aus dem /56-Block abzuleiten, der dem WAN delegiert wurde. Jede Prefix ID entspricht einem eigenen /64 innerhalb des /56.\nZu diesem Zeitpunkt sollte IPv6-Konnektivität bestehen. Testen mit ping6 2620:fe::fe (Quad9) aus der OPNsense-Shell oder von einem Host dahinter. Wenn IPv6 funktioniert, weiter zum IPv4-Tunnel.\nSchritt 5: GIF-Tunnel erstellen # Der GIF-Tunnel transportiert IPv4-Verkehr in IPv6-Paketen zum AFTR von M-Net.\nUnter Interfaces → Devices → GIF.\nNeuen Eintrag hinzufügen:\nFeld Wert Local address WAN (oder ein beliebiges Interface mit GUA — siehe Hinweis unten) Remote address 2001:a60:0:2::ffff Tunnel local address 192.0.0.2 Tunnel remote address 192.0.0.1 Tunnel netmask / prefix 29 Disable Ingress filtering ✓ aktiviert Description AFTR_MNET Welches Interface als lokale Adresse verwenden? Der GIF-Tunnel benötigt eine Global Unicast Address (GUA) als IPv6-Quelle (eine Link-Local-Adresse ist nicht routbar und erreicht den AFTR nicht). Da in Schritt 3 eine Prefix ID (9) auf den DHCPv6-Client des WAN gesetzt wurde, erhält das WAN-Interface eine GUA aus dem delegierten /56 und funktioniert hier. Jedes andere Interface mit einer GUA (LAN, ein VLAN) funktioniert ebenfalls.\nSpeichern und übernehmen.\nSchritt 6: GIF-Interface als WANv4 zuweisen # Unter Interfaces → Assignments das gif0-Gerät als neues Interface hinzufügen. Beschreibung auf WANv4 setzen.\nInterfaces → WANv4 öffnen:\nInterface aktivieren Sowohl IPv4 als auch IPv6 Configuration Type auf None lassen — die Adressen sind bereits in der GIF-Konfiguration definiert Speichern und übernehmen.\nSchritt 7: Gateway überprüfen # Wenn das WANv4-Interface zugewiesen wird, erstellt OPNsense automatisch einen Gateway-Eintrag dafür. Unter System → Gateways → Configuration überprüfen, ob er vorhanden ist.\nDer automatisch erstellte Gateway hat das WANv4-Interface zugewiesen, ein leeres IP-Adressfeld (OPNsense leitet den Endpunkt aus der GIF-Tunnel-Konfiguration ab) und Gateway-Monitoring deaktiviert. Er muss nicht als Upstream-Gateway gesetzt werden — OPNsense routet IPv4-Verkehr automatisch durch ihn.\nSetup überprüfen # Von einem Host im LAN sollten nun sowohl IPv4 als auch IPv6 funktionieren:\ncurl -4 ifconfig.me — sollte eine Adresse im Bereich 100.64.0.0/10 zurückgeben (CGNAT, normal bei DS-Lite) curl -6 ifconfig.me — sollte die öffentliche IPv6-Adresse zurückgeben Wenn IPv4 nichts zurückgibt oder der Tunnel nicht aufgebaut wird:\nPrüfen, ob IPv6 zuerst funktioniert (der Tunnel hängt davon ab) Prüfen, ob die AFTR-Adresse korrekt ist — aftr.prod.m-online.net auflösen und mit 2001:a60:0:2::ffff vergleichen Prüfen, ob das GIF-Local-Address-Interface eine GUA hat (z.B. WAN mit gesetzter Prefix ID, oder LAN) Was nicht funktioniert # Port Forwarding: Man teilt sich eine öffentliche IPv4 mit anderen Kunden hinter dem AFTR. Eingehende IPv4-Verbindungen sind nicht möglich. Die Lösung ist, IPv6 für alles zu verwenden, das von außen erreichbar sein soll, oder durch einen VPS zu tunneln (Thema des nächsten Artikels). VPNs über IPv4 von außen: Gleicher Grund. WireGuard oder OpenVPN, das auf der öffentlichen IPv6-Adresse lauscht, funktioniert einwandfrei. Bekannte Probleme # Es gibt einen ungelösten Bug in OPNsense, der bei DS-Lite-Setups zu sporadischen Problemen führen kann: opnsense/core#7713. Stand OPNsense 26.1.5 ist das Issue noch offen. Wenn die IPv4-Konnektivität durch den GIF-Tunnel unerwartet abbricht oder sich inkonsistent verhält, könnte dieser Bug die Ursache sein. Ressourcen # DS-Lite on 23.7.6+ (OPNsense Forum) OPNsense Core Issue #7713 OPNsense Forum topic 46665 OPNsense Forum topic 27935 M-Net DS-Lite mit pfSense (cybercyber.org) RFC 6333 — Dual-Stack Lite Dieser Artikel wurde mit Unterstützung von Claude (Anthropic) verfasst.\n","date":"5 Juni 2026","externalUrl":null,"permalink":"/de/posts/opnsense-ds-lite/","section":"Posts","summary":"","title":"OPNsense mit DS-Lite","type":"posts"},{"content":"$ whoami petar.cubela Viele haben das schon vor mir gemacht, aber ich finde es trotzdem eine gute Idee, sich vorzustellen. Es liegt viel Schönheit in der Schlichtheit des genialen Designs eines UNIX-Systems und seiner Mensch-Maschine-Schnittstelle.\nDies ist meine Homepage. Danke, dass du vorbeischaust.\nIch bin Systemadministrator, Linux-Enthusiast mit einer Leidenschaft für komplexe Netzwerkinfrastrukturen und Physiker durch Studium. Ich bemühe mich, immer besser im Schreiben zu werden. Ich liebe Lyrik und klassische Bücher und Musik.\nHier findet man vor allem technische Blog-Artikel über Self-Hosting, Open-Source-Software, Netzwerke (OPNsense, IPv6), die Administration von Linux-Systemen, vielleicht ein bisschen Physik und Texte über meine eigenen Gedanken.\nIch werde Texte auf Deutsch und Englisch schreiben. Manche in beiden Sprachen, manche nur in einer.\n$ history Nach der Schule entwickelte ich ein tiefes Interesse für Wissenschaft und Physik, insbesondere für theoretische Physik. Deshalb entschied ich mich, Physik zu studieren, was ich an der LMU in München tat.\nLinux ist großartig zum Prokrastinieren, wenn man eigentlich an der Masterarbeit arbeiten sollte. :-)\nAus dieser Prokrastination wurde schließlich mein Beruf: Heute administriere ich beruflich Linux-Systeme und Netzwerke.\n","date":"5 Juni 2026","externalUrl":null,"permalink":"/de/about/","section":"CubelaPetar","summary":"","title":"Über mich","type":"page"},{"content":"","externalUrl":null,"permalink":"/de/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":" Datenschutzerklärung # Verantwortlicher # Verantwortlich für diese Website und die hier beschriebene Verarbeitung:\nPetar Cubela — mail@petarcubela.de\nHosting # Diese Website wird auf einem virtuellen Server der netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe, Deutschland, betrieben. Beim Besuch wird Ihre IP-Adresse verarbeitet, soweit dies zur Auslieferung der Seiten technisch erforderlich ist. Der Webserver speichert keine Zugriffsprotokolle.\nRechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse am sicheren Betrieb des Servers.\nWebanalyse # Diese Website verwendet eine selbst gehostete Instanz von Plausible Analytics (Community Edition), die auf demselben Server wie die Website läuft. Alle Daten verbleiben auf eigener Infrastruktur; es werden keine Daten an Dritte weitergegeben.\nPlausible erfasst in aggregierter Form: Seiten-URL, Referrer, Browser- und Betriebssystemtyp, Gerätetyp sowie das aus der IP-Adresse abgeleitete Land bzw. die Region. Es setzt keine Cookies und speichert nichts auf Ihrem Gerät. Zur Zählung einzigartiger Besucher wird ein nicht umkehrbarer Hash aus IP-Adresse, User-Agent und einem Zufallswert berechnet, der alle 24 Stunden rotiert und endgültig gelöscht wird. Die rohe IP-Adresse wird zu keinem Zeitpunkt gespeichert. Die entstehenden Statistiken sind aggregiert und lassen keine Rückschlüsse auf einzelne Besucher zu.\nRechtsgrundlage: Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse an einer datenschutzfreundlichen Reichweitenmessung.\nKeine weiteren Datenerhebungen # Diese Website verfügt über keine Kontaktformulare, Kommentarfunktionen, Social-Media-Einbindungen, Werbung oder Drittanbieter-Skripte. Es werden keine weiteren personenbezogenen Daten verarbeitet.\nIhre Rechte # Nach Art. 15–20 DSGVO haben Sie das Recht auf Auskunft, Berichtigung, Löschung, Einschränkung der Verarbeitung und Datenübertragbarkeit.\nWiderspruchsrecht (Art. 21 DSGVO): Soweit die Verarbeitung auf berechtigtem Interesse beruht, können Sie ihr jederzeit aus Gründen, die sich aus Ihrer besonderen Situation ergeben, widersprechen.\nSie haben außerdem das Recht, sich bei einer Datenschutz-Aufsichtsbehörde zu beschweren.\nZur Ausübung dieser Rechte wenden Sie sich an die oben genannte E-Mail-Adresse. Beachten Sie, dass diese Website keine Daten speichert, die Sie als Besucher identifizieren könnten; entsprechende Anfragen können daher mangels identifizierbarer Daten möglicherweise nicht erfüllt werden (Art. 11 DSGVO).\n","externalUrl":null,"permalink":"/de/privacy/","section":"Datenschutz","summary":"","title":"Datenschutz","type":"privacy"},{"content":"Angaben gemäß § 18 Abs. 1 Medienstaatsvertrag (MStV):\nPetar Cubela\nKontakt: mail@petarcubela.de\nDies ist ein privates, nicht-kommerzielles Blog.\n","externalUrl":null,"permalink":"/de/impressum/","section":"Impressum","summary":"","title":"Impressum","type":"impressum"}]