Support accessing resources outside of site subnet / overlapping LANs (e.g. multiple FritzBox Sites)

[mwcp-media]

Summary

Enable defining resources that are reachable via a site connector (primary WireGuard) even if the target IP is outside the declared site subnet.

Motivation

In real-world multi-site setups, especially in home or small-office environments, it is very common that multiple locations use identical LAN subnets (e.g. 192.168.178.0/24, which is the default for FRITZ!Box devices).

While Pangolin sites can be successfully connected (e.g. via WireGuard), it is currently not possible to expose services running inside those LANs unless the target IP is part of the configured site subnet.

This creates a limitation in scenarios where:

the actual LAN subnet differs from the tunnel/subnet used by Pangolin
multiple sites use overlapping or identical LAN ranges
users want to expose existing devices (e.g. NAS) without redesigning their internal networks, which is often not feasible due to existing dependencies or limited control over the network setup

In such cases, adding a resource fails with:

"target ip is not within the site subnet"

This makes Pangolin difficult to use in common homelab and multi-site environments where subnet control is limited or not easily changeable.

Proposed Solution

Introduce a way to define resources relative to the site connector rather than strictly bound to the declared site subnet.

Possible approaches could include:

Allow “external” resource targets per site that are reachable from the site agent (WireGuard peer), regardless of subnet
Introduce an optional “agent-based routing mode” where traffic is forwarded via the site connector instead of relying on subnet validation
Provide a configuration flag to disable or relax the subnet restriction for advanced users
Allow defining resources using logical routing (e.g. via connector identity) instead of strict IP/subnet matching

The key idea is:

👉 If the site connector can reach the target IP, Pangolin should optionally allow it as a valid resource target, even if the IP is outside the declared site subnet, for example by leveraging site-specific routing tables or connector-level routing logic.

This would not replace the current subnet-based model, but extend it for more flexible deployments.

Alternatives Considered

No response

Additional Context

This limitation becomes especially visible in setups with multiple identical home networks (e.g. several FritzBox-based locations), where changing subnets is impractical.

Other tools in this space (e.g. agent- or tunnel-based systems) allow routing traffic via a site-specific connector instead of enforcing strict subnet membership, which makes them more flexible for such environments.

This feature would significantly improve usability for:

homelab users
small distributed setups
environments without full control over internal network design