|
||||||||
I don't know which equipment is involved in your case, but my problem scenario was like that: |client|-link_mtu1500-|R1Ipsec|-link_mtu1300-|R2Ipsec|-link_mtu1500-|RDP_Ter minal_Server| Link_mtu1300 was an ipsec tunnel, implemented by R1 and R2 firewall/routers, connecting two Ethernet segments. 1. Client has a local view of its connection, he queries its interface, see MTU size, so he will request a TCP MSS of 1460 (1500-40) while connecting to other hosts 2. Client want to connect to RDPServer, sends a SYN to it, with MSS set to 1460 during handshake. 3. Server generate a packet of 1500 octets containing data according to what he learned during tcp handshake, (nobody has lowered the mss during transit) with DF set and sends it to client 4. The packet is too big to pass the ipsec link, and can't be fragmented so R2Ipsec must generate icmp frag request message.... *BUT* R2Ipsec implementation / configuration was broken, so such ICMP message got filtered, never arrived to the server, resulting in a communication stall. the workaround solution was to on-the-fly lower MSS when the client packet reached R1Ipsec before encapsulation ( this is possible only if R1Ipsec is also the encapsulating machine, the protocol is TCP and the packet is not already crypto signed in some way ) Or To temporary lower rdp mtu of ethernet interface of the rdp server machine, forcing it to generate packets less than ipsec link Or disable PMTUD on the server, assumed that fragmentation works on the communication path. Of course this wuold never happened if PMTUD discovery worked correctly, with not buggy implementations/configurations. A general summary document on the subject: http://www.cisco.com/en/US/products/hw/routers/ps4081/products_tech_note0918 6a0080094268.shtml Bye .FT -------- Original Message -------- > Maybe your problem was due to MTU differences, fragmentation and > incorrect handling of icmp messages ( it happened to me in the past > that a mtu problem prevented me to connect to a terminal server rdp machine through tunnels). > Do you mean I should change by hand the MTU on each workstation and server on both subnets? Did you try to do that to solve your problem? If yes, did it work fine after? I really hoped I could avoid changing the MTU on every computer, but I might give it a try... I suspect Microsoft TCP/IP stack does not handle ICMP messages very well. To all: feedback on that topic is welcome! I must not be the only one with that (possible) MTU problem... -- Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch |