Re: [Openvpn-users] Windows client, mysterious routes and MTU issues

["John A. Sullivan III" <jsullivan@xxxxxxxxxxxxxxxxxxx>]

On Mon, 2006-02-06 at 14:52 +0000, Erich Titl wrote:
> John A. Sullivan III wrote:
> ..
> > 
> > <snip>
> > The Windows client requests an MSS of 1460:
> > Transmission Control Protocol, Src Port: 1349 (1349), Dst Port: 22 (22),
> > Seq: 0, Ack: 0, Len: 0
> >     Source port: 1349 (1349)
> >     Destination port: 22 (22)
> >     Sequence number: 0    (relative sequence number)
> >     Header length: 28 bytes
> >     Flags: 0x0002 (SYN)
> >     Window size: 16384
> >     Checksum: 0x7b77 [correct]
> >     Options: (8 bytes)
> >         Maximum segment size: 1460 bytes
> >         NOP
> >         NOP
> >         SACK permitted
> 
> OK, this is the syn packet
> 
> > 
> > Then the OpenVPN server replies saying the MTU is 0:
> >     Type: 3 (Destination unreachable)
> >     Code: 4 (Fragmentation needed)
> >     Checksum: 0x133e [correct]
> >     MTU of next hop: 0
> 
> This is a bit premature, can you correlate this packet with the previous
> TCP request? What are the source and destination addresses for this packet.
Exactly.  That's the mysterious problem.  I double checked the ICMP
packet just in case and the source address in the returned header is
172.20.98.2 and the destination 10.7.254.1 - exactly the same as the SYN
packet.  I've reproduced the scenario many times with different devices
and the packet sequence is always the same.
> 
> > 
> > Then destination replies that it wants an MSS of 1368:
> > Transmission Control Protocol, Src Port: 22 (22), Dst Port: 1349 (1349),
> > Seq: 0, Ack: 1, Len: 0
> >     Source port: 22 (22)
> >     Destination port: 1349 (1349)
> >     Sequence number: 0    (relative sequence number)
> >     Acknowledgement number: 1    (relative ack number)
> >     Header length: 28 bytes
> >     Flags: 0x0012 (SYN, ACK)
> >     Window size: 32440
> >     Checksum: 0x364d [correct]
> >     Options: (8 bytes)
> >         Maximum segment size: 1368 bytes
> >         NOP
> >         NOP
> >         SACK permitted
> 
> And this baffles me, as it appears to be the correct SynAck Packet for
> the TCP request. So my main question is, why do you get a SynAck for a
> connection which was rejected beforehand with an ICMP type 3
> (destination unreachable) message? For my understanding there is
> something amiss here.
Yes - exactly. Now I just need to find what it is.
> 
> > 
> > Why am I getting an MTU request of 0 from the OpenVPN server? 1500 byte
> > pings pass fine.  I would expect that PMTU-D should work:
> 
> Mhhh.... your ICMP messages may not have the DF bit set....
ping -f -l 1472 10.7.254.1
In fact, my original test was to set up a continuous ping like this.  As
soon as I attempted a TCP connection, the replies stopped and I received
a need to fragment error message - right in midstream.

I'm still digging away.  I set up an almost duplicate environment on the
same Xen host and, to my shocked surprise, with virtually identical
configuration files, there was no problem!

The one difference is the relaying of the decrypted packets through an
ipsec WAN.  I'll try that next.  Thanks for your help - John
> 
> cheers
> 
> Erich
> 
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@xxxxxxxxxxxxxxxxxxx

Financially sustainable open source development
http://www.opensourcedevel.com


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users