cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
610
Views
0
Helpful
3
Replies

3000 Series VPN - MTU/fragment problem with RDP

Aaron Harrison
VIP Alumni
VIP Alumni

Hi

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

ion!

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..

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
3 Replies 3

a-vazquez
Level 6
Level 6

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.

bfeeny
Level 1
Level 1

Did you ever resolve this? I would be interested in knowing what you did to fix it?

Hi

Not really - well, kind of....

There is definately an issue with some device between the vpn endpoints, however we've been unable to get the third party to fix it, or configure the 3002/3000 conc to work around it.

As it happens, the 3002 client is now on a PIX DMZ, so we have set the sysopt tcp mss to 1300 and this works around it.

It's annoying that the concentrator or client can't do that though.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: