LAN access through VPN with IP collision

[mickgotwings]

Hello there!

I've got a wireguard VPN set up on my opnsense machine, which I use to access my LAN remotely. Everything works fine unless there's a subnet collision. I wonder, if there's a way around this problem.

Say, I'm at my friend's house and connected to their WiFi. Their LAN subnet is 192.168.1.1/24.
My home LAN subnet is also 192.168.1.1/24.
Now, when I connect to my VPN I can't really access a machine on my LAN at 192.168.1.123, because that IP is taken on my friend's subnet.

Is there any workaround? Obviously, I won't be able to use 192.168.1.123 in this situation.

I could use port forwarding as a temporary solution, but it requires adding every single LAN IP manually. Also, it just intuitively seems wrong to do so.

Maybe I could use a virtual subnet to route e.g. 10.0.1.* to 192.168.1.* on my LAN, but I have no idea on how to achieve this.

That's why I'm here asking for help, please guide me

P.S. I'm no expert and I'm willing to learn, so any comments on what I might be doing wrong and what I should read first are highly appreciated.

[Monviech (Cedrik)]

Depending on the size of your LAN, you could just change your IP Range of it to something like 10.134.55.0/24. Going into the 10.0.0.0/8 range will have a very small chance to get into collissions with other "normal" home networks.

Another way would be to implement IPv6. If you already have Global Unicast Addresses, they're Globally Unique and there can't be any collissions by design. Implementing that into your Wireguard Tunnel would allow you to reach all of your devices everywhere.

If not, another way would be to implement IPv6 ULAs into your Wireguard tunnel to have a dual stack Tunnel. Then you can reach your devices with either their IPv6 ULAs, or their IPv4 addresses.

[mickgotwings]

Monviech, thank you for this!

Depending on the size of your LAN, you could just change your IP Range of it to something like 10.134.55.0/24. Going into the 10.0.0.0/8 range will have a very small chance to get into collissions with other "normal" home networks.

I have considered it. However, it'd be quite a hassle to do so, since I have a few IPs hard coded in a number of config files (should've used local DNS in the first place, am I right).

Another way would be to implement IPv6. If you already have Global Unicast Addresses, they're Globally Unique and there can't be any collissions by design. Implementing that into your Wireguard Tunnel would allow you to reach all of your devices everywhere.

If not, another way would be to implement IPv6 ULAs into your Wireguard tunnel to have a dual stack Tunnel. Then you can reach your devices with either their IPv6 ULAs, or their IPv4 addresses.

I don't think I understand your point here. The machine I'm trying to access only has an IPv4 address, so I don't see how implementing IPv6 in my tunnel would help here. Could you please elaborate on this?

[Patrick M. Hausen]

Since you control your LAN you could implement IPv6 for the LAN and the VPN tunnel, even if the mobile endpoint has got only an IPv4 uplink.

[mickgotwings]

I don't think I understand your point here. The machine I'm trying to access only has an IPv4 address, so I don't see how implementing IPv6 in my tunnel would help here. Could you please elaborate on this?

After some digging, I understand how stupid my question really was, and I just want to confirm it here

For future readers with similar to mine understanding of ipv6 prior to this post (which was little to none): a ULA is essentially a private range for your subnet. Its usage is highly situational and usually discouraged, which is why, from my understanding, people rarely talk about it.

Since my ISP does not support ipv6, the only option I am left with is to implement ULAs in my tunnel.

Thank you for the help!
I'll report my journey with implementing ULAs here to hopefully help someone with a similar problem in the future.

[bimbar]

You should be aware that IPv4 is prioritized over IPv6 ULA, rendering them mostly useless (apart from a few very specific use cases such as thread).

[Burak]

Obviously your VPN client does not forward local addresses through the tunnel.
It is quite impractical to constantly change your home LAN subnet based on the subnet of the remote location you are connecting from. (Imagine travelling, airport, cafe, hotel) You'll get a collision some time.
Also it is a bit over the top to implement IPv6 just for this.

The simple solution is to tell your VPN client to forward all traffic through the VPN tunnel, not just traffic for your home LAN. So even when you are on some 192.168.1.0/24 network (while your home subnet is also 192.168.1.0/24) you will always be able to reach your home appliances with the tunnel.

[mickgotwings]

Obviously your VPN client does not forward local addresses through the tunnel.

That's what I thought at first.
However, this should not be the case, since my wireguard "client" config clearly states to route everything through the tunnel.

Code: [Select]

[Interface]
PrivateKey = REDACTED
Address = 10.0.0.4/32
DNS = 10.0.0.1

[Peer]
PublicKey = REDACTED
PresharedKey = REDACTED
AllowedIPs = 0.0.0.0/0
Endpoint = REDACTED
PersistentKeepalive = 10

The only thing I can think of to break this behavior is some iOS shenanigans.

[bimbar]

Usually the more specific route wins, so your friend's local 192.168.1.0/24 wins over 0.0.0.0/0. If it did not do that, you would not be able to reach your nexthop.