This video demonstrates the setup and inherent limitations of a WireGuard side-to-side VPN connection using a consumer-grade AVM Fritzbox router and an IP464 cloud router. The presenter successfully establishes the VPN tunnel and confirms basic connectivity via ping and web interface access to the Fritzbox's tunnel IP. However, a critical issue is revealed: when attempting to access devices in the Fritzbox's local network, while ping responses are received, TCP-based services (like browser access) fail. Wireshark analysis conclusively shows that the Fritzbox performs unconfigurable Source Network Address Translation (SNAT) on outgoing VPN traffic originating from its LAN, changing the source IP of response packets from the expected local network address to its own WireGuard tunnel IP. This behavior breaks TCP sessions as the receiving end expects the original source IP. The video concludes by labeling the Fritzbox as "stupid" for this unconfigurable flaw in side-to-side VPN scenarios and suggests a workaround: using a dedicated device like a Raspberry Pi behind the Fritzbox to handle the VPN, circumventing the Fritzbox's unwanted NAT.
Summarizing the Transcript:
0:00 - Introduction to the Problem: The video introduces the topic of setting up a WireGuard Side-to-Side VPN with a Fritzbox, which the presenter sarcastically calls a "stupid little thing" due to its limitations in this context.
0:23 - Demonstration Goal: The aim is to show how to configure a side-to-side VPN between a Fritzbox and an IP464 cloud router, and then analyze packet behavior with Wireshark.
0:46 - Initial Fritzbox State: The Fritzbox is shown connected to DSL with no existing VPN configurations.
0:59 - Cloud Router & Peer Setup: A new IP464 cloud router gateway is configured, defining two WireGuard peers: "Fritzbox" (Peer 1) and "my PC" (Peer 2). Internal IP addresses (e.g., 10.7.0.0/20) and the Fritzbox's local network (192.168.178.0/24) are defined for routing.
2:11 - Routing Table Configuration: A route is added on the cloud router to direct traffic destined for the Fritzbox's local network (192.168.178.0/24) towards the Fritzbox's WireGuard tunnel IP (10.7.0.2).
3:08 - Fritzbox WireGuard Import: The generated WireGuard configuration file is downloaded and imported into the Fritzbox. The Fritzbox successfully connects and acknowledges the remote network (10.7.0.0/20).
4:23 - PC WireGuard Configuration: The PC's WireGuard client is configured as Peer 2, setting its allowed IPs to include the Fritzbox's local network (192.168.178.0/24) to ensure traffic for that network is tunneled.
Pinging the Fritzbox's local LAN IP (192.168.178.1) appears to work, but the reply packet's source IP is observed to be 10.7.0.2 (the Fritzbox's tunnel IP), not the expected 192.168.178.1.
Attempting to access the Fritzbox's web interface via its local LAN IP (192.168.178.1) fails.
9:48 - Wireshark Analysis & Source NAT Explanation: Using Wireshark, the presenter demonstrates that when a TCP SYN packet is sent to 192.168.178.1, the Fritzbox receives it and attempts to reply. However, the Fritzbox performs Source NAT, changing the source IP of the response packet from 192.168.178.1 to 10.7.0.2. The PC's operating system rejects this response because it comes from an unexpected source, thus preventing TCP sessions from establishing, while ICMP (ping) is less strict and still registers a reply.
13:17 - Conclusion and Proposed Solutions: The Fritzbox's unconfigurable Source NAT on VPN tunnel traffic makes it unsuitable for "clean" side-to-side VPNs, particularly for accessing TCP-based services on the remote LAN.
Workaround: Implement Source NAT on the other side of the tunnel (on the PC/cloud router) to match the Fritzbox's behavior (less ideal).
Recommended Solution: Place a dedicated device (e.g., a Raspberry Pi) behind the Fritzbox to handle the WireGuard VPN connection. This dedicated device will route traffic cleanly without unintended SNAT, with the Fritzbox simply forwarding relevant traffic to the Pi via a static route.
15:17 - Final Verdict: The Fritzbox, despite its "jack of all trades" nature, is deemed a "disaster" for specific, advanced networking tasks like proper side-to-side VPNs due to its unconfigurable NAT behavior.