[{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/","section":"CubelaPetar","summary":"","title":"CubelaPetar","type":"page"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/ds-lite/","section":"Tags","summary":"","title":"Ds-Lite","type":"tags"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/series/home-network-with-ipv6/","section":"Series","summary":"","title":"Home Network With IPv6","type":"series"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/ipv6/","section":"Tags","summary":"","title":"Ipv6","type":"tags"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/categories/network/","section":"Categories","summary":"","title":"Network","type":"categories"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/opnsense/","section":"Tags","summary":"","title":"Opnsense","type":"tags"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/categories/tutorial/","section":"Categories","summary":"","title":"Tutorial","type":"categories"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/vpn/","section":"Tags","summary":"","title":"Vpn","type":"tags"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/vps/","section":"Tags","summary":"","title":"Vps","type":"tags"},{"content":" Introduction # I\u0026rsquo;m writing this while on a train to Zurich, on the train\u0026rsquo;s public Wi-Fi — IPv4-only. And I\u0026rsquo;m still connected to all my home services via VPN, even though my home sits behind a DS-Lite connection with no public IPv4. My other article covers setting up OPNsense with DS-Lite.\nThe solution: a VPS with dual-stack public IPs acting as a WireGuard hub. My home router connects to the VPS over IPv6, and I connect from anywhere using the VPS\u0026rsquo;s public IPv4. I needed this mainly for work — our office network is IPv4-only and I wanted access to my self-hosted LLM server at home. I discussed it with Claude, which suggested a site-to-site WireGuard tunnel between home and VPS over IPv6, with road warriors connecting to the VPS over IPv4.\nOverview # The result: I can reach any home address from an IPv4-only network — including VLANs that are IPv6-only. It\u0026rsquo;s been solid since I set it up.\nThe VPS is the hub:\n[Home LAN 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 Network plan # Role Device WireGuard IPv4 WireGuard IPv6 (ULA) Public Endpoint Hub VPS 10.0.0.1/24 fde4:ed21:b2c0:56dd::1/64 VPS_PUBLIC_IPv4 (static IPv4) / VPS_PUBLIC_IPv6 (static IPv6) Home gateway OPNsense 10.0.0.2/24 fde4:ed21:b2c0:56dd::2/64 vpn.petarcubela.de (dynamic IPv6 via DDNS) Road warrior Laptop/PC 10.0.0.3/24 fde4:ed21:b2c0:56dd::3/64 CLIENT_PUBLIC_IPv4 (IPv4) Home LAN IPv4 subnet: 10.56.0.0/20 (covers all home VLANs) Home LAN IPv6 ULA block: fde4:ed21:b2c0:5600::/56 (covers all home VLANs) WireGuard tunnel IPv4 subnet: 10.0.0.0/24 WireGuard tunnel IPv6 subnet: fde4:ed21:b2c0:56dd::/64 WireGuard port: 51822/udp Part 1 — VPS setup # All the commands in the following are executed as the root user. 1.1 Generate keys # Generate a keypair using wg and store both files in the default WireGuard directory. The private key needs restricted permissions.\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 Enable IP forwarding # The VPS needs to forward packets between the tunnel and the internet, so IP forwarding must be enabled.\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 config /etc/wireguard/wg0.conf # The PostUp hooks run after the interface comes up and do two things: open the kernel firewall to allow forwarded traffic (FORWARD rules), and enable NAT for outbound IPv4 via the physical interface (MASQUERADE on eth0). The PreDown hooks undo this cleanly before the interface goes down. Both the FORWARD rules and the sysctl settings from §1.2 are required: sysctl enables IP forwarding at the kernel level, but the firewall (ufw sets the forward policy to DROP by default) still blocks forwarded packets until the FORWARD chain is explicitly opened.\nThere is no IPv6 MASQUERADE rule because this setup uses ULA addresses (fd...) — they route only within the WireGuard tunnel and never leave the VPS to the internet.\nBefore saving this config, check your internet-facing interface name with ip -br link and replace eth0 if it differs (common alternatives: 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 # uncomment if large transfers stall # Replace eth0 with your actual internet-facing interface 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 # ── Home (OPNsense) ─────────────────────────────────────────── [Peer] PublicKey = \u0026lt;opnsense-public-key\u0026gt; # No Endpoint — OPNsense initiates, VPS learns the address dynamically # AllowedIPs: tunnel IPs + entire home IPv4 LAN + entire home 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 # No Endpoint needed — client initiates the connection Notice that OPNsense appears here as just another WireGuard peer. What makes this a site-to-site tunnel — rather than a plain client VPN — is the AllowedIPs for the OPNsense peer: by including the full home LAN subnets (10.56.0.0/20 and fde4:ed21:b2c0:5600::/56), the VPS builds routing table entries for those entire prefixes pointing at OPNsense. In WireGuard, AllowedIPs acts as both a route and an ACL: packets destined for those subnets are sent to OPNsense, and only packets sourced from those subnets are accepted from OPNsense.\n1.4 Enable and start # Enable the tunnel:\nsystemctl enable --now wg-quick@wg0 wg show # verify interface and peers 1.5 UFW firewall # I use ufw on my VPS. First, allow the WireGuard port:\nufw allow 51822/udp comment \u0026#34;WireGuard\u0026#34; If UFW is not already active, ensure port 22/TCP is allowed before running ufw enable to avoid locking yourself out of SSH.\nNext, packet forwarding must also be permitted by UFW. Edit /etc/default/ufw and change the forward policy:\nDEFAULT_FORWARD_POLICY=\u0026#34;ACCEPT\u0026#34; Then reload UFW to apply:\nufw reload Part 2 — OPNsense (home gateway) # All steps are performed in the OPNsense web UI.\n2.1 Create WireGuard instance # VPN → WireGuard → Instances → Add\nField Value Name wg-vps-tunnel Listen Port 51822 Tunnel Address 10.0.0.2/24, fde4:ed21:b2c0:56dd::2/64 Generate keypair copy the public key for use on the VPS 2.2 Add VPS as a peer # VPN → WireGuard → Peers → Add\nField Value 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 Use the VPS IPv6 address as the endpoint — the home→VPS leg travels over IPv6 since home has no public IPv4.\nThe Keepalive of 25 seconds is necessary because OPNsense sits behind the DS-Lite CGNAT. WireGuard is completely silent when idle, and NAT state tables typically expire UDP mappings after 25–30 seconds of inactivity. A keepalive packet every 25 seconds keeps the mapping alive and ensures OPNsense can always receive incoming packets from the VPS.\n2.3 Assign the WireGuard interface # Interfaces → Assignments → assign the new wg interface, enable it.\n2.4 Add gateway # System → Gateways → Configuration → Add\nField Value 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 does not automatically create a connected route for WireGuard interfaces (unlike Linux). You must add the gateway object manually.\n2.5 Add static route # System → Routes → Configuration → Add\nField Value Network Address 10.0.0.0/24 Gateway wg-vps-tunnel_gw - 10.0.0.1 Description WireGuard VPS tunnel IPv4 route This route is required. Without it OPNsense does not know to send return traffic for 10.0.0.0/24 back into the tunnel.\n2.6 Add IPv6 gateway # System → Gateways → Configuration → Add\nField Value 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 Add IPv6 static route # System → Routes → Configuration → Add\nField Value 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 Firewall rules # Firewall → Rules → [wgvpstunnel interface] → Add (IPv4 — allow tunnel subnet)\nField Value Action Pass TCP/IP Version IPv4 Source 10.0.0.0/24 Destination 10.0.0.0/24 OPNsense blocks all traffic on new interfaces by default, so even with the tunnel established no packets will flow until a pass rule is in place. Without this rule, a ping 10.0.0.2 from the VPS will fail, making it impossible to verify tunnel connectivity. The rule allows any host in the tunnel subnet to reach any other host in the same subnet — including OPNsense\u0026rsquo;s own tunnel address 10.0.0.2.\nFirewall → Rules → [wgvpstunnel interface] → Add (IPv4 — allow access to home LAN)\nField Value Action Pass TCP/IP Version IPv4 Source 10.0.0.0/24 Destination 10.56.0.0/20 Firewall → Rules → [wgvpstunnel interface] → Add (IPv6 — allow access to home ULA)\nField Value Action Pass TCP/IP Version IPv6 Source fde4:ed21:b2c0:56dd::/64 Destination fde4:ed21:b2c0:5600::/56 Firewall → Rules → LAN → Add\nField Value 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 Part 3 — Road warrior / client # 3.1 Generate keys # Linux/macOS:\nwg genkey | tee client_private.key | wg pubkey \u0026gt; client_public.key Windows: Use the official WireGuard GUI — it generates the keypair automatically.\n3.2 WireGuard config 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 # uncomment if large transfers stall [Peer] PublicKey = \u0026lt;vps-public-key\u0026gt; Endpoint = VPS_PUBLIC_IPv4:51822 # VPS IPv4 address AllowedIPs = 10.0.0.0/24, 10.56.0.0/20, fde4:ed21:b2c0:56dd::/64, fde4:ed21:b2c0:5600::/56 PersistentKeepalive = 25 AllowedIPs routes tunnel traffic, the entire home IPv4 LAN, the tunnel IPv6 subnet, and the entire home ULA /56 block through the VPS. Internet traffic remains local on the client (split tunnel).\nfde4:ed21:b2c0:56dd::/64 falls within fde4:ed21:b2c0:5600::/56 — the /56 covers 5600:: through 56ff::, so 56dd is already included. You could drop the /64 entry and the /56 alone would cover it, but listing both makes the intent explicit: 56dd::/64 is the VPN tunnel subnet, 5600::/56 is the home LAN ULA block. WireGuard resolves the overlap via longest-prefix matching.\n3.3 Add client peer to VPS # Once you have the client\u0026rsquo;s public key, add it to the VPS:\n# Add live without dropping existing connections wg set wg0 peer \u0026lt;client-public-key\u0026gt; allowed-ips 10.0.0.3/32,fde4:ed21:b2c0:56dd::3/128 # Persist to config wg-quick save wg0 Verification # On the VPS # # Check tunnel status and peer handshakes wg show # Healthy output shows recent handshake and data transfer: # peer: \u0026lt;opnsense-pubkey\u0026gt; # latest handshake: 14 seconds ago # transfer: 1.23 MiB received, 456 KiB sent # Ping OPNsense tunnel IPs ping 10.0.0.2 ping6 fde4:ed21:b2c0:56dd::2 # Ping a home LAN device (IPv4 + IPv6 ULA) ping 10.56.0.1 ping6 fde4:ed21:b2c0:5600::254 # Ping client tunnel IPs (once client peer is connected) ping 10.0.0.3 ping6 fde4:ed21:b2c0:56dd::3 From road warrior / client # # Ping VPS tunnel IPs ping 10.0.0.1 ping6 fde4:ed21:b2c0:56dd::1 # Ping OPNsense tunnel IPs ping 10.0.0.2 ping6 fde4:ed21:b2c0:56dd::2 # Ping a home LAN device by IPv4 ping 10.56.0.1 # Ping a home device that only has a ULA IPv6 address ping6 fde4:ed21:b2c0:5601::\u0026lt;address\u0026gt; # e.g. a device on the server VLAN Packet-level debugging (on VPS) # # Watch ICMP traffic on the tunnel interface tcpdump -i wg0 icmp # If you see echo request but no echo reply: # → packet reaches the tunnel but OPNsense is dropping it (check firewall rules) # If you see nothing: # → packet never enters the tunnel (check AllowedIPs and routing) Sources # How to setup WireGuard on Ubuntu 20.04 ","date":"19 June 2026","externalUrl":null,"permalink":"/posts/access-dslite-net-from-ipv4-only-nets/","section":"Posts","summary":"","title":"VPS as VPN Hub to Access IPv6-only WAN from IPv4-only Networks","type":"posts"},{"content":"","date":"19 June 2026","externalUrl":null,"permalink":"/tags/wireguard/","section":"Tags","summary":"","title":"Wireguard","type":"tags"},{"content":"$ whoami petar.cubela So many people have done this already but I think this is a great idea to introduce oneself. There is a lot of beauty in the simplicity of the genius behind a UNIX system and its human-machine interface.\nThis is my homepage. Thanks for stopping by.\nI am a system administrator, a Linux enthusiast with a love for complex network infrastructures, and a physicist by degree. I am trying my best to become better at writing texts. I love poetry and classical books and music.\nHere you will find mostly technical blog articles about self-hosting, open source software, networking (OPNsense, IPv6), the administration of Linux systems, maybe a bit of physics, and texts about my own thoughts.\nI will write texts in German and English. Some in both languages, some in only one.\n$ history After finishing school I developed a deep interest in science and physics, especially theoretical physics. Thus, I decided I wanted to study physics, which I did at the LMU in Munich, Germany.\nLinux is great to procrastinate while you should be working on your master\u0026rsquo;s thesis. :-)\nThat procrastination eventually became my profession: today I administrate Linux systems and networks for a living.\n","date":"5 June 2026","externalUrl":null,"permalink":"/about/","section":"CubelaPetar","summary":"","title":"About Me","type":"page"},{"content":"","date":"5 June 2026","externalUrl":null,"permalink":"/tags/firewall/","section":"Tags","summary":"","title":"Firewall","type":"tags"},{"content":" Introduction # I have a DS-Lite connection at home, provided by M-Net. I run an OPNsense firewall and needed the two to work together. My first instinct was to call the ISP and ask for a proper dual-stack setup with a real public IPv4 address, mainly because of VPN access problems from IPv4-only networks. But I decided to take that as a challenge instead — just try to use IPv6 and work around the issues. I have to admit I am a fan of IPv6; I think it is great to not have to deal with NAT and DHCPv4, and SLAAC feels much simpler. There is a follow-up article on how to access a DS-Lite home network from an IPv4-only network using a VPS as a WireGuard hub.\nOPNsense does support DS-Lite, but it takes a specific setup and there are a few non-obvious gotchas. This article walks through the full configuration.\nThis guide uses M-Net as the example ISP. M-Net is a German regional provider. The VLAN ID (40), AFTR address, and PPPoE username format are M-Net-specific — your ISP may differ. The overall approach is the same for any DS-Lite connection, but double-check these values with your provider. What is DS-Lite? # DS-Lite (Dual-Stack Lite, RFC 6333) is a transition technology that lets ISPs hand out IPv6 to their customers while conserving public IPv4 addresses. From the customer\u0026rsquo;s perspective it looks like this:\nYou get a public, routable IPv6 prefix (in my case a /56 from M-Net, delegated via DHCPv6). You get no public IPv4 address. Instead, your IPv4 traffic is tunnelled through the IPv6 connection to a device called the AFTR (Address Family Transition Router) at the ISP. The AFTR then NATes all customers\u0026rsquo; traffic behind shared public IPv4 addresses (CGNAT, RFC 6598). The tunnel between your router and the AFTR is a GIF tunnel (Generic tunnel Interface) — it carries your IPv4 traffic encapsulated inside IPv6 packets. Inside the tunnel, both endpoints use addresses from the reserved 192.0.0.0/29 block (RFC 6333 §10):\nAddress Role 192.0.0.2 Your router (B4 element) 192.0.0.1 ISP AFTR gateway The practical downsides: you lose a real public IPv4, so port forwarding is impossible, and VPN protocols that rely on incoming IPv4 connections need a workaround. Every host and service behind the router should ideally be reachable over IPv6 directly.\nPrerequisites # OPNsense (tested on 24.x) A DSL modem in bridge mode — M-Net requires VLAN 40 on the WAN. A DrayTek Vigor 166 works well for this; a FritzBox also works. Your M-Net PPPoE credentials (username and password from the customer portal) The AFTR IPv6 address for M-Net: 2001:a60:0:2::ffff (hostname aftr.prod.m-online.net — you must resolve it yourself, OPNsense only accepts an IP address in the GIF config) Step 1: Modem Setup # Make sure your modem is in bridge mode so OPNsense receives the raw PPPoE frames and handles the connection itself. M-Net requires VLAN 40 — verify your modem passes it through correctly.\nStep 2: Create the PPPoE Device # In OPNsense, go to Interfaces → Devices → Point-to-Point.\nAdd a new entry:\nField Value Link Type PPPoE Link Interface(s) Your WAN physical port (e.g. igb2) Username Your M-Net username (format: XXXXXXX@mdsl.mnet-online.de) Password Your M-Net password Description mnet_pppoe_dslite Leave all other fields at their defaults. Save and apply.\nA new device pppoe0 (or pppoe1 if one already exists) will appear in the device list.\nStep 3: Assign and Configure the WAN Interface # Go to Interfaces → Assignments and make sure the WAN interface is assigned to the newly created PPPoE device (pppoe1).\nThen open Interfaces → WAN and configure it as follows:\nIPv4 Configuration Type → None DS-Lite does not give you a real IPv4 on the WAN interface — IPv4 will come through the GIF tunnel in a later step.\nIPv6 Configuration Type → DHCPv6 This establishes the IPv6 connection over the PPPoE link and requests the prefix delegation from M-Net.\nUnder DHCPv6 client configuration, set:\nField Value Prefix Delegation Size 56 Send prefix hint ✓ enabled Optional Prefix ID 9 The Prefix ID determines which /64 sub-prefix of the delegated /56 the WAN interface uses for its own IPv6 address. The exact value does not matter as long as it is distinct from your LAN and VLAN prefix IDs — setting it to 9 reserves one /64 for WAN and leaves IDs 0–8 for LAN and VLANs. The result is a WAN interface with a routable Global Unicast Address (GUA), which the GIF tunnel in Step 5 needs.\nSave and apply. OPNsense will now establish the PPPoE connection and request an IPv6 /56 prefix from M-Net.\nStep 4: Track IPv6 on LAN and VLANs # For each internal interface (LAN, VLANs), go to Interfaces → [Interface] and set:\nField Value IPv6 Configuration Type Track Interface (legacy) Parent Interface WAN Assign Prefix ID A unique value per interface (e.g. 0 for LAN, 1–8 for VLANs) This tells OPNsense to derive the IPv6 address of each interface from the /56 block delegated to WAN. Each Prefix ID maps to a distinct /64 within the /56.\nAt this point you should have working IPv6 connectivity. Test with ping6 2620:fe::fe (Quad9) from the OPNsense shell or from a host behind it. If IPv6 works, move on to the IPv4 tunnel.\nStep 5: Create the GIF Tunnel # The GIF tunnel carries your IPv4 traffic inside IPv6 packets to M-Net\u0026rsquo;s AFTR.\nGo to Interfaces → Devices → GIF.\nAdd a new entry:\nField Value Local address WAN (or any interface with a GUA — see note below) 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 ✓ enabled Description AFTR_MNET Which interface to use as local address? The GIF tunnel needs a Global Unicast Address (GUA) as its IPv6 source (a link-local address is not routable and won\u0026rsquo;t reach the AFTR). Because we set a Prefix ID (9) on the WAN DHCPv6 client in Step 3, the WAN interface gets a GUA from the delegated /56 and works fine here. Any other interface with a GUA (LAN, a VLAN) also works.\nSave and apply.\nStep 6: Assign the GIF Interface as WANv4 # Go to Interfaces → Assignments and add the gif0 device as a new interface. Set the description to WANv4.\nOpen Interfaces → WANv4:\nEnable the interface Leave both IPv4 and IPv6 Configuration Type as None — the addresses are already defined in the GIF config Save and apply.\nStep 7: Verify the Gateway # When you assign the WANv4 interface, OPNsense automatically creates a gateway entry for it. Go to System → Gateways → Configuration to verify it exists.\nThe auto-created gateway will have the WANv4 interface assigned, an empty IP Address field (OPNsense infers the endpoint from the GIF tunnel config), and gateway monitoring disabled. You do not need to set it as an upstream gateway — OPNsense routes IPv4 traffic through it automatically.\nVerifying the setup # From a host on the LAN, you should now have both IPv4 and IPv6 connectivity:\ncurl -4 ifconfig.me — should return an address in the 100.64.0.0/10 range (CGNAT, normal for DS-Lite) curl -6 ifconfig.me — should return your public IPv6 address If IPv4 returns nothing or the tunnel is not coming up, check:\nThat IPv6 is working first (the tunnel depends on it) That the AFTR address is correct — resolve aftr.prod.m-online.net and compare with 2001:a60:0:2::ffff That the GIF local address interface has a GUA (e.g. WAN with Prefix ID set, or LAN) What does not work # Port forwarding: You share a public IPv4 with other customers behind the AFTR. Incoming IPv4 connections are not possible. The solution is to use IPv6 for anything that needs to be reachable from outside, or to tunnel through a VPS (covered in the next article). VPNs over IPv4 from outside: Same reason. WireGuard or OpenVPN listening on your public IPv6 address works fine. Known Issues # There is an unresolved bug in OPNsense that can cause intermittent problems with DS-Lite setups: opnsense/core#7713. As of OPNsense 26.1.5 the issue is still open. If your IPv4 connectivity through the GIF tunnel drops unexpectedly or behaves inconsistently, this bug may be the cause. Resources # DS-Lite on 23.7.6+ (OPNsense Forum) OPNsense Core Issue #7713 OPNsense Forum topic 46665 OPNsense Forum topic 27935 M-Net DS-Lite with pfSense (cybercyber.org) RFC 6333 — Dual-Stack Lite This article was written with the assistance of Claude (Anthropic).\n","date":"5 June 2026","externalUrl":null,"permalink":"/posts/opnsense-ds-lite/","section":"Posts","summary":"","title":"OPNsense with DS-Lite","type":"posts"},{"content":"","externalUrl":null,"permalink":"/authors/","section":"Authors","summary":"","title":"Authors","type":"authors"},{"content":"Information pursuant to § 18 Abs. 1 Medienstaatsvertrag (MStV):\nPetar Cubela\nContact: mail@petarcubela.de\nThis is a private, non-commercial personal blog.\n","externalUrl":null,"permalink":"/impressum/","section":"Imprint","summary":"","title":"Imprint","type":"impressum"},{"content":" Privacy Policy # Controller # Responsible for this website and the processing described here:\nPetar Cubela — mail@petarcubela.de\nHosting # This website is served from a virtual private server operated by netcup GmbH, Daimlerstraße 25, 76185 Karlsruhe, Germany. When you visit, your IP address is processed as technically necessary to deliver the pages. The web server does not store access logs.\nLegal basis: Art. 6(1)(f) GDPR — legitimate interest in operating and securing the server.\nWeb Analytics # This site uses a self-hosted instance of Plausible Analytics (Community Edition), running on the same server as the website. All data stays on my own infrastructure; nothing is shared with third parties.\nPlausible collects in aggregate: page URL, referrer, browser and operating system type, device type, and the country/region derived from the IP address. It sets no cookies and stores nothing on your device. To count unique visitors, a one-way hash is computed from the IP address, the user-agent string, and a random salt that is rotated and permanently deleted every 24 hours. The raw IP address is never stored. The resulting statistics are aggregated and cannot be linked to individual visitors.\nLegal basis: Art. 6(1)(f) GDPR — legitimate interest in privacy-preserving reach measurement.\nNo Other Data Collection # This site has no contact forms, comment sections, social media embeds, advertising, or third-party scripts. No other personal data is processed.\nYour Rights # Under Arts. 15–20 GDPR you have the right to access, rectification, erasure, restriction of processing, and data portability.\nRight to object (Art. 21 GDPR): where processing is based on legitimate interest, you may object at any time on grounds relating to your particular situation.\nYou also have the right to lodge a complaint with a data protection supervisory authority.\nTo exercise these rights, contact me at the email address above. Note that this site retains no data that could identify you as a visitor, so such requests may be impossible to fulfil for lack of identifiable data (Art. 11 GDPR).\n","externalUrl":null,"permalink":"/privacy/","section":"Privacy","summary":"","title":"Privacy","type":"privacy"}]