Policy NAT

Hi Laz,

Thanks for responding.

I was a little sloppy with my question as information was missing. I actually used the following route maps for my topology (different IP addressing):

route-map ISP1 permit 10
 match ip address 100
 match interface GigabitEthernet0/0

route-map ISP2 permit 10
 match ip address 101
 match interface GigabitEthernet0/1

The 100/101 access list:

access-list 100 permit tcp host 155.1.79.9 host 150.1.6.6 eq telnet
access-list 101 permit tcp host 155.1.79.9 host 150.1.3.3 eq telnet

So, it is only triggered by the host, and the route’s exit interface has to be the one directly connected to the relevant ISP.

Regarding the external interface and overloading, this can be changed to a pool with an single IP, but the static requirement that has not been met.

Still, what I was really trying to figure out is the difference between using route-map at the begging and at the end, but as you highlighted, one is dynamically created by traffic based on matches in route-map, whilst the the other is static but only used if traffic meets the route-map’s criteria.

Still, for a static NAT entry, that means outside hosts can connect to the inside host without restriction as the route map does not apply in inbound traffic and the entry exists in the table, is that correct?

Sam

Hello again Sam

Ah I see, thanks for clarifying. I think your description is spot on. Your use of both match ip address and match interface in your route-map is a well-documented pattern in multi-ISP scenarios. The match ip address selects your specific flow (the Telnet traffic between those two hosts), while the match interface ensures that routing actually sends that traffic out the expected ISP-facing interface. It’s a solid approach that gives you clear, predictable control over which static mapping gets applied to which ISP path.

Now, concerning dynamic versus static route-map behavior. You’re right. The key difference really does come down to when the translation is created.

In dynamic NAT, where the route-map is at the beginning), the router creates translations on-demand. A NAT entry only pops into the table when traffic matching your route-map criteria actually flows. Once it ages out from inactivity, it’s gone until the next matching packet arrives.

In static NAT, where the route-map at the end, the 1:1 translation is permanent. It’s loaded into the NAT table immediately upon configuration and stays there forever (or until you reload). The route-map’s job is not to decide whether the translation exists, but when it applies. If outbound traffic destined for ISP1 arrives, this static mapping is used while traffic matching a different route-map uses a different static mapping. This is why Policy NAT works so elegantly for dual-ISP topologies. The same inside host gets different inside-global addresses depending on the destination, and each mapping is always available for bidirectional traffic.

And you’re correct, since those static route-map mappings exist unconditionally in the NAT table, outside hosts can indeed connect to the inside host without restriction. The route-map is only evaluated for outbound traffic to decide which static mapping applies. When an outside host sends traffic destined to one of your global addresses, the router simply does a destination-address lookup in the NAT table, finds the static 1:1 binding, and reverses the translation without re-checking the route-map against inbound criteria.

But remember, policy NAT with static mappings is not a firewall control, and that is not its purpose. If you genuinely want to restrict which outside hosts can reach an inside resource, you’ll need to apply a separate access-control list to your outside interface. The route-map only controls where outbound traffic gets translated, not who can initiate inbound connections.

So, although the dynamic NAT entry is “safer” in this sense, it is by no means a complete security solution. Security must be implemented as a separate implementation regardless of what NAT you choose to use. Make sense?

I hope this has been helpful!

Laz