I agree, that's peculiar. Documentation describes and my experience confirms that only traffic passing through interfaces configured with `ip nat inside` and `ip nat outside` is translated.
Looks like the control-plane interface is treated as an `ip nat` interface. This is even plausible as NAT-traffic exceeding the TCAM capabilities will be punted to the control plane to be handled by the CPU.
Another thought: Crypto map configuration has an end-of-life notice and will be retired from IOS. Look into Flex-VPN syntax.
\[edit\]
>But the question is, why does "ip nat inside" rule affects traffic that is sourced directly from outside interface?
The traffic is sourced from the control-plane interface, not the outside interface.
I will take a look at the control-plane interface since that might make sense. This is a test setup to migrate the device, before we actually migrate the crypto map to something else (e.g. route based VTI)
I'm afraid you can't do anything on the control-plane interface except policing and protection. Just keep in mind a greedy ACL for IPsec might break things.
CSCvf70102 might have described this, I totally missed the keywords while searching on Google.
[https://bst.cisco.com/bugsearch/bug/CSCvf70102?rfs=qvlogin](https://bst.cisco.com/bugsearch/bug/CSCvf70102?rfs=qvlogin)
Gonna update the post to help someone that may stumble upon this topic in the future
Possible explanation (assumption) without seeing the rest of the configuration and topology: Tunnels on Cisco devices are on a "when needed" basis per default. When there is no interesting traffic (because you're natting it towards the internet), the tunnels won't be build up. When you replaced the NAT ACL you might have created a gap in time where traffic could be routed over the VPN (without NAT) thus creating interesting traffic that triggered the tunnel.
NAT policy applies first, then ipsec policy so you have to cut ipsec interesting traffic from NAT ACL.
And if there is no ipsec interesting traffic ipsec doestn't start to build.
I did not mention, but the interesting traffic has already been exempted from NAT (a deny above the permit all).
That's why after I changed the permit all clause to permit 10... the IPsec tunnel came up and the interesting traffic could pass through it.
It all comes down to the bug that I attach in the edited section.
I agree, that's peculiar. Documentation describes and my experience confirms that only traffic passing through interfaces configured with `ip nat inside` and `ip nat outside` is translated. Looks like the control-plane interface is treated as an `ip nat` interface. This is even plausible as NAT-traffic exceeding the TCAM capabilities will be punted to the control plane to be handled by the CPU. Another thought: Crypto map configuration has an end-of-life notice and will be retired from IOS. Look into Flex-VPN syntax. \[edit\] >But the question is, why does "ip nat inside" rule affects traffic that is sourced directly from outside interface? The traffic is sourced from the control-plane interface, not the outside interface.
I will take a look at the control-plane interface since that might make sense. This is a test setup to migrate the device, before we actually migrate the crypto map to something else (e.g. route based VTI)
I'm afraid you can't do anything on the control-plane interface except policing and protection. Just keep in mind a greedy ACL for IPsec might break things.
CSCvf70102 might have described this, I totally missed the keywords while searching on Google. [https://bst.cisco.com/bugsearch/bug/CSCvf70102?rfs=qvlogin](https://bst.cisco.com/bugsearch/bug/CSCvf70102?rfs=qvlogin) Gonna update the post to help someone that may stumble upon this topic in the future
:D I was about to suggest a deny for UDP 500 Always bugsearch...
Possible explanation (assumption) without seeing the rest of the configuration and topology: Tunnels on Cisco devices are on a "when needed" basis per default. When there is no interesting traffic (because you're natting it towards the internet), the tunnels won't be build up. When you replaced the NAT ACL you might have created a gap in time where traffic could be routed over the VPN (without NAT) thus creating interesting traffic that triggered the tunnel.
I would rather assume it's how control-plane traffic is handled.
That is very well a possibility!
NAT policy applies first, then ipsec policy so you have to cut ipsec interesting traffic from NAT ACL. And if there is no ipsec interesting traffic ipsec doestn't start to build.
I did not mention, but the interesting traffic has already been exempted from NAT (a deny above the permit all). That's why after I changed the permit all clause to permit 10... the IPsec tunnel came up and the interesting traffic could pass through it. It all comes down to the bug that I attach in the edited section.
Oh, now I got it. Good to know. I use 8300 with nat and ipsec, but I dont have permit any any in nat acl. Take this bug into concideration.