03-19-2005 06:50 AM - edited 02-21-2020 01:40 PM
We're doing a PIX to PIX VPN using 2 525s. The VPN is working, but we're seeing poor performance (only 2.4mbps) and what I believe are a significant number of errors. Also, I think that there may be a packet size problem as the largest packet that can be sent is 990 bytes. The previous VPN was using 2621s and we saw around 5mbps max BW ~ with the PIXs we're getting half of that.
Debug crypto ipsec shows the following error:
IPSEC(cipher_ipsec_request): ERR: bad pkt 10.0.140.80->192.168.0.60
I can cause this message by pinging through the VPN with a packet larger than 990 bytes. Even without the DF-bit set, a ping larger than 990 bytes will fail.
show crypto ipsec sa:
#pkts encaps: 1857023, #pkts encrypt: 1857023, #pkts digest 1857023
#pkts decaps: 2346358, #pkts decrypt: 2348410, #pkts verify 2348410
#pkts encaps: 8455751, #pkts encrypt: 8455751, #pkts digest 8455751
#pkts decaps: 9095401, #pkts decrypt: 9095401, #pkts verify 9095409
#pkts encaps: 422099, #pkts encrypt: 422099, #pkts digest 422099
#pkts decaps: 734762, #pkts decrypt: 739089, #pkts verify 739089
IPSec transform is AES-256/SHA. I've checked my configs a dozen times - both ends are identical. Besides, I believe that any config discrepancy would prevent the SA from forming altogether.
Virtually all the errors occur only on one end. The other has a few errors only on one subnet pair.
Any thoughts or help appreciated.
~Dan
03-19-2005 12:22 PM
Just in case it is a software bug, try 3DES or AES128 for a while.
03-20-2005 06:46 PM
Great thought, unfortunately, same result. Also, the throughput difference the PIXs and 2621s isn't as great as I suggested, but the PIXs are still slower.
For sure, the decrypt errors and limiting packet size are issues.
I am appreciative of any and all suggestions.
~Dan
03-22-2005 03:05 PM
For the general knowledge of all, the problem was less serious than I originally thought. The only limitation was that ICMP packets larger than 1020 bytes were not allowed through the outside interface. All other IP traffic was fine.
The problem turned out to be having "ip audit" enabled on the outside interface. Remove both "ip audit interface outside" commands, and we're all good now. I guess it was preventing large packets from getting fragmented before encryption.
~Dan
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide