overlapping subnets in virtual router and NAT

[faizankhurshid]

Hi

I have two virtual routers say customer-1 and customer-2 having subnets 10.10.10.0/24 (overlapping subnet). Now internet connection line is on eth1/1 which is in default virtual router. Both customer-1 and customer-2 needs to access the internet but I am wondering how source NAT will work in this case?

Also for reverse traffic for 10.10.10.0/24 subnet in default route will work?

Thanks

[faizankhurshid]

@reaper your comments please

[reaper]

in your scenario the ideal solution would be to have eacht VR connected to the ISP independently, this will prevent collisions with your duplicate IP subnets

[pulukas · Accepted solution]

I would setup NAT from one to a non-overlapping subnet on egress from the VR into the ISP VR.

This will give everything a unique address from the ISP VR perspective and return the traffic to the correct sources.

[faizankhurshid]

Thanks @reaper @pulukas for your comments 

[chtoh82]

Hi, sorry to bring this thread up as I happened to came across  when searching for a solution to my issue. 

So, I have a setup as below, I'm having 2 VSYS with overlapping subnet (Network A and B) in the trust interface, however, I also added secondary subnets in that same interface, however, this time, the secondary subnets are non overlapping. 

What I did next was, from each VSYS A and VSYS B,  configured Source NAT from Trust to External Zone, translated IP as the secondary subnet interface IP (ie 192.168.3.1 and 192.168.4.1 for VSYS A and B respectively), to reach out to a server in the untrust subnet located in the Main VSYS.

I also have routing configured respectively, as you can see from the diagram, however, I could not reach to the untrust subnet from both VSYS A and B. 

Session browser showed connected sessions from both VSYS A and B trust zones to the Main VSYS untrust zones, with correct source and destination addresses with NAT-ed IP as well.

The following counter global were observed:

Session setup: no destination zone from forwarding

Packets dropped: no route

These counters indicated there there were no routing or routing was incorrect, however, fib route lookup from both VSYS A and B to Main VSYS  to destination in untrust zone in main VSYS was successful.  Route lookup from Main VSYS to VSYS A and B to destination of Source NAT-ed IP (192.168.3.1 and 4.1) was successful as well.

Therefore, could anyone verified if SourceNAT is supported in such intervsys routing design?