Problem: Überlappende IP-Netze bei VPNs
Wenn
B und
C zufällig
dasselbe LAN-Netz verwenden (z. B. beide 192.168.178.0/24, was bei -Boxen Standard ist), passiert Folgendes:
- Sobald beide per VPN an A angebunden sind,
weiß A nicht, an welches VPN-Peer es Pakete für 192.168.178.x senden soll.
- Das Routing bricht zusammen, weil überlappende Netze nicht unterscheidbar sind.
Und: Weder die eingebaute -Implementierung noch können auf der Fritzbox „NAT auf Subnetze“ machen — zumindest nicht out of the box.
Lösungen / Workarounds
Du hast drei Optionen, je nach Aufwand:
Beste Lösung: Netz anpassen (wenn irgendwie möglich)
Wenn du doch irgendwie Zugriff auf die Fritzbox-Oberfläche von B und/oder C bekommst:
- Box B: z. B. 192.168.2.0/24
- Box C: z. B. 192.168.3.0/24
dann funktioniert alles wie in meiner ersten Anleitung ohne Tricks.
Das ist
technisch die sauberste und stabilste Variante.
Alternative: VPN-Tunnel mit NAT (Masquerading)
Falls du
die LAN-Netze von B und C nicht ändern kannst, kannst du auf
A mit und eine Art NAT-Router für die VPN-Tunnel bauen.
Beispiel:
- B bleibt bei 192.168.178.0/24,
- C auch 192.168.178.0/24
- Auf A wird aber der Traffic aus B beim Eintreten ins VPN auf ein fiktives Netz z. B. 10.10.2.0/24 genattet
- Traffic aus C wird auf 10.10.3.0/24 genattet
Damit sehen sich die Netze auf A plötzlich als verschieden:
# Beispiel für B (IPSec-Tunnel)
iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o ipsec0 -j NETMAP --to 10.10.2.0/24 # Beispiel für C (WireGuard-Tunnel) iptables -t nat -A POSTROUTING -s 192.168.178.0/24 -o wg0 -j NETMAP --to 10.10.3.0/24
- Dann schreibst du Routing- und Firewallregeln gegen 10.10.2.0/24 und 10.10.3.0/24.
- Für die Geräte hinter B und C sieht alles normal aus, aber A sieht sie unter unterschiedlichen Netzen.
Hinweis: NETMAP ist ein spezielles Target von , das genau für so etwas gemacht ist. Falls es nicht verfügbar ist, ginge auch SNAT/MASQUERADE, allerdings verlierst du dann die Quell-IP der einzelnen Geräte.