02-10-2018 12:32 AM
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?
02-17-2018 07:06 AM
02-19-2018 02:54 AM
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
02-19-2018 03:16 AM
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.
02-19-2018 10:17 AM
03-25-2020 12:53 AM - edited 03-25-2020 12:54 AM
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?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!