Thanks for the comments on problems you are experiencing. I did not receive a response to any of the previous messages I sent you, so I have copied the Bugtraq list, in case you do not receive email sent to your reply to address. In general, the best way to report product problems is to open up a case with the Cisco TAC (Tech Support) and our TAC will work with you to go through your issues and help find a resolution. If you open a TAC case in the future and you aren't satisfied, you should feel free to ask for the case to be escalated. Any problems that are found will have bug IDs assigned to them so that we can track and fix them for you as soon possible. All open bugs are visible by all customers in our Bug Tracker tool on cco.cisco.com. Security related items are handled through our PSIRT group (psirtat_private), which helps coordinate getting a fix and response out as soon as possible including distribution of information to Bugtraq and various other mailing lists. Since your issue report appears at first glance to be problem related, I will do my best to help respond. If you have specific questions or additional information, please feel free to drop it to me directly and we will work to help you resolve problems you are experiencing. If you a specific support case #, please attach this in your email to me as well. This information will help to make sure that we have all the details on your specific environment so that if you have found a new problem, we can ensure it is corrected ASAP. Our next release will offer some additional nice enhancements regarding fragmentation, Path MTU Discovery (PMTUD) and Client MTU determination. Specifically- 1. 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. In most cases (and we strive for all), running it manually should be unnecessary. There are some enhancements with our next release that fix a couple of specific dial-up/NDISWAN issues on the client side. If you are interested in specifically trying out our new release and providing beta feedback as to whether or not your problem is resolved or would like us to help to resolve your issues, you can feel free to contact me directly. 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. In order to investigate and resolve the problems you are reporting, please send me information concerning your application/environment, MTU on the Client, Concentrator configuration, device on the public side of the Concentrator exhibiting problems and a sniffer trace showing 1580 byte packets on the wire or other problems you are seeing. I look forward to hearing back from you so that we can help resolve your problems. Best Regards, -Pete Davis Cisco Systems, Inc. (508) 553-6007 <ATTACHMENT> Cisco VPN3000 gateway MTU overflow ================================== Bug class: Conceptual/bad protocol implementation Equipments affected: Cisco/VPN 3000 Concentrator with software vpn3000-3.5.Rel-k9.bin FACTS The Cisco VPN3000 gateway lets remote client dictate which maximum MTU to use when sending back ESP frames, regardless of the transmitting capabilities of the physical medium. IMPACT * Oversized frames get silently discarded by equipements linked to the gateway's public interface and retransmissions occur. * Other disturbances or DoS against neighboring equipements may occur, especially as many IP stacks on routers and sniffers etc ... are poorly implemented. DETAILS We have witnessed this phenomena after establishing tunnels with the "VPN dialer" over a modem connexion: when the target sends back ethernet frames with size close to the max ethernet MTU (1500), the gateway encrypts the frames adding ESP headers and stupidly tries to send a 1580-bytes frame back to the client. RESOLUTION -> From the official documentation there is no way to enforce a maximum MTU on the VPN gateway. -> Hence: a gateway software patch by Cisco is necessary: if MTU negociation occurs, the gateway should set a max-MTU threshold (the physical medium's !). PSEUDO WORKAROUNDS * client side: For Windows-based OS (likely Unix and Linux-based OS too), Cisco released a tool called setMTU.exe that can prevent ill MTU negociation from happening. * target side: artificially lowering the max MTU on the interfaces. -> But such a policy is not acceptable: The VPN client, as well as remote targets, should not have to be aware of the gateway's interface configuration ! The bug does not lie in client software, but in the gateway's software. Master Phi </ATTACHMENT>
This archive was generated by hypermail 2b30 : Mon Jul 15 2002 - 09:30:01 PDT