I have a problem with a 3002 hardware client tunnel to a 3000 series concentrator - basically telnet/snmp etc work fine, but Remote Desktop Connection (RDP) fails nearly all the time.
This issue cropped up before, but we were able to fix it by modifying the fragmentation policy on the client.
This week the problem came back when we switched the VPN over to a different concentrator on a different site - I've checked over all the settings and nothing seems different. The only difference is that the version on the concentrator has changed from 4.1.? to 4.7
I see messages like the following:
Packet from 172.29.7.17/0, to 10.48.71.246/0, should be handled by existing sess
Which I understand indicate fragment problems - I've tried setting the client interface MTU to 1300 and tried the three fragment policies with no luck.
Curiously the software VPN client works OK, and any machines with it installed work ok - this is because the VPN client sets the MTU of all NICs to 1300.
I suspect that for some reason the client perhaps isn't fragmenting properly, or the concentrator isn't setting it's MTU to that of the client - is this how it's supposed to work? Should setting the client be sufficient?
Thanks for any tips/experience
Any worthwhile replies will be rated..
Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Re: 3000 Series VPN - MTU/fragment problem with RDP
Ability to choose whether or not large packet fragmentation is performed before or after encapsulation "pre-fragmentation" as well as whether or not the Concentrator responds to internal ICMP/PMTUD requests and requests an internal device to lower its MTU, or otherwise fragments the packet and clears the DF bit if set. The main reason that this will be a configurable option is due to the fact that specific service packets of Windows 2000 and some other OS's do not respond to PMTUD when the request comes from a client on the same subnet as the server. (Concentrator) 2. Ability to define a maximum Concentrator MTU < default of ~15XX bytes (Concentrator) 3. Adjusted setMTU behavior to fix specific NDISWAN/dial-up related issues that may presently require manual MTU adjustment workaround (Client) The setMTU application is needed on the client side regardless of anything on the Concentrator side Since the concentrator does fragment large packets, it would be interesting to know if you're seeing 1580 byte packets on the wire or the 1580 byte packet fragmented based on the Ethernet MTU of 1518.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :