cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
480
Views
0
Helpful
4
Replies

Pix-to-Pix Lan-to-Lan issue

justintime
Level 1
Level 1

I have a very peculiar issue regarding two PIX515e's (7.0(6)) running a l2l config. Take the following diagram:

HostA---PixA---PixB---HostB

HostB runs an app that does large SQL queries against HostA. When there is a lot of traffic, the TCP connection eventually times out.

Through packet captures and 'show asp drop' on PixA and PixB, and much loss of hair, I have determined what is happening.

HostB sends a packet to HostA. HostA receives the packet, and transmits an ACK. For some reason I haven't discovered, PixB drops the ACK. HostB never recieves the ACK, so it sends a TCP retransmission to HostA. Since PixA already saw the ACK for the initial packet, PixA drops the retransmission (and all subsequent retransmissions) from HostB with a 'TCP DUP and has been ACKed' counter increment in 'show asp drop'. This results in a deadlock condition in the TCP session, and it eventually times out.

Both networks are as secure as can be, and are deemed "trusted". Is there a way that I can disable the PIX's asp checks on any traffic over the l2l VPN?

Justin

4 Replies 4

network.king
Level 4
Level 4

Hi ,

Just two queries ,

Is that initially HOSTA and HOSTB communication fine .

And if the problem is during high voulume of traffic exchange , whats the PIX cpu and how is the number of connections in the PIX

regards

vanesh k

Yes, HostA and HostB communicate fine. The problem actually affects any host behind PixA talking over the VPN to any host behind PixB. The problem only rears it's head during TCP sessions with a lot of data passing back and forth - ssh traffic is fine.

PixB is very lightly loaded, but PixA might be under load, and that might explain some of the sporadic-ness of the problem. I will look into the CPU and # of connections on PixA and post back.

Thanks for the reply!

Justin

Talking to the group that admins PixA: "The CPU has only went over 20% twice in the last 3 months and runs steady at 5-10%. Utuilization for outside interface is under 5% on avg and inside is the same."

So I don't think it's overutilization that's causing the problem. If it was too many connections, we'd see that in syslog, wouldn't we?

Justin

Answering my own post, we updated the PixA to 7.0(6.4), and like magic, everything works. Not only does the app in question work, everything else over the VPN works *much* faster. Dunno exactly what they did in 6.4, but it made a huge difference for me!