[ previous ] [ next ] [ threads ]
 From:  <edp dot lists at acerbis dot it>
 To:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  R: [m0n0wall] R: [m0n0wall] VNC Problem
 Date:  Thu, 7 Oct 2004 15:05:35 +0200
I don't know which equipment is involved in your case, but my problem
scenario was like that:


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
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
4. The packet is too big to pass the ipsec link, and can't be fragmented so
R2Ipsec must generate
icmp frag request message....


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 )
To temporary lower rdp mtu of ethernet interface of the rdp server machine,
forcing it to generate packets less
than ipsec link
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:



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