Hi Andrew,

Thanks for your reply!

A couple of more questions:

Would changing the maximum segment size to 1200 not have any negative performance impact for the users that do not have a problem with fragmentation today?

Is the MTU setting of 1380 a good value for the outside inteface?

Thanks again for your help!

Best regards,

Harry

OK to answer your questions:-

"Would changing the maximum segment size to 1200 not have any negative performance impact for the users that do not have a problem with fragmentation today. 99% of the time is the fact that a higher MSS is negotiated, with the DF bit set = the fragmentation issue most common. Some apps/services will receive the "fragmentation required" icmp message and IGNORE it. So the easiest way I have found is to have the clients negotiate a lower MSS = lower overall MTU. Then the clients can send what they like with the DF bit set, and ignore ICMP "frag required" messages all day long and it will all work!

"Is the MTU setting of 1380 a good value for the outside interface?" personally - no. If you are directly connecting to say an ATM device then yes, as this is the optimum/recommended MTU size. If you are given an Ethernet RUJ45 connection from your provider I would use an of MTU 1500....BUT take into consideration everything else you are trying to do.

if you have an MTU of 1500 and you have IPSEC and run IP and TCP:-

IPSec Header/encryption 56 bytes

IP Header 20 Bytes

TCP header 20 bytes

So far 96 bytes = so the MAX data Payload is 1404. With a client NIC that has an MTU of 1500 - it will take the TCP/IP header off and try to negotiate a MSS of 1460 bytes = possible fragmentation issue.

At the end of day in my personal opinion - you have to keep the network running at 100% and healthy, it's no good if the users can send/receive the max amount of data per packet if it breaks the network?

HTH>

What kind of issue is your client having? I'm having an issue where the clients are freezing up while they're using the application, even though the tunnel status is up, after a few seconds they're back to normal. This happen intermittently. Cisco suggested setting the DF to on and adjusting the tcpmss to 1280. My outside Interface is still set to MTU size 1500. I did all that and I'm still having the same problem. Is you issue similar to mine, and did any of these suggestions help you at all?

Thanks.

Hi,

A limited number of users were having problems connecting to some web sites and using Outlook. We did not see any clients freezing.

We enabled clear-df on the outside interface and set the TCPMSS to 1260. We did not modify the MTU on either interface. This fixed our issue.

Best regards,

Harry

Thanks for your reply. Currently I have the TCPMSS set to 1280 and clear-df on the outside is also enabled. I will try to lower the TCPMSS to 1260 hopefully I'll have a better results. I'm also planing on upgrading the ASA to the latest software image 8.04(23). I currently have the 8.0.3(6).

I have to jump in here - let me ask you, why are you upgrading from 1 ED image to another ED image? What extra functionality does 8.04(23) have that 8.0.3(6) does not?

Using an Early Delopyment image could be the reason for your issue - upgrading might solve 1 issue - but generate 10 more.

I've had a TAC case open with Cisco for a long time and we've exhausted a tremendous amount of troubleshootings packet captures and so forth. Then it got escalated to a higher level and was decided to upgrade to the latest image before proceeding with any troubleshooting steps.

Have you thought about downgrading to ver 7.2(x) which is an extremley stable ver?

I had this issue today. After adjusting the MSS value the application in Azure started responding to the wireless scanners. Thank you !!

What is the MTU on the client machines set to - by default ANY machine that the cisco VPN client is installed on defaults to a MTU of 1300 and ALL subsequent MSS neogitiations noeogitate to a MSS of 1260.

HTH>

The client machines are PCs running WinXP Pro. The Cisco VPN client is running with default configs.

However, these same client PCs have VPN settings to connect to our VPN 3000 concentrators, and they work without any problems. The problem appears to be specific to the tunnel into the ASA.

The ASA can ping to the Outside router, as well as any Inside device, with packet sizes up to 1500, without problems.

When I try to telnet from the VPN client machine to a device on the Inside, it appears that the connection is established, as 'netstat' on the client machine shows an established connection. Running debug ip packet on a router also shows the incoming connection. However, something (the MTU limitation?) does not allow a login prompt to be received by the VPN client machine, and the connection will eventually time out.

I suspect something in the ASA is the problem, but cannot identify what it may be.

-rb

Found the problem. Compression was enabled under the default group policy:

group-policy DfltGrpPolicy attributes

banner none

wins-server value 10.200.6.190 10.200.6.191

dns-server value 10.200.6.190 10.200.6.191

dhcp-network-scope none

vpn-access-hours none

vpn-simultaneous-logins 3

vpn-idle-timeout 30

vpn-session-timeout none

vpn-filter none

ipv6-vpn-filter none

vpn-tunnel-protocol IPSec webvpn

password-storage disable

ip-comp enable <----------

Changing this to disable made the difference. Disable is the default.

Hope this helps someone.

-rb