FRITZ!Box LAN-LAN VPN: Why Your Device Gets No Remote IP
In a LAN-LAN VPN the networks are joined and devices keep their own addresses. A dial-in connection is what assigns an address from the remote pool.
A laptop connects to a FRITZ!Box VPN, reaches a file share at the other site, and still shows its home address in every tool you try. People then hunt for a setting that hands out a remote IP and never find one, because there is nothing to find. In a LAN-LAN coupling two routers join their networks and each device keeps the address it already had. Only a dial-in connection leases an address out of the remote pool.
The rest of this is about telling those two arrangements apart, and about what the far side actually sees.
One coupling joins networks, the other lends an address
A LAN-LAN link is a route between two subnets, not a remote desk. Your laptop sends a packet to 192.168.188.40, the FRITZ!Box recognises that destination as reachable over the tunnel, and the packet arrives with your original source address intact. Nothing in that path needs a second address, and nothing assigns one.
A dial-in profile behaves like a remote extension of the router. The connecting device is given an address from the target LAN, which is why it appears in the lease table there. Same tunnel, different question: one design extends a network, the other admits a guest into it.
| Arrangement | Which device asks | Address the device keeps | What the far site sees |
|---|---|---|---|
| LAN-LAN coupling | any host behind either router | its own local address, unchanged | an address from your subnet, or the router address if the link translates |
| Dial-in profile | the single device that connects | a lease from the remote pool | an address inside the remote LAN |
What the far host sees depends on translation
With plain routing the remote machine records your real local address, for example 192.168.178.20, and its own reply has to travel back through the tunnel. That reply only works when the remote router holds a route for your whole subnet, which the coupling normally installs for you.
If the link rewrites source addresses instead, the remote host sees one address for everything behind the tunnel: the router's own LAN address. Both designs are legitimate, and both make the question what is my IP answerable in a way that has nothing to do with the VPN being up.
You can settle it in a minute without guessing. Open a connection table or an access log on a machine at the other site while a request is in flight, then read the source column. An address that belongs to the sending subnet means routing is in place; a single repeated router address means the link is translating. Write the result into your notes, because it determines whether remote access rules must allow a subnet or one host.
Where those values live in FRITZ!OS
On a current FRITZ!OS release the wizard sits under Internet, then Freigaben, then VPN, behind the button for a new connection. The first choice is the shape you want: a FRITZ!Box joined to another FRITZ!Box, or a single computer dialling in.
- Pick the two-router option and continue.
- On the following Netzwerkeinstellungen page, name the remote IPv4 network, for example 192.168.188.0/24, and set the shared VPN key.
- Finish the wizard, then import the configuration file it offers on the other FRITZ!Box.
The remote network field is the one that matters for this symptom. It tells the router which destinations belong on the far side of the tunnel; the key only decides whether the tunnel comes up at all. A wrong network there produces silence, not an address.
When the far side insists on a remote identity
Some services are written to accept only clients whose address falls inside their own subnet, and no amount of routing will satisfy them. That is a policy on their side, and the fix is a different connection type rather than another tunnel setting.
Add a dial-in profile for that one device and leave the coupling in place for everything else. The device then leases an address from the remote pool and appears in the remote router's connection list, which is exactly what the service wants to see. Two profiles can coexist on one router, provided each has its own shared key and its own network entry.
Run these checks in order
Before changing modes, confirm the basics, because a coupling that never worked looks identical to one that works correctly.
- Compare the two LAN prefixes. A coupling between two networks that both use 192.168.178.0/24 cannot route, and the fix is to renumber one side.
- On each router, read the VPN overview and confirm the remote network appears as connected.
- From a host at the far site, request the service and read the source address it logs. This is the observation that answers the original question.
Test from a client, never from the router's own ping page: the router can reach destinations through paths its LAN hosts cannot use, so a successful ping there proves nothing about the device.
If both directions work and the device still shows its home address, the coupling is doing its job. Reach for a dial-in profile only when a remote identity is genuinely required, and keep the two arrangements documented next to the subnet plan.