What are the reason behind this, security? If it is, tunneling like IP GRE is not recommended since serial link is already private, use IPSec VPN with AES-256/SHA-HMAC encryption. AES is faster than DES (3DES).
"fast encryption method that doesn't eat the BW and keep the latencies low."
You're usaully going to give up some, since it's then nature of the beast. However, one item to watch for, often the encryption imposes a smaller effective MTU. Packet fragmention can often adversely impact performance. For TCP, if supported, the IOS command IP TCP adjust-mss helps avoid the issue.
Now I have a new problem... I've confirmed that all the traffic I want is going thru the VPN tunnel... nothing is going unencrypted anymore and that's exactly what I needed. However, we have Netflow running in the remote router and the Netflow packets are in fact getting encrypted in the remote side but then the peer routers rejects the packet by saying this over and over:
%CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
This is an indication that the access list that you are using does not match the access list used on the other end of the connection. That access list has a statement that permits the Netflow traffic and your access list does not have a statement that permits it.
Look at both access lists. They should be mirror images of each other. I believe that you will find that there is at least one statement on the other end that is not matched on your end. Fix the access lists so that they are mirror images of each other and I believe that the problem will be solved.
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...