I have (3)local machines (192.168.1.200, 192.168.1.200, 192.168.1.202).

I also have (2) remote machines (123.456.123.456, 456.123.456.123)

What can I do to allow them to be (or appear to be) on a single subnet?

Reason why: I am messing around with BACnet which uses APD and requires special configuration to use multiple subnets which I don't wish to do right now.

First off, fix the duplicated ip, tho I am assuming that was more a C&P error .

Anyways, you'd want a tunnel of some kind to like em, like a VPN. The easiest method is to have a site-to-site VPN linking the two routers/gateways on both sides but that usually does depend on both sides having a static public IP. Do you have a static public IP on both sides and a router/gateway capable of VPNing? That'd be the solution I'd suggest.

OpenVPN can be used like that. You can also set up a fairly simple VPN like that using OpenSSH.

Functionally, OpenVPN acts like a router, which is what you need here.

In fact, if you do not need for the connection to be secure, you might be able to set this up using a "static route" in your existing home router.

Each subnet needs to have a distinct range of private network addresses. Then, the router (software or hardware) is set up to act as a "gateway" between them. Traffic is forwarded to the router (or OpenVPN) on your local network, and thence it is forwarded to the counterpart router in the other network. Corresponding routing options must be set up on both ends so that packets can successfully navigate a round trip.

Thanks r3sistance. Yes, a typo! Yes, I have a static IP for the two remote servers, and a static IP for my Comcast modem. My home router is a Asus RT-AC68U and a quick google indicates that it probably supports VPN, but I have never tried. The remote servers are VPS's provided by a host, and since I can directly reach them, expect I could use software to support that side (then are both Centos 6.X).

Thanks Turbocapitalist. So maybe OpenVPN or OpenSSH on the remote servers only, right? Could they also be on the local side and not attempt to use the Asus RT-AC68U to implement?

Thanks sundialsvcs. Same question regarding OpenVPN. I do not need any secure routing downstream of my home router. The network is rather small, and consists of within my LAN 3 Linux boxes, 3 PCs (not involved), and a couple of televisions (not involved), and the two remote Linux servers which both have static IPs.

For the OpenSSH-based VPN you'd need root on both machines but only the SSH client on the one you are connecting from. Obviously the SSH server would be on the one you are connecting to. The basic instructions are towards the end of the manual page for the client.

Initially, you'll need some kind of remote root access via keys. However, that can be locked down increasingly once you have the details worked out. I think that even in this case you could eventually work things out with a non-root user and use of sudo

For the OpenVPN-based VPN, I'll defer to others here.

I would say that it maybe best to check if your host has a preferred method for VPNs, if you are getting any kind of managed level support then they may already have guides or methods on how to create VPNs for services hosted on their particular infrastructure.

If you do not require security between the two subnets, then you just need two routers and a little bit of setup on both of them. Which you can probably do with their off-the-shelf administrative interface.

Let's call the router that serves the Internet to your home, "router #1," and let's assume that it lives at 192.168.0.1 as routers customarily do.

Purchase a "router #2" for the other subnet, and plug it into router #1. Cause router #1 to give it a fixed IP-address based on its MAC number. Let's say that router #2 will live at 192.168.0.250. (To clarify: let router #2 obtain its network-side IP address via DHCP as it customarily does, and cause router #1 ... which is the DHCP server that it will be talking to ... to always hand it a known, fixed address that belongs to router #1's subnet.)

Now, on each router, you build static-route definitions that describe the "other" subnet, and which specify the "other" router's (known) address as the "gateway" that leads to it.

Also be certain that router #2 doles out IP-addresses to its clients (with its built-in DHCP server) which are "non-routable addresses" that do not conflict with those of router #1's private subnet, and vice-versa. Routing decisions are based on the value of the IP-address in each packet. The address-ranges in every subnet must be distinct, because IP-addresses in both ranges will likely appear on both subnets.

For simplicity, each of the machines in each subnet will do what they always do: they'll toss everything up to their "default route," which leads to their router. Each of these routers now knows about the other subnet, and how to route traffic to it in both directions: anything destined for the other side will be sent to the other router, "as a gateway," and delivered to its destination by it. This avoids the need for individual routing-configuration or awareness on their part as to exactly how the packets get to where they're going.

Q. E. D.

You would need to use OpenVPN (I wouldn't even bother with OpenSSH ...) only if you require a secure link, which you say that you do not. But the routing concepts remain essentially the same, because OpenVPN (in "tunnel mode") is, fundamentally, "a router."

traceroute, and a packet-sniffer such as tcpdump or WireShark, will be the fundamental tools that you will use as you figure it all out.