cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
409
Views
0
Helpful
3
Replies

PIX to PIX VPN Errors

dan.shalinsky
Level 1
Level 1

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

3 Replies 3

Philip D'Ath
VIP Alumni
VIP Alumni

Just in case it is a software bug, try 3DES or AES128 for a while.

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

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