Policy NAT

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene,

Believe you have a typo:

R1(config)#interface Gi
R1(config)#interface GigabitEthernet 0/1

Should be

R1(config)#interface GigabitEthernet 0/1
R1(config)#ip nat inside

1 Like
3

Hello Chris

Yes you are correct! Thanks for catching that! I will let @ReneMolenaar know to have that changed.

Thanks again!

Laz

4

Hello Rene,
I haven’t yet tried out, but couldn’t we do something like this instead of using a route-map?

ip nat inside source list TO_ISP1 int g0/2 (or pool POOL_TO_ISP1)
ip nat inside source list TO_ISP2 int g0/3 (or pool POOL_TO_ISP2)

--
Respectfully

1 Like
5

Hello Network E,

I hope you are doing well. I will admit that I have not read this lesson, but I have read the headline, and I might be able to answer your question. Policy based NAT is done with a route map, if you used some other method to NAT it would not be policy based NAT. So would your config work? Possibly, but if it did you are no longer using policy based NAT.

I hope this helps.
Scott

1 Like
6

Hello Network E

@wellerk.scott is absolutely right. You could do it that way as well. However, the exercise was used to show how to use a route-map.

The advantage of using a route map instead is that you have more flexibility by creating more specific NAT rules.

I hope this has been helpful!

Laz

7

Thanks Chris, I fixed this.

8

So the overall idea with regard to Policy-based NAT is very clear. Can you please elaborate on other advantages that PBN gives us beside matching traffic using ACL. What I mean is that it was correctly pointed out that the same result might be achieved using just ACL as a source instead of static nat. Also you can match the same traffic with this ACL. So what is the flexibility and advantage that route-maps are giving us?
Can we match next-hop, can we alter next-hop, can we do some advanced matching that we’ll not be able to achieve using ACL?

9

Hello Denis

As mentioned in a post above, yes you would be able to get the same result as that within this lesson simply by using an access list. However, the advantages of using Policy NAT over simply using an access list is the same as the advantages given by route lists over access lists.

Route lists are more powerful since, besides prefixes, there are a lot of different match conditions that you can use. In the Introduction to Route Maps lesson, you will find the following list of elements that can be matched:

R2(config-route-map)#match ?
    additional-paths  BGP Add-Path match policies
    as-path           Match BGP AS path list
    clns              CLNS information
    community         Match BGP community list
    extcommunity      Match BGP/VPN extended community list
    interface         Match first hop interface of route
    ip                IP specific information
    ipv6              IPv6 specific information
    length            Packet length
    local-preference  Local preference for route
    mdt-group         Match routes corresponding to MDT group
    metric            Match metric of route
    mpls-label        Match routes which have MPLS labels
    policy-list       Match IP policy list
    route-type        Match route-type of route
    rpki              Match RPKI state of route
    security-group    Security Group
    source-protocol   Match source-protocol of route
    tag               Match tag of route
    track             tracking object

So you can apply policy NAT based on the metric of a route, or even the tracking of a particular object. Even when working only with prefixes, route maps give you the advantage of working with multiple access lists allowing you to create more complex polices for NATting.

I hope this has been helpful!

Laz

10

Hello Rene:
I was labbing this topic and detected that with static nat, “route-map” apply only when the traffic is initiated from the inside to outside. But when the traffic is initiated from the outside to inside, this does not follows “route-map” rules. I have checked on Cisco documentation and saw that need to include at the end the reverse option, also tested but did not work…Can you share any information about this issue, please? If necessary I can share the config I have tested.
Thanks in advance!!

1 Like
11

Hello Ovaldo

What you are describing is the normal behaviour of NAT, whether you use policy NAT with route maps or not. When configuring ip nat inside source static, only traffic initiated from inside to outside will create the NAT translation. Of course, any return traffic of the same flow (same source and destination IP addresses and ports) will be allowed back through, as these are identified as responses to the initial communication.

If you want to enable incoming traffic from outside in, you must use the examples shown in the following lessons:


I hope this has been helpful!

Laz

1 Like
12

Hello Laz:
Thanks a lot by your feedback!! You said that when we set “ip nat inside source static” only traffic initiated from the inside to outside can be translated and of course the return traffic beloging to the same flow. At this point, I can not agree with you, also traffic initiated from the outside can be translated (IG–>IL). From my reading on Cisco Documentation when uses “route-map” for static nat, only inside to outside flow works, if the traffic is initiated from the outside “route-map” does not apply. This is, one interesting aspect , that’s why i asked about it.
Thanks!!

13

Hello Ovaldo

Yes, I stand corrected. My thoughts were focusing more on PAT. Using the ip nat inside source static command will create a one to one static NAT translation for traffic in both directions.

As for the use of route-maps for static NAT, the addition of the route-map keyword at the end of the NAT statement adds a requirement that the route-map achieve a match in order for that NAT statement to be applied, and the translation to take place. In the specific NAT statement of the lesson, the only way a translation will take place is if there is a match with the source address and the destination address. Since such a match will only take place on outgoing traffic with the specific source and destination IP addresses, then only the specific outgoing traffic will be matched.

What you are referring to here when talking about the reversible keyword in your post is further described in the following Cisco documentation:

It includes restrictions on this feature, and what platforms support it.

I hope this has been helpful!

Laz

14

Hello Laz:
Thanks for your reply!!

1 Like
15

why the link btween nat and ips1 catch 192.168.1.101 as source and not 192.168.12.1?

16

Hello Konstantinos

When H1 attempts to create a telnet session with 2.2.2.2, the packet should arrive at ISP1 with a source address of 192.168.12.1. According to the lesson, this translation occurs successfully at R1. Are you seeing something different in your topology? If so, then there may be something wrong with the translation configuration, the route map, or the ACL in your configuration of R1. Take a look and if you need any further help, let us know!

I hope this has been helpful!

Laz