Hi @geoffFx ,
IPSEC tunnel is supposed to encrypt data, in general within two endpoints but supports p2mp ipsec architectures too.
For the sake of current conversation let's stick with the P2P example.
Normally , when typical S2S IPSEC setup is configured, traffic is originated from a source, it's encapsulated within an ESP header and terminated exactly to the remote address where tunnel points to, after initial phase where IKE/ISAKMP negotiation happens.
Once destination is reached, de-capsulation occurs and then traffic can finally travel out unencrypted towards final users.
When a nat element is in the middle (that is between two endpoints), you have an additional device which rewrites the tunnel source ip header to a new source address (post-natted ip header). This means that you can loose visibility of your real tunnel endpoint address. How overcome such situation?
In this case IPSEC uses NAT traversal (NAT-T) to allow communication between endpoints.
ESP packet will be encapsulated inside a UDP packet with port 4500 after a negotiation phase where both sides recognize they're behind a NAT device. Further communication is entirely encrypted and handled by the feature which delivers traffic to the effective destination.
There's not really a matter of best practice behind its use. Sometimes you may have small offices behind ISP NAT which should use IPSEC. So, in that case, NAT-T becomes one of possible solutions to choose. Of course, Cisco routers do support NAT-T.
Kind regards.
