01-31-2025 03:57 AM - edited 01-31-2025 03:58 AM
Hello, everyone.
Every NAT that I've configured so far has a use that I can associate with the real world (Static NAT/PAT, Dynamic PAT, Twice NAT) but I don't understand why would we ever want to configure Policy NAT.
From my understanding, this is a NAT configuration that matches packets not only based off the source but also based off the destination and other parameters which makes it more specific/flexible.
So instead of configuring my ACL like this: access-list 1 permit x.x.x.x y.y.y.y, with Policy NAT,I could use an extended ACL to specify the destination and even port numbers or even use a route map.
However, why? Why would we ever want to use Policy NAT? Why would we want the translations occur and possibly differ based off both the source and the destination?
Thank you.
David
Solved! Go to Solution.
01-31-2025 04:10 AM
One case, if you have VPN and you want to excluding vpn traffic from NATing, here we need extended ACL in NAT.
Deny vpn traffic and allow other traffic
MHM
01-31-2025 04:23 AM
I would say as a form of security, basically for the same reasons we use FWs, and possibly in lieu of a FW.
Consider your recent question about static PAT, using Telnet port 23 for both inside and outside. Why use it at all, rather than static NAT? (Especially as your questions, then, were about failures of traffic not getting through, although not by design. But, if such failures are by design? [Of course, design security can be done in different ways, but if we need to use NAT/PAT anyway . . .])
NB: typing this reply, I saw @MHM Cisco World 's reply arrive, and a nice example of limiting transit traffic to specific need.
01-31-2025 04:33 AM - edited 01-31-2025 04:33 AM
Hello
it’s more of a granular translation - specifying sip/dip and ports to only perform translation subject to the condition of the policy and at all other times not to translate at all or do so but just on sip/sip &port etc..
you may want to perform policy translation depending on where the traffic is originating from and importantly where it is destined to go and on what port is using and would like to connect too
01-31-2025 04:10 AM
One case, if you have VPN and you want to excluding vpn traffic from NATing, here we need extended ACL in NAT.
Deny vpn traffic and allow other traffic
MHM
01-31-2025 04:23 AM
I would say as a form of security, basically for the same reasons we use FWs, and possibly in lieu of a FW.
Consider your recent question about static PAT, using Telnet port 23 for both inside and outside. Why use it at all, rather than static NAT? (Especially as your questions, then, were about failures of traffic not getting through, although not by design. But, if such failures are by design? [Of course, design security can be done in different ways, but if we need to use NAT/PAT anyway . . .])
NB: typing this reply, I saw @MHM Cisco World 's reply arrive, and a nice example of limiting transit traffic to specific need.
01-31-2025 04:37 AM - edited 01-31-2025 04:37 AM
"Consider your recent question about static PAT, using Telnet port 23 for both inside and outside. Why use it at all, rather than static NAT?"
Right, since there is a difference between allowing all communication from and to that IP instead of allowing only specific ports where the packets with ports that do not have a matching entry would be just dropped.
I also noticed @MHM Cisco World's reply, thank you!
01-31-2025 06:49 AM
"Right, since there is a difference between allowing all communication from and to that IP instead of allowing only specific ports where the packets with ports that do not have a matching entry would be just dropped."
Exactly! Plus, with PAT, you can also redirect ports, not something ACLs, route maps, or possibly most FWs would do, again if you need to use NAT/PAT anyway, and you can avoid the need for a stand alone FW (saving real world $$$), possibly a real world usage case.
In real world networking, $$$ often is a very critical concern, vs. classroom examples, which focus on learning network concepts.
01-31-2025 04:33 AM - edited 01-31-2025 04:33 AM
Hello
it’s more of a granular translation - specifying sip/dip and ports to only perform translation subject to the condition of the policy and at all other times not to translate at all or do so but just on sip/sip &port etc..
you may want to perform policy translation depending on where the traffic is originating from and importantly where it is destined to go and on what port is using and would like to connect too
01-31-2025 04:39 AM
Hello David,
Policy NAT is useful when you need more granular control over how NAT operates in complex networks, providing the ability to translate traffic based on not just source IP but also destination, port numbers, or other parameters. It allows you to apply specific NAT rules depending on various traffic attributes, such as source and destination IP addresses, protocol, and port numbers, which makes it ideal for scenarios where traditional NAT methods (like statc NAT, PAT, or dynamic NAT) fall short.
Policy NAT is used when different types of traffic need to be treated differently, such as separating web traffic from email traffic or managing traffic between different departments in an organization. This type of NAT allows for granular control over how traffic is translated based on specific criteria like source and destination IP addresses, protocols, or ports. For instance, web traffic can be translated to one public IP, while email traffic is translated to another. It also enables the assignment of distinct public IPs for different types of outbound traffic, like internal users accessing cloud services versus browsing websites. Additionally, Policy NAT is helpful in scenarios where certain hosts or services, like VPN traffic or public-facing servers, need to be excluded from NAT, while other internal traffic is NATed. It also allows for selective NAT, such as address overloading or port-specific mappings, and can be applied to different departments to apply unique translation rules.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide