PDA

View Full Version : Extreme Slowness on VPN Tunnel - Packets drop



hotice_
2009-12-22, 15:49
Hi,
I'm having a really weird problem with very slow VPN traffic (Non-Encrypt is fast and normal)

Setup:
VPN Community - 3 sites fully Meshed
Site A - Nokia IP260 on R61 HFA3 (I know)
Site B- UTM-1 EDGE 7.X Firmware
Site C- UTM-1 EDGE 7.X Firmware

Symptoms:
Traffic in a specific VPN tunnel is VERY slow and I see a lot of packet loss
Traffic is ONLY slow between site A & B.
Between A&C and B&C, everything is working as normal


-Non-Encrypted traffic between A&B is functionning normally
-VPN tunnels are established normally
-Tried disabling QOS module completely, didn't help
-Tried creating a new VPN community only between A&B - no dice
-Reduced to DES for Phase1&2 for vpn community
-Tried Reducing the VPN encryption domain on each side to only 1 specific host (2 Domain controllers)
-Tracker shows nothing out of the ordinary



The only odd thing I saw is a fw monitor output analysis shows the i, I, o but NOT the Big O everytime.

isharted
2009-12-22, 19:35
Could there be a load issue on the Edge device (B)?
Also, are you putting the vpn flags in your fw monitor (-pi +vpn -pO -vpn)?

On issues like this, I usually start with focus on the Edge device. Weird that B&C works fine, though. Possibly some link between A&C has a problem with the protocol 50 traffic?

lammbo
2009-12-28, 09:23
Could there be a load issue on the Edge device (B)?
Also, are you putting the vpn flags in your fw monitor (-pi +vpn -pO -vpn)?

On issues like this, I usually start with focus on the Edge device. Weird that B&C works fine, though. Possibly some link between A&C has a problem with the protocol 50 traffic?

Given the manner the traffic responds between any given path of A+B+C, I would have to assume the gateways are configured correctly so my guess would be more along the lines of PMTU. There are several other posts on this forum that discuss testing this already so maybe start there by testing your allowed packet sizes each way.

hotice_
2009-12-28, 19:45
Given the manner the traffic responds between any given path of A+B+C, I would have to assume the gateways are configured correctly so my guess would be more along the lines of PMTU. There are several other posts on this forum that discuss testing this already so maybe start there by testing your allowed packet sizes each way.

This was also my initial thought. I had the customer try a few pings and I'm a bit puzzled by the results:

192.168.3.0/24 is the remote site



ping -f -l 1492 192.168.3.3

Pinging 192.168.3.3 with 1492 bytes of data:

Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 192.168.3.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ping -f -l 1373 192.168.3.3

Pinging 192.168.3.3 with 1373 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.3.3:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

ping -f -l 1364 192.168.3.3

Pinging 192.168.3.3 with 1364 bytes of data:

Request timed out.
Request timed out.
Reply from 192.168.3.3: bytes=1364 time=187ms TTL=125
Request timed out.

Ping statistics for 192.168.3.3:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 187ms, Maximum = 187ms, Average = 187ms

melipla
2009-12-29, 10:45
It sounds like a routing problem for ipsec traffic, which I would blame on the ISP or the upstream ISP. :) Never the less, I saw this note in the R70.20 release notes which sounds like it might be part of your problem:


00465490 VPN between two different networks will now successfully complete the IKE over UDP phase even when there is a router with a low MTU situated between them.

So my answer would be to upgrade to the latest version on the IPSO gateway and see if that helps. ;) Doesn't look like new Edge firmware has been releases since July 2009, so it wouldn't include that fix.

The only other thing I could think of would be to try to use one VPN tunnel per Gateway pair on the VPN Community to see if that helps.

dsb.nepo
2009-12-29, 16:30
This remind me a bug we run 8 years ago ...

Is this for all traffic or only specific protocols (icmp/smb/...) ?
If you have dmz's connected to site A/C which are connected over a dedicated switch to the GW is the traffic even slow?

Our problem was a bad firmware on a core switch which set the DF flags but only for smb traffic and icmp.

Maybe you see more if you look to the packets with 'fw monitor' or tcpdump