I would hypothesize that the decryption in the in-to-out and encryption in the out-to-in paths are related to IPsec VPNs in which the clients are considered "inside" and they are accessing the outside internet. Think of a teleworker using a IPsec-protected access to internet via his/her company infrastructure. After creating an IPsec tunnel terminated at an interface marked as "inside", the teleworker's IPsec-protected traffic arrives at the router, is decrypted and after routing out through an "outside" interface, it is being NATted. For the return traffic, it is NATted from "outside" to "inside", then sent to the teleworker IPsec-encrypted.
I have the same problem and as I can see here, this is not answered yet.
I looked after this topic and I found the following:
NAT inside to outside (local to global translation)
NAT outside to inside (global to local translation)
I understand that by out-to-in direction NATing happens first and only then routing, this is logical, since the main point would be in to route only a private IP in the intern network instead of a public one.
But in case of in-to-out direction, I don't see the logic of making routing before NATing.
In order to properly route the packet with a public destination address, it first has to be NATted back from the private IP.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...