Overlapping IP Address Space

We'll use NAT and a few routing tricks to remedy a situation where two disparate subnets are using the same IP address space, 192.168.1.0/24.

Most examples that run through a problem like this seem to go through an example where the two networks wit overlapping address space are directly connected to the same router/firewall/NAT device. This will step through a couple of ways to solve the problem where there is actually a network in between the two address conflicting subnets.

Here we have three flow based routers, SRX devices. SRX-11 has an interface using the 192.168.1.0/24 network, where the Client device lives. The Client device is simulating several hosts by using addresses 192.168.1.80 through 192.168.1.89. From SRX-11's perspective, the Client LAN is in the TRUST security zone. Likewise on the other side of the network, there is a similar device names SRX-13 that also has an interface in a separate 192.168.1.0/24 network, where the Server device is connected. The Server is also simulating several hosts by using addresses 192.168.1.80 through 192.168.1.89. From SRX-13's perspective, the Server LAN is in the TRUST security zone.

SRX-12 provides network connectivity to SRX-11 and SRX-13, forming the backbone of our small network. From both SRX-11 and SRX-13's point of view, their interfaces connected to SRX-12 are in the UNTRUST security zone. SRX-12 is quite permissive, and does not block any traffic. SRX-11 and SRX-12 are also quite open, and have a default policy of "permit" and no further security policies -- so all traffic can pass through them more or less unhindered.

The SRX devices all run IS-IS SRX-12 provides network connectivity to SRX-11 and SRX-13, forming the backbone of our small network. From both SRX-11 and SRX-13's point of view, their interfaces connected to SRX-12 are in the UNTRUST security zone. SRX-12 is quite permissive, and does not block any traffic. SRX-11 and SRX-12 are also quite open, and have a default policy of "permit" and no further security policies -- so all traffic can pass through them more or less unhindered.

Security Policy on all SRXs

[edit security policies]
juniper@SRX{11-13}# show 
default-policy {
    permit-all;
}

[edit security policies]
juniper@SRX{11-13}# 

The SRX devices all run IS-IS.

IP Address Mappings

In order to allow the two networks with the 192.168.1.0/24 address space assigned to them, we need to map some unique address space to each site, and then NAT all of the traffic destined to, and from this unique address space. The mappings we'll use are as follows:

Client: 192.168.1.0/24 => 192.168.81.0/24

Server: 192.168.1.0/24 => 192.168.80.0/24

So, from the perspective of the client, we will reach the Server with 192.168.80.0/24 addresses, and from the Perspective of the Server we'll be able to reach the client if we try to connect to the 192.168.81.0/24. We'll use static NAT twice to enforce these mappings -- also known as Double NAT.

We'll do some quick and ugly routing, just to get our network to a point where we can see some traffic flowing. This will be far from optimal, and we'll clean it up later on. In SRX-12, we point 192.168.81.0/24 towards SRX-11 to take care of client traffic, we'll tag it for easy identification with export policy.

Static Routes for NAT'ed IP blocks for client space SRX-13

[edit routing-options]
juniper@SRX-12# show 
static {
    route 192.168.81.0/24 {
        next-hop 172.18.1.11;
        tag 6009;
    }
}

[edit routing-options]
juniper@SRX-12# 

We'll then point 192.168.80.0/24 traffic towards SRX-13 to take car of the server traffic, again with a handy tag.

Static Routes for NAT'ed IP blocks on SRX-13

[edit routing-options]
juniper@SRX-12# show 
static {
    route 192.168.80.0/24 {
        next-hop 172.18.2.13;
        tag 6009;
    }
    route 192.168.81.0/24 {
        next-hop 172.18.1.11;
        tag 6009;
    }
}

[edit routing-options]
juniper@SRX-12# 

We'll setup a quick policy to export these tagged static routes.

Policy to match static routes with a tag of 6009

[edit policy-options]
juniper@SRX-12# show 
policy-statement STATIC-6009 {
    from {
        protocol static;
        tag 6009;
    }
    then accept;
}

[edit policy-options]
juniper@SRX-12# 

And then apply this an an export policy in the IS-IS protocol.

STATIC-6009 used as an IS-IS export policy

[edit protocols isis]
juniper@SRX-12# show 
export STATIC-6009;
level 2 disable;
interface ge-0/0/4.0;
interface ge-0/0/5.0;
interface lo0.0 {
    passive;
}

[edit protocols isis]
juniper@SRX-12# 

And then we'll check that the routes are being advertised out and our export policy is working as expected.

IS-IS database on SRX-12

[edit protocols isis]
juniper@SRX-12# run show isis database detail SRX-12.00-00 
IS-IS level 1 link-state database:

SRX-12.00-00 Sequence: 0xc, Checksum: 0x9629, Lifetime: 1194 secs
   IS neighbor: SRX-12.02                     Metric:       10
   IS neighbor: SRX13.02                      Metric:       10
   IP prefix: 172.18.1.0/24                   Metric:       10 Internal Up
   IP prefix: 172.18.2.0/24                   Metric:       10 Internal Up
   IP prefix: 192.168.80.0/24                 Metric:        0 External Up
   IP prefix: 192.168.81.0/24                 Metric:        0 External Up

IS-IS level 2 link-state database:

[edit protocols isis]
juniper@SRX-12# 

This is a really unscalable, inefficient, and method that is subject to problems if there are multiple paths. This is just a placeholder to see that our NAT policies are working properly. We'll repair the routing later, shifting the responsibility of advertising the mapped subnets to the network device that is doing the NAT operations for that mapped network.