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