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. (ext network) —> (ext p2p) <— cable —> (int p2p) <—

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?

  • 1
    You are trying to create an extranet, and you really, really need to be protected by a firewall. Remember that Target got hacked and cost it millions of dollars because a vendor had direct access to its network. You have not vetted the other company's network, employees, and vendors. With overlapping addressing, you can use Outside-Source NAT. See this question and answers about connecting networks with overlapping addressing.
    – Ron Maupin
    Aug 31, 2020 at 13:50
  • Thanks for the reference to Target. That may help me get the point across to management rather than explaining to them in technical terms. I do have an alternate solution to pass the traffic through the firewall but it gets a little messy due to active-passive HA...also the firewall will provide an edge for filtering ports and applications but if the server is compromised and abuses an allowed port/app then we still get hosed.
    – Kev
    Aug 31, 2020 at 18:28
  • Does every host on each side need to address any host on the other side? If they're workstations, then probably not.
    – Criggie
    Aug 31, 2020 at 20:13
  • Yes. so the two /24 subnets are for servers. Then clients on the internal side will be accessing the server. Access filtered by ACLs, firewall, and/or route leaks. The main problem still exists...merging routing domains between two independent Orgs. Aside from security issues since that is more of a politics argument, a routing issue on the external side could hit me on the internal side...the extent of impact would depend on the lockdown and segmentation.
    – Kev
    Aug 31, 2020 at 21:01
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 17, 2020 at 21:26

3 Answers 3


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.


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. :(

  • With the subnets from the question, no NAT is necessary.
    – Zac67
    Aug 31, 2020 at 16:45
  • That's not necessarily true. For example, if the user needs to access vendor resources from various hosts throughout their network, but it is not practical to route through their internal network, NAT is a good alternative. I find it's usually better to employ NAT to isolate one's own private network from any RFC1918-addressed networks outside your own control, rather than wedge vendor-assigned RFC1918 IPs into your network and systems. Not doing so is honestly pretty short-sighted. Aug 31, 2020 at 17:08
  • (Source) NAT doesn't solve any addressing ambiguities - the destination address must be unique to the sender at all times. From that POV, NAT doesn't solve any problem but the back routing one. If network access is bilateral, NAT doesn't have any advantage as all routes need to work.
    – Zac67
    Aug 31, 2020 at 17:19
  • NAT allows isolating vendor-assigned (overlapping) addresses to only one device on your network while allowing access from wherever you designate. Yes, it may be necessary to use both SNAT and DNAT. That's a supported configuration on the firewalls I'm familiar with. It's supported for exactly this type of problem. Cisco and Juniper even have KB articles about it. You can even mix this with VRF on some platforms, if needed, to permit communication among hosts that have overlapping addresses in the different networks. Aug 31, 2020 at 18:24
  • NAT will not be an issue. Overlapping subnets will since I need to use static routes to point the traffic to the external next-hop. If I provision the same subnet, the directly connected subnet will take priority over the static route and traffic will not even make it to the NAT firewall. I also plan on using a VRF but it is still impossible to isolate this as clients will need to access the internal server through route leaks. I did consider public IPs on both sides of the p2p interface to follow better practices but that allows the external side to route out using our ISP circuits.
    – Kev
    Aug 31, 2020 at 18:34

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.