Elijoh
asked on
IPSec VPN dropping Packets
I have an ASA 9.6 with 3 L2L vpns configured. I also have Remote client configured on the firewall. The tunnels seem to be up and I can see sessions created for the L2L vpns. The problem is that after connecting and running continuous pings, the packets have register a drop(request timed out). This has resulted to some servers being inaccessible as the connection times out when connecting. See the screen captures for pings.
Capture-ping.PNG
Capture-ping.PNG
Try pinging with larger packet sizes and see if the number of packet drops increases.
A VPN adds overhead to the packet, and unless you're adjusting the segment size, then normal 1500-byte packets will get fragmented into a large 1450-ish byte packet and a 50-ish byte packet.
This basically doubles the risk for dropped/delayed packets. (Unless, as I mentioned, you enter the command to adjust the maximum segment size.)
A VPN adds overhead to the packet, and unless you're adjusting the segment size, then normal 1500-byte packets will get fragmented into a large 1450-ish byte packet and a 50-ish byte packet.
This basically doubles the risk for dropped/delayed packets. (Unless, as I mentioned, you enter the command to adjust the maximum segment size.)
ASKER
Thanks for your response asavener...the tunnel is using the default MTU...do I need to change that or just test a ping with a larger payload?
PeterLong I also thought this is normal but it's affecting access to servers since they timeout. The ipsec sessions do not drop.
PeterLong I also thought this is normal but it's affecting access to servers since they timeout. The ipsec sessions do not drop.
Did some research, and found that the ASA automatically adjusts the mss, now, to 1380.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/s8.html#wp1517601
You can try explicitly setting the mss to a lower value. (For example, sysopt connection tcpmss 1200)
Run ping tests with the do-not-fragment bit set to determine what the largest non-fragmented packet size is that will successfully ping the remote site.
Also, run some ping tests to determine whether you have more packet drops for larger packets.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/command/reference/cmd_ref/s8.html#wp1517601
You can try explicitly setting the mss to a lower value. (For example, sysopt connection tcpmss 1200)
Run ping tests with the do-not-fragment bit set to determine what the largest non-fragmented packet size is that will successfully ping the remote site.
Also, run some ping tests to determine whether you have more packet drops for larger packets.
do you have any of these drops inside the network - NONVPN
you have a few significantly longer times in the capture
is this ASA to ASA tunnel?
what type of traffic is running across the tunnel
DPD - dead peer detection can lose some packets with tunnel failure
better - try VPN Monitor
or even vpnttg to better monitor with SNMP
you have a few significantly longer times in the capture
is this ASA to ASA tunnel?
what type of traffic is running across the tunnel
DPD - dead peer detection can lose some packets with tunnel failure
better - try VPN Monitor
or even vpnttg to better monitor with SNMP
ASKER
Darin I don't have any of these dropping in the non VPN network and hence my frustration. I also have AnnyConnect configured on the ASA and these are not experiencing these dropouts. The tunnel ios between an ASA and a Cisco router.
This ASA is a v 9.5 and I replaced an older 8.2. the 8.2 seemed to work well.
This ASA is a v 9.5 and I replaced an older 8.2. the 8.2 seemed to work well.
It is possible that the VPN is disconnecting and reconnecting, which breaks the stateful flows through the ASA.
Try adding the command sysopt connection preserve-vpn-flows .
You might try enabling some IPSec debugging to see if the VPN is having to rebuild itself.
debug crypto ipsec
Try adding the command sysopt connection preserve-vpn-flows .
With the persistent IPsec tunneled flows feature enabled, as long as the tunnel is recreated within the timeout window, data continues flowing successfully because the security appliance still has access to the state information in the original flow.
This command supports only IPsec LAN-to-LAN tunnels, including Network Extension Mode. It does not support AnyConnect/SSL VPN or IPsec remote-access tunnels.
You might try enabling some IPSec debugging to see if the VPN is having to rebuild itself.
debug crypto ipsec
Hi,
check for tunnel configuration if you have define Keepalive 3 2 which is default statement then remove the statement and try pinging as below :
ASA(config-t)#int tunn 0
ASA(config-t)#keepalive 3 2 (remove by simply typing no Keepalive 3 2)
This should solve the problem.
check for tunnel configuration if you have define Keepalive 3 2 which is default statement then remove the statement and try pinging as below :
ASA(config-t)#int tunn 0
ASA(config-t)#keepalive 3 2 (remove by simply typing no Keepalive 3 2)
This should solve the problem.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
show cry isa
and
show cry ipse sa
should tell you
Pete