OpenVPN Cloud for a client-to-client(s) connectivity

eoliver

Hi there!

I'm trying to use OpenVPN Cloud to set up client-to-client connectivity, as shown in the figure below.

Currently, I have connectivity between the laptop and the router (on the right side).
However, I'm struggling to connect the laptop and the devices on the far right side.

Can anyone please, point me in the right direction (link, another post, book, etc.)?

Thank you.

openvpn_inc

Hello eoliver,

It's no wonder you are having issues, they're both on the same subnet. The client would try to send the traffic for the remote network, to the local network instead. You seem to be treating this as a bridge connection, where the local and remote networks are tied together. But that has a lot of possible problems, not least of which is DHCP propagating across the link.

What you want ideally is that the network subnet IP ranges on the client side and the remote side are different and not overlapping. Then your computer will know that if you want to reach a computer in the remote network, to send traffic for that particular remote network subnet through the VPN tunnel. And local traffic stays local.

Now, OpenVPN Cloud does actually allow you to connect devices and networks when they have the same IP ranges. There's a trick to addressing the remote network on OpenVPN Cloud using DNS. OpenVPN Cloud by default pushes its own DNS server and you can define a domain in OpenVPN Cloud like "site1.remote" or whatever you want to call that domain. It will only exist in OpenVPN Cloud and will only work for computers connected to OpenVPN Cloud and using the OpenVPN Cloud DNS server. You can enable an option on OpenVPN Cloud called 'allow embedded IP'. What this does is it automatically creates subdomains for every possible IP in the remote network. Like 192-168-0-1.site1.remote and 192-168-0-2.site1.remote. If you ping these, they will resolve to internal IP addresses in OpenVPN Cloud, which then does the necessary network translation internally to the remote side's IP address, outside of view of your client.

So to your client on the left in your diagram to reach a system in the remote network on the right, you can't access it by IP directly (because it will think, hey, that's local traffic, because the subnets are the same on both sides). But you can access it by some DNS record like 192-168-0-1.site1.remote. That then gets resolved by the OpenVPN Cloud DNS server to some IP like 10.100.10.1 or whatever. This avoids the duplicate IP addressing problem I just described, because this is another subnet, and it will be sent through the VPN tunnel to OpenVPN Cloud. OpenVPN Cloud knows that this particular IP is associated with 192.168.0.1 on the remote network and will translate it and send it there. Any responses are translated back. In effect this creates a kind of 'mask' that hides the real remote network's IP range but still lets you access it.

You could even have multiple such sites with same subnet ranges and you can set up different domains for each like site2.remote, site3.remote, or even purpleclown.domaindomaindomain or whatever you like.

So in your situation... option 1 is to change subnet on your remote network so that it is not going to collide with the commonly used 192.168.0.0/22 ranges, like maybe 10.56.0.0/22 or something. Then traffic for the remote site will make it without being confused with the local network. Although there is then still potential for problems due to firewalls and missing routes, but your first problem in your diagram is the overlapping subnets. Or you can consider the embedded IP address option that masks the remote network and makes it possible to have same or overlapping IP ranges used simultaneously in multiple locations, this works around that particular issue with overlapping subnets.

You can find the option to set up such a domain in OpenVPN Cloud web interface under Networks and then click the pencil to edit the remote network, and under Domains add a domain and enable the Allow embedded IP option.

Not saying this is the only thing you need to solve, but this problem at least is the main and obvious one.

Kind regards,
Johan