slow vpn tunnel (pix to pix)

[wfbtr]

hello-
I have a site that is about 4 miles from the main office and have a vpn tunnel between the two. To browse the network from the remote site seems ok- a tad slow, but to pull up a document or save a document to the main site is extremely slow. And also to send an email from the remote site to the main site is slow as well. The remote site is just one workstation behind a PIX 501. The Exchange box is at the main site.
Any thoughts?
thanks.

 

[308win]

Is this a problem with the VPN or the underlying internet connection, might it just be a crappy DSL connection? Have you gone to dslreports.com and run a speed test?

 

[wfbtr]

hi 308-
thanks for the response. It's a T1, though I haven't tested the speed yet. I'll give that a shot. It takes 6 minutes to copy a file that is just under 2 megs to the network share, which I think is a bit slow. Or maybe that's normal because of the 3des encryption. I'm not sure.

 

[wfbtr]

also- to bring up and manipulate a document on the network times out (not responding).

 

[mbilgrav]

Hi,

Verify/check that your bandwitdh (bw) is not used up on both sides, by interbet traffic/downloades etc
Try a Show local and observe the bytes sizes and durations.

Verify that you have prober interface sppeds and duplex setting, by a show interface, and observe the counters for collision, runts, CRC, interface resets etc.

Also check you VPN config, and make sure you use seperate ACL for NAT-0 and crypto ACL.

HTH
Martin Bilgrav

 

[wfbtr]

thanks mbilgrav-
do i need to show interface while the vpn is being utilized? right now i show full duplex, MTU 1500 bytes, 0 runts/giants/input errors, crc, frame, overrrun, ignored, abort, underruns, output errors, collisions, resets, babbles

received 13,274 broadcasts

 

[308win]

2 million bytes is 16 million bits. 16 million bits over a 1,440,000 bit line is 12 seconds + overhead, which is still not 6 minutes. There is a problem.

As mbilgrwav said, verify that the bandwidth is available.

You do not need to 'sho' the interface while the VPN is being utilized. You apparently have 0 errors. Can you make sure the next device also has no errors on it and the duplex matches? (Since you are clean, it also should be.)

Try shrinking the MTU on a workstation, make it 1440 or less. (I use DRTCP) I had problems with one of my sites and that cured it.

 

[mbilgrav]

alsp remember that you have TWO PIX'es to verify.
show local - on both pix
Observe byte count and duration.

sho interface on both pix.
Observe both inside and outside interfaces for errors.

 

[wfbtr]

thanks for both replies. i'll try the mtu setting at the remote site.
my PIX at the main site has the e0 (outside) interface at half duplex. the e1 is at full duplex. should the outside be set at full as well? and if so, what's the syntax?
thanks.

 

[308win]

no, the duplex settings on the intefaces can be different, the duplex needs to match the device that it is connected to, as in a switch or router. If the other device is auto-negiotiate, that might be the source of your problems. You should lock them down. However your interface is running without errors, on at least the one that you described, which leads me to believe that you do not have a duplex/auto negiotiation issue. (The one at half might show collisions, which is normal and not an issue as long as it is under 5% during the short term)

 

[mbilgrav]

just read my own posts....
What you should verify is show conn not show local
sorry for the misleads.

 

[wfbtr]

just did a couple tests. from the main site i pulled the 2 meg document to my workstation. It took about 2 minutes. I pulled the document to the server, it also took just over 2 minutes (it has a RAID, which I think makes the write a little longer). and then I had the user copy it to the server right after my two tests, and it still took 7 minutes.

 

[jdeaner]

do some packet sniffing on the outside and the inside of the FW(s) to see the traffic.