Routing between completely separate private networks

Question

I’ve got a request from a partner vendor in a completely separate routing domain to directly route a /24 rfc1918 network on my rfc1918 internal network. The proposed solution has their handoff directly connected to our router with static routes with next-hop on my router pointing to the vendor router.

192.168.1.0 (ext network) —> 10.1.1.1/30 (ext p2p) <— cable —> 10.1.1.2/30 (int p2p) <—192.168.2.0/24

At first glance, this sets off a bunch of red flags with bad practice merging two private networks of two completely separate orgs. Realistically, it will work as long as we keep track of the overlapping subnet on the vendors network to make sure we don’t provision the same subnet on our network. I know there is a certain level of trust needed from the external network to not route a ton of traffic my way but hope to at least use an ACL to allow only expected subnets through the p2p interface.

So I was wondering if anybody has scenarios or issues I am overlooking with this setup?

Answer 1

You need to work out and put in writing the security definitions (=what connections are allowed - anything else isn't) and the other formalities (average/maximum bandwidth, QoS, availability, ...). Make the security definitions rough (subnet A <-> subnet B etc) and rigid, and let the connecting parties handle the details (host-based or port-based filtering).

From the network side, that shouldn't be a big problem, especially when there's no overlap (that we can see). Of course, you need to filter out any traffic but the permitted.

Answer 2

A few more concerns are:

1. Are the protocols you intend to use across this connection all compatible with your available equipment's NAT implementation? If so, this really makes things easier on you in the long term. You can just create an isolated NAT pool with any addresses the vendor wants, without having to route that pool inside your network.

2. Which of your IP addresses are able to access resources on the vendor's network? Are they essentially creating a VRF and NAT pool on their side, so they can allow any customer like you to access their RFC1918-addressed resource from customer's RFC1918 hosts?

3. If you prefer to use public addresses on your side, is this allowable? If not, does the vendor really have an infosec & network team?

4. Is the vendor willing to use public addresses on their end?

5. sigh IPv6 has been around for better than twenty years and we're still doing stuff like this. :(

Answer 3

Technically adding another bogon network adjacent in address space is as simple as a static route. Technically this is the simplest valid solution.

Some things you might want to consider.

1. Is the /24 at each site big enough? When you do exceed the IP space where do you intend on adding additional addresses?

2. Is there a pressing reason to have a full /24 netblock routed? Typically a firewall would be used providing a select range of IPs and services between sites. This is not exclusively for security. Many protocols can use broadcast and scan adjacent networks (SMB). This will cause all machines participating to now send additional unicast across this network link frequently resulting in slow "discovery" events.

3. In general I have replaced all 192 networks in corporations in favor of 10 nets. This has the advantage of having a unified IP space so you can provide any/any routing without requiring complex NAT. In addition when you do add logging it will be easier to identify the location and device by its prefix. Typically the WIFI and LAN IP spaces are unique allowing for easier segmentation by firewalls and identification in logs. In a home network they are the same to allow for simplicity and auto discovery protocols.

4. You mentioned static routing. You might want to look into OSPF or RIP. In this scenario you might not need it but once you have some experience and some areas defined it will allow for easier future growth. Consider the scenarios of redundant network paths (dual homed internet) or multiple VPNs.