NAT in stick

[snarayanaraju]

Hi Experts,

I am configuring NAT in stick configuration. I am not comfortable with the logic behind this. Also,I have completely gone thru the CISCO document describing the NAT in stick configuration. Still i donot understand

Below I am explaining the issue

Please find the attached Topology diagram and configuration. Please correct the what i am missing in the configuration.

1. I am not able to ping 61.1.192.65 (INTERNET Router) IP address from PC Router.

2. What is the need of PBR configuration here.

3. In what logic i have to make the interface as INSIDE or OUTSIDE. (Since in this case we are configuring public ip address and private ip address in the same eth 0/0 interface and creating loopback 0 interface)

I believe i have explained the need to your understanding. Please help

Thanks in advance

Sairam

[Marwan ALshawi]

use the follwoing config and should work

yours was ok but you had extra entry in the ACL of route-map

interface Loopback0

ip address 1.1.1.1 255.255.255.0

ip nat inside

ip virtual-reassembly

!

interface FastEthernet0/0

no ip address

shutdown

duplex half

!

interface FastEthernet1/0

ip address 218.248.17.2 255.255.255.0 secondary

ip address 192.168.1.254 255.255.255.0

ip nat outside

ip virtual-reassembly

ip policy route-map nat

duplex auto

speed auto

!

interface FastEthernet1/1

no ip address

shutdown

duplex auto

speed auto

!

ip route 0.0.0.0 0.0.0.0 218.248.17.1

!

no ip http server

no ip http secure-server

!

ip nat pool pool1 218.248.17.11 218.248.17.12 netmask 255.255.255.0

ip nat inside source list 1 pool pool1

!

access-list 1 permit 192.168.1.0 0.0.0.255

access-list 100 permit ip 192.168.1.0 0.0.0.255 any

!

route-map nat permit 10

match ip address 100

set interface Loopback0

this a copy of the debug i did it in gns3 lab:

NAT: s=192.168.1.1->218.248.17.12, d=61.1.192.65 [22]

NAT*: o: icmp (61.1.192.65, 4) -> (218.248.17.12, 4) [20]

NAT*: s=61.1.192.65, d=218.248.17.12->192.168.1.1 [20]

NAT*: o: icmp (61.1.192.65, 4) -> (218.248.17.12, 4) [21]

NAT*: s=61.1.192.65, d=218.248.17.12->192.168.1.1 [21]

NAT: i: icmp (192.168.1.1, 4) -> (61.1.192.65, 4) [23]

good luck

HTH

[snarayanaraju]

Hi HTH,

Thanks for responding. I will try your suggestion. By the mean time can you please explain the logic behind using the PBR in this scenario. Let me put my question in simpler way

1. What happens when in the packet 192.168.1.1 (inside host) enters the router interface fa 1/0.

As per router inside to outside traffic flow logic first policy route-map will be checked and then routing table and finally NAT will be used.

2. when the return packet comes back to router first NAT translation will be checked and if translation is found then it will route the packet directly to fa 1/0.

Am i correct. If this is the case see the attachment of a file describing "NAT ON STICK ROUTER CONFIGURATION". In Example configuration on page 4 they have the below ACL used for route-map.

access-list 102 permit ip 10.0.0.0 0.0.0.255 any

If i remove this from configuration, the setup stopped working. It seems it is mandatory ACL for return traffic

Correlating the point 1 and 2 i explained above, i don't know why this ACL has to be included and what it does.

I know that i explained very lengthy which would have tested you patience. But i tried to give detailed info.

Please explain the logic

Sairam

[snarayanaraju]

Hi Its me again.

I tried an another way of achieving this. probably this may be the alternative solution.

I used a L2 switch connecting Internet, NAT Router, and PC Router. I configured sub interfaces on NAT Router as below

int fa 0/0.1

encap dot1q vlan 192

ip add 192.168.1.254

ip nat inside

int fa 0/0.2

encap dot1q vlan 128

ip add 218.248.17.2

ip nat outside

ip nat inside source list 1 pool NAT overload

access-list 1 permit 192.168.1.0 0.0.0.255

ip nat pool NAT 218.248.17.1 218.248.17.2 prefix 24

It is working perfectly. I am surprised why CISCO is not suggesting this as solution. Is there any downside found in this solution described now

sairam

[Marwan ALshawi]

this is not nat on stick

this is one using to logical interfaces

the logic how it works nat on stick

traffic coming to the interface, match the the acl of the route-map

then the route-map will make the input interface as the lo0

lo0 has nat enabled

then the packed wil be routed based on the router routing table and when go through the interface as egress interface will be nated using the nat pool

Hope this Help

[Peter Paluch]

Sairam,

What you have designed here with 802.1Q subinterfaces is a common solution if you have a 802.1Q-capable switch available. There are no notable downsides with this solution.

I do not know why Cisco is not suggesting this as a solution but it is basically a different scenario than you have originally suggested. You original problem was that you needed to designate a single interface both as inside and outside. What you have done here is basically a "cheating" but a smart one :) By creating two subinterfaces, you can designate one as inside, the second as outside.

The PBR solution is another smart trick whose primary disadvantage is that all NATted packets must be process-switched.

However, Cisco has actually come with a targeted solution exactly for this kind of problem - a NAT performed on a single interface. The solution is called the NAT Virtual Interface and is supported since IOS 12.3T. You may find further information here:

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html

Best regards,

Peter

[snarayanaraju]

Hi Peter,

Thanks for your post. The link you provided is very useful

But i am worried whether VRF has to be configured if NAT Virtual interface is used?

What to do if I donot have any VRF in place and whether this solution is suitable for the scenario i have discussed in my first post

Thanks and looking for your expertised comments

Sairam

[Peter Paluch]

Hello Sairam,

I believe that you don't need those VRFs at all when using NVI.

Your configuration would be as follows:

interface Ethernet0/0

ip address 218.248.17.2 255.255.255.0 secondary

ip address 192.168.1.254 255.255.255.0

ip nat enable

exit

ip nat pool SAI 218.248.17.11 218.248.17.12 netmask 255.255.255.0

access-list 101 permit ip 192.168.1.0 0.0.0.255 any

ip nat source list 101 pool SAI overload

Best regards,

Peter

[snarayanaraju]

Hi Peter,

I am very convinced with your reply. I will use NVI for upcoming projects.

But going back to NAT in Stick configuration, I need some more clarity which i expect you to help me

What is the logic of assigning OUTSIDE & INSIDE in the NAT in stick configuration. Because We are configuring both the outside and inside ip address in the same interface. (refer the diagram & configuration i attached previously.Then we are creating loopback 0 and making it IP NAT OUTSIDE interface.

But contradictly refering example 2 in the document i attached which is taken from CISCO there the Interface fa 0/0 is configured with IP NAT OUTSIDE and Loopback is configured with IP NAT INSIDE

can you take some of your time and make the concept clear for me.

sairam

[snarayanaraju]

Hi peter,

Have you tested the configuration.

I did using Dynamips. It failed. Moreover you configured 218.248.17.11 as secondary. If this is the case then I have to configure " ip route 192.168.1.0 255.255.255.0 218.248.17.2" in INTERNET Router, which will bypass the NAT(it will start working without NAT).

Moreover I understood that NVI is one of the method used for Inter VRF communication / routing.

Shall you help me on this?

Sairam

[Peter Paluch]

Hello Sairam,

Sorry for replying lately.

I have tested it right away - you were right, the configuration did not work as I originally posted it here. The solution is, fortunately, quite simple: add the command "no ip redirects" on the Ethernet interface and it should make things work.

My current configuration is as follows:

interface FastEthernet0/0

ip address 218.248.17.2 255.255.255.0 secondary

ip address 192.168.1.254 255.255.255.0

no ip redirects

ip nat enable

!

ip nat pool SAI 218.248.17.11 218.248.17.12 netmask 255.255.255.0

ip nat source list 101 pool SAI overload

!

access-list 101 permit ip 192.168.1.0 0.0.0.255 any

A neighboring router on the same segment produces this output:

Internal#show ip route

*Mar 1 00:19:36.891: %SYS-5-CONFIG_I: Configured from console by console

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.1.254 to network 0.0.0.0

C 192.168.1.0/24 is directly connected, FastEthernet0/0

S* 0.0.0.0/0 [1/0] via 192.168.1.254

Internal#ping 218.248.17.222 source 192.168.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 218.248.17.222, timeout is 2 seconds:

Packet sent with a source address of 192.168.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms

Internal#traceroute 218.248.17.222

Type escape sequence to abort.

Tracing the route to 218.248.17.222

1 192.168.1.254 4 msec 8 msec 36 msec

2 218.248.17.222 32 msec * 68 msec

Internal#

The router being pinged and tracerouted to is also on the same segment:

External#show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C 218.248.17.0/24 is directly connected, FastEthernet0/0

Sorry again for originally posting a non-working solution.

Best regards,

Peter

[snarayanaraju]

Hi Peter,

I am happy to see your reply. Indeed I am waiting for that. Thanks.

I will try this immediately. But please explain me the following:

1. How "no ip redirects" command makes the difference here. I know the use of this command. But what is the purpose of using this here and how it influenced the configuration

Thanks in advance. I will let you know the result after checking the configuration

Thanks in advance

Sairam

[Peter Paluch]

Hi Sairam,

You are heartily welcome.

I will try to explain the topics you've asked me but it will take some time.

About the "no ip redirect" - to be completely honest, I am also not quite sure what is going on. But I tried a few experiments and this is what I've found out.

First off, according to the wonderful document "When Are ICMP Redirects Sent?" at

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml

the redirects are sent when all these conditions are met:

1.) The interface on which the packet comes into the router is the same interface on which the packet gets routed out.

2.) The subnet or network of the source IP address is on the same subnet or network of the next-hop IP address of the routed packet.

3.) The datagram is not source-routed.

4.) The kernel is configured to send redirects.

Note that the sending of ICMP redirect messages does not apply in the case of our router with two IP addresses on its Ethernet interface because the condition 2 is not met (the packet goes from one IP subnet to another). In this case, the router reroutes the packet as usual.

Now, if we do not configure the NAT, things basically work - the router with the secondary address takes the packet and simply reroutes it on the same segment. However, as soon as we turned on the NAT, it apparently stopped working.

The problem was that the addresses in your NAT pool were from the same IP subnet as the secondary IP address in the Ethernet interface. I believe that the following sequence of steps has taken place (it is only my speculation as I have not found it documented anywhere - if there is a Cisco engineer nearby please correct me!):

1.) The packet came into the router through the NAT-enabled interface

2.) The NAT code first looked into the translation table for the Ethernet interface to see if there is already a translation entry. Let's assume that this is the first packet and the NAT table is empty.

3.) The NAT code therefore evaluated the access list 101 to see if that packet is eligible for translation. Because the packet passed the ACL check, the NAT created a new translation entry and rewrote the packet's source IP address to one of the NAT pool's public addresses.

4.) Now, the packet was about to be routed. However, the routing code with the IP Redirect feature turned on discovered that the (rewritten) source IP address of the packet is in the same network as the destination and that it is on the same interface through which the packet came in. Probably, the code now concluded that it is unnecessary to resend the packet out as both the source and the destination are on the same network and on the same interface, so it just dropped the packet without sending anything.

I suspect that turning off the IP Redirect feature removes that addition "sanity" check and the router simply and dutifully routes the packet according to its routing table after it was NATted. Therefore, it started working.

You can try this: make the NAT pool to contain addresses from a different network than the secondary IP address on the Ethernet interface is in. Then the NAT will work even with the IP Redirect turned on.

I don't know if this is comprehensible to you - I find it myself quite messy.

Best regards,

Peter

[snarayanaraju]

Hi Peter,

I am in sync with you. I am able to get your explanation cleary. No doubt in it. I admire you depth understanding on the concepts

But in none of the cisco doc and in any forums i am seeing that NVI is the alternate to NAT in stick configuration

It says that, NVI is used to make communication with different VRFs.

Do you have second opinion on this

Sairam

[Peter Paluch · Accepted solution]

Hi Sairam,

Thank you for your kind words.

While the Cisco does not explicitely state that the NVI can be used for the NAT-on-stick applications, it does not say neither that it can not be used. In the command reference for 12.4 IOS, it is stated that the "vrf" option in the "ip nat source" command is optional, thereby allowing its use also in the global routing table.

Regarding that the NVI is allegedly supposed to provide means for communication between different VRFs, this is a quotation from the article about the NVI posted earlier here:

NVI is not a new way of doing NAT; it's a new feature to resolve NAT restriction.

And this is what I also think about NVI. Not primarily VRF-specific stuff (even though it might in cases help solve some problem but I do not know enough about such applications) but rather a different approach to do NAT.

Best regards,

Peter