How NAT behaves when traffic is rerouted?

[Nikolaos Milas]

Hello,

We have a setup like:

Some subnets at R2 are private and NAT'ed using "ip nat outside" on Int2/1. Int 2/3 and Int 2/4 are using "ip nat inside".

The interface Int2/1 is normally used for traffic from Site 2 (where R2 lies) to ISP (and vice versa).

Question: If we route traffic from/to Site 2 (i.e. R2) to/from ISP so that it goes through R1 instead (i.e. using Int2/5 rather than Int2/1), will the above NAT setup continue to work, since traffic will not pass through Int2/1 where "ip nat outside" is set?

If not, how should we set "ip nat outside" so that it works no matter which the route from/to the ISP is?

Please advise.

Thanks in advance,
Nick

[devils_advocate]

How are your NAT statements setup on each Router?

The source IP is not going to change when the packets go out R2's 2/5 interface so as long as R1 has an ACL which allows the correct subnets to be NATed then it should work fine.

Although you have NAT also setup on R2, this only applies for packets which follow its default route. Any packets which go out Int2/5 can remain 'UnNatted' and the NAT can be applied at R1 before it goes out the route to the ISP.

[Nikolaos Milas]

Thank you,

Your reply clears things out well. I will try setting NAT rules on R1 for R2 private traffic, per your suggestion, and test things out.

I will then report back.

By the way, we also have some IPSec VPNs terminating at Int2/1 ip address ("crypto map vpn" on Int2/1). I think that if traffic is rerouted (through R1) these will break. Would you suggest something to resolve this problem?

Thanks again,
Nick

[Nikolaos Milas]

A clarification: If I set up NAT (for R2 private subnets) at R1, then R2 private subnets will obviously need to use a public address pool available there (different from the pool available at R2). This might complicate things a bit for us.

I am wondering if a solution like the one described here (for scenarios with two ISPs):

http://www.ciscohacks.com/home/general/nat-on-two-outside-interfaces

could also work in our case (even if Int2/5 is a P2P link to our internal network), like:

interface Int2/1
 ip address 1.1.1.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface Int2/5
 ip address 10.10.10.100 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface Int2/3
 description Connection to LAN
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
ip nat inside source route-map NAT1 interface Int2/1 overload
ip nat inside source route-map NAT2 interface Int2/5 overload
!
access-list 101 permit ip 10.1.1.0 0.0.0.255 any
!
route-map NAT1 permit 10
 match ip address 101
 match interface Int2/1
!
route-map NAT1 permit 10
 match ip address 101
 match interface Int2/5

[Nikolaos Milas]

Hmm, now that I am thinking of it again, since the only thing that changes is the route, while the destination remains the same, it should be enough to simply configure both Int2/1 and Int2/5 with "ip nat outside"!

Isn't it so?

For example, a config should be like the following:

Say that Int2/2 connects network: 10.20.10.0/24, Int2/3 connects network: 10.1.1.0/24 and Int2/4 network: 10.20.12.0/24. Then, to NAT Int2/3 network, we should:

access-list 120 permit ip 10.1.1.0 0.0.0.255 any

route-map InternaltoInternet permit 10
 match ip address 120
!

ip nat pool ovrld 2.2.2.2 2.2.2.2 prefix-length 24

ip nat inside source route-map InternaltoInternet pool ovrld overload

Interface 2/3
 ...
 ip nat inside
 ...

Interface 2/1
 ...
 ip nat outside
 ...

Interface 2/5
 ...
 ip nat outside
 ...

Nick