FRITZ!Box VPN connects but nothing answers: WireGuard or IPSec
A connected FRITZ!Box tunnel that cannot reach the LAN is an addressing problem. Check the four IPSec fields or the WireGuard peer before re-importing.
The tunnel reports connected, the icon is green, and nothing on the home LAN answers. That is the most common FRITZ!Box remote-access complaint, and it is almost never the tunnel itself. The address plan, the subnet identity or the client's route table is wrong. Which of those you end up debugging depends on whether you chose WireGuard or the older IPSec Fernzugang, so start by knowing which one you actually configured.
The tunnel comes up and the LAN stays silent
A tunnel that establishes proves the keys and the endpoint are right. It does not prove the client was given an address the box can route to, or that the client knows which prefixes belong on the tunnel. Those are two separate successes, and only the second one lets you reach a printer.
Check the client's address first, then its route table.
If the assigned address sits outside the LAN subnet, the box has nothing to route back to. If it sits inside the DHCP range, the box may hand the same address to a local device. Both produce a tunnel that connects and a LAN that ignores you.
What each option actually configures
The IPSec option generates a configuration file for one user, containing the pre-shared key and the addressing. You import it into a client that speaks the same profile, which on Windows usually means the vendor tool rather than the built-in client. The WireGuard option generates a peer for one device: a key pair, an address inside the tunnel and an endpoint.
That difference decides your maintenance model. Each WireGuard device is a separate peer with its own key, so revoking a lost phone means deleting one peer while the others keep working. IPSec revokes by changing the shared secret or the user's configuration, which is coarser and affects every device using it.
Neither option is obsolete. The IPSec path stays the supported one wherever the far end cannot run WireGuard.
The IPSec fields that produce a dead tunnel
Four values have to agree with your LAN, and three of them fail in ways that look like a broken tunnel.
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
The network address is the one that catches people. A subnet is identified by its first address, which normally ends in zero, and entering a host address there produces a configuration that looks entirely plausible and never connects. The DHCP range matters for a different reason: tunnel clients are typically assigned above it, so a range that consumes the whole subnet leaves nothing to hand out.
Overlapping subnets are the other classic. If the remote LAN you are joining uses the same prefix as the LAN you are sitting on, routing cannot tell the two apart, and renumbering one side is the only real fix. No amount of client configuration solves it.
Why WireGuard fails differently
WireGuard has no pre-shared key to mistype, so its failures cluster around the peer definition instead. An allowed-IPs list that omits the LAN prefix produces a tunnel carrying nothing, because the client never sends LAN-bound traffic into it. A stale public key on either side produces a handshake that never completes. A missing endpoint or a wrong port produces silence rather than an error.
Compare both sides field by field instead of re-importing the file and hoping.
The one shared failure is the subnet collision. WireGuard will happily build a tunnel to a network that overlaps your local one, and then the routing table decides which of the two identical prefixes wins.
Prove it from outside, then keep a way back in
Test from a mobile connection, never from inside the LAN, because from inside you are testing a path that does not involve the tunnel at all. Record which port each option uses before you enable it, and forward that port to the box.
Keep the generated file somewhere you can reach without the tunnel, and note the box's external name while you are at it.
A configuration that has never been tested from outside is a plan rather than a working remote access path. Test one LAN host by address rather than by name, so a DNS failure does not get mistaken for a routing failure.