creating proper vpn tunnel, when both LANs have the same addressing

I was following this tutorial http://wiki.debian.org/OpenVPN#TLS-enabled_VPN and this one http://users.telenet.be/mydotcom/howto/linux/openvpn.htm to create openvpn connection to my remote LAN.

But both examples assumed that both LANs have different addresses (ie 192.168.10.0/24 and 192.168.20.0/24, check out this image i.stack.imgur.com/2eUSm.png).

Unfortunately in my case both local and remote lan have 192.168.1.0/24 addresses. I am able to connect directly on the openvpn server (I can ping it and log in with ssh), but I can't see other devices on the remote LAN (not mentioning accessing them via browser which was the point from the first place). And don't know if the addressing issue may be the reason of that? If not - how to define routes, so I could ping other devices in remote LAN?

Solution 1:

You're sunk. All the machines are using the same subnet. How do you propose they would be able to distinguish local from remote hosts? Your only option here would perhaps be some form or port forwarding from the VPN hosts at each site. This would work for a few services, but would be a nightmare to support long term.

You really just need to bite the bullet and re-number one of the sites.

My guess is that you don't have a good grasp on some core networking fundamentals. I'd highly recommend you read though this Serverfault Q&A on IPv4 subnetting. That will help you better understand the why behind your present difficulties.

Solution 2:

Even if this question is already answered, here is another option:

• Assign a secondary IP in a free subnet to the gateway on one side
• Use the NETMAP target in iptables to translate everything

If you choose 192.168.2.0/24 as alternative subnet on one side, you could use this rule to translate the Network:

iptables -t nat -A POSTROUTING -o tap0 -j NETMAP --to 192.168.2.0/24

Solution 3:

In my opinion, NETMAP is actually a pretty valid way of making sure that networks won't collide. Many routers use the same private address space and sometimes there's just no way of changing a setup for a network you don't own (e.g. in an internet café, public WLAN). Yes, you could change your own network to use a rather uncommon address space, but some providers distribute locked-down equipment with no way of changing that, which would require you to add more network gear. Oh, and sometimes it's just very convenient to type 10.0.0.x instead of e.g. 192.168.214.x.

TL;DR: While not advisable in professional setups, NETMAP might come in handy.

Here's an example that allows me to use 10.0.0.x on both sides and still connect via OpenVPN. Instead of pushing the real route to clients, you use an uncommon subnet:

OpenVPN

push "route 10.11.12.0 255.255.255.0"

NETMAP

iptables -t nat -A PREROUTING -d 10.11.12.0/24 -j NETMAP --to 10.0.0.0/24

Source NAT (assuming you're using OpenVPN's default 10.8.0.0/24 subnet)

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth1 -j SNAT --to-source PUBLICIP

This works pretty well, even with default gateway replacement. It might get messy if you're using your own DNS:

push "dhcp-option DNS 10.11.12.1"

That's because though you'll be able to reach the DNS server (which is on 10.0.0.1), it returns addresses based on it's subnet, not the NETMAPed one. There might be ways around that. I'm thinking of BIND's views, e.g., no idea whether Samba is capable of something like that.