Simon, if you aren't through nat from the client back to the VPN device, I think there could be an asymmetric or some other routing issue back to the client. The NAT-T constructed, means that packtes back to the ip address included inside the messages were dropped. I have seen this in a couple of cases when NAT is not used. My guess, is a "show ip route" back to the actual IP address of the VPN client would route the traffic out another interface. Thus it is not parsed by the crypto map that is receiving the traffic. Also, you will notice that subsequent packets are "NOT Encrypted, but should've been". The client uses aggressive mode, so if this is the case, it actually may have went further than a L2L client that would have used main mode. There may be some other stuff going on, but I would make sure that the packets are directed back out the same interface with the crypto map first. That NAT-T is a clue if NAT isn't being used. In any case, post back what the resolution was so we all know.
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
