overlapping subnets in virtual router and NAT

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

overlapping subnets in virtual router and NAT

L3 Networker

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

1 accepted solution

Accepted Solutions

L7 Applicator

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.

 

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

View solution in original post

11 REPLIES 11

Cyber Elite
Cyber Elite

overlapping subnets on different VR will not interfere unless you need them to converge, at which time you will get a conflict

 

a solution to this situation could be to implement separate VSYS (rather than just separating VR) and enabling the 'shared gateway' feature which automatically provides for this sort of situation

 

Alternatively you can look into using PBF with symmetric return which will keep track of the original source when forwarding packets, and returns the packets to the proper origin

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Thanks for the reply.

 

For shared gateway solution, if traffic is initiated from 10.10.10.10 from VR1 (which is in VSYS1) and at the same time 10.10.10.10 from VR2 (which is in VSYS2) to internet through shared gateway (where source NAT is happening) then how I can define the reverse route for 10.10.10.0/24 in shared gateway?

 

 

I'm starting to think you will still need PBF, so simply implementing pbf will be your best shot without complicating things

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Thanks for reply @reaper for destination NAT in shared gateway, say public IP 100.100.100.100 into 10.10.10.10 then again problem is after getting NAT, in which VSYS traffic will go?

 

Some vendor like Juniper implement this using routing instance (virtual router) aware NAT that associate the public IP to virtual router, mean after destination NAT in which routing instance routelookup wil happen for policy lookup and forwarding. 

 

https://forums.juniper.net/t5/SRX-Services-Gateway/Overlapping-address-ranges-virtual-routers-and-NA...

 

Is there any feature in Palo Alto to support this? As it is very important for multi-tenant (customers) enviornemnt where customer can share same private subnets. 

@reaper your comments please

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

L7 Applicator

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.

 

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

Thanks @reaper @pulukas for your comments 

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?

 

Screenshot 2020-03-25 at 3.38.03 PM.png

Pulukas, do you have any examples of how to set this up?  This scenario is exactly what I am trying to do, but having issues with the NAT statements needed to accomplish this.  If I create a NAT policy to change source IPs to a non-overlapping subnet, then my outbound NAT rule doesn't seem to work.  Seems like I can only get one or the other to work, not both.  Thanks.

I have the same case. Is there a solution?

  • 1 accepted solution
  • 15124 Views
  • 11 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!