Is this distributed private net over TCP possible?

K

kenw232

n00b
Joined
Nov 28, 2009
Messages
46
Is it possible to create a distributed private network over the internet using Linux? For example you have your typical home router connected to the internet and your devices get private IP's of 192.168.1.x via NAT. Now I simply want the same 192.168.1.x network to also be on the other side of the world. So 192.168.1.5 can ping 192.168.1.6 over the internet. Of course it would have to be tunneled somehow.

See this example image:
network.png
 
Yes, this is very much possible with Linux. I would recommend you look into OpenVPN. This will allow your Linux servers to build VPN tunnels to each other. While you can do this all with a single subnet, I would not recommend it as it will chew up a significant portion of your bandwidth at each site with unnecessary traffic since you are bridging layer 2 across all sites.

I would recommend that each site have different subnets and configure your routing properly to route those other sites to the Linux VPN servers. How much network experience do you have to handle all this?
 
I believe with OpenVPN you can do a special kind of tunnel that is basically like if it was an ethernet cable. Basically it's running at a lower layer. I think it's called a dev tap, while a normal IP tunnel is dev tun. (I might be getting the terms mixed up) so I'd say it's possible.

Keep in mind, if all you want to do is be able to ping/access other clients, you can do that with a normal tunnel too. I don't know the setting off hand but think it's in the config file and just a switch you turn on, but it allows clients to access each other.
 
Thanks for your response. I don't have a lot of experience but was curious. I guess OpenVPN is what I shoud look at then. I'll test it out.
 
Is it straight forward to do this without OpenVPN? what if I wanted to do it manually? It appears OpenVPN is not licensed under the GPL.
 
OpenVPN community edition is GPL. An alternative here is StrongSwan, which you can use to form IPSEC tunnels, but this uses IKE and thus not TCP (although NAT-T can utilize UDP 4500).
 
Last edited:
It may be possible, but it's generally a bad idea to have a single broadcast domain spread over such a long distances and relatively slow links.

What is the application here? It's very rare that such a setup is required. Why do you believe having the same broadcast domain at all three sites is a solution?
 
I wasn't aware of the Community edition. Cool.

There is not confirmed application yet, just theory and some random thoughts I had. But even if a single subnet (192.168.1.x) was spread across a large distance how much extra traffic does that actually generate? Just ARP discovery packets and stuff no? I would think it would be insignificant.
 
ARP would be the majority of it, but it all depends on how many devices are on that subnet and how active the subnet is. If there's only a handful of devices on the subnet, then it isn't that bad if most traffic is unicast. If there is multicast or high broadcast applications running then your bandwidth will get destroyed pretty quickly.
 
ARP is layer 2, so probably wouldn't cross the link regardless. The routers would have to proxy ARP for remote hosts, creating another layer of complexity. But it's hardly the only common broadcast traffic.

What about DHCP? Do you want to deal with servers at each location fighting each other over which is authoritative for the broadcast domain? Or have only a single server that must serve addresses to remote sites? What if the connection between sites goes down, and hosts can't get their proper addresses? Are you going to suffer through setting up everything with static addresses? DHCP alone should disqualify the idea.

There's also mDNS, commonly used for auto-discovery of servers, etc. Probably not a huge bandwidth suck, but the latencies involved with such distances could cause quirks and user confusion.

Many services may have their own broadcast functions that may suffer in such a topology.

Then there's IPv6. It'd be weird for each site to be on the same IPv4 subnet but distinct IPv6 ones.
 
Last edited:
If I setup a typical DHCP server on the 192.168.1.x subnet it would work for all machines correct? And ICMP/ping would work too correct? I'm assuming any IP traffic/service would work as usual and as if it was a local subnet still, just a little slower at times.
 
CAN you do it? Yes
SHOULD you do it? No, VERY MUCH NO. Technical limitations are going to become a huge problem very quickly

Thus far there has been so little detail offered here, that I suspect that this cause is to connect all remote offices together on a single subnet. This is NOT how you should connect remote offices together.

How you SHOULD connect remote offices is that each office should have their own subnet:
Office 1: 192.168.10.x/24
Office 2: 192.168.20.x/24
Office 3: 192.168.30.x/24

On top of that, you should use OpenVPN tunnels on the Linux servers in order to connect the offices together. In tun (tunnel) mode the VPN is running at layer 3, which means that the VPN connections between each linux server should be unique:
Office 1 to Office 2: 192.168.255.0/30
Office 1 to Office 3: 192.168.255.4/30
Office 2 to Office 3: 192.168.255.8/30

You need to ensure that at each office, you have a route for the remote offices directed at the local Linux server and then all communications will work as normal. If this is gettign over your head, you shoudl contract a network engineer to help you out. This is going to take a fair bit of networking know how to get this all to work together.
 
You must log in or register to reply here.
Back
Top