I have sent the following to Archie Cobbs of the MPD-list.
From: Martin Holst [mailto:mail at martinh dot dk]
Sent: 31. marts 2004 11:57
To: 'Archie Cobbs'
Cc: 'mpd dash users at lists dot sourceforge dot net'
Subject: RE: [Mpd-users] Re: WinXP PPTP MRU problems
After looking through the IP-filter log of my own m0n0wall I am pretty sure
that m0n0wall does not block incoming fragments.
Have a look:
M0n0wall is configured with three interfaces DMZ, LAN and WAN
PPTP is used to secure wireless access from DMZ to LAN.
- PPTP access from DMZ to LAN is OK
- PPTP access from WAN to LAN is OK
- PPTP access from DMZ to WAN fails due to MTU-related problem.
WAN (ed0) is routed Ethernet with MTU 1500 - PPTP interface (ng1) has an MTU
m0n0wall logs all traffic through PPTP-interface and WAN. Log shows
incoming on PPTP-interface when trying to access e.g. web servers.
m0n0wall sends an "icmp unreach/needfrag" back - to no avail.
12:17:15.984233 ed0 @0:23 p 129.142.xxx.xxx,80 -> 192.168.xxx.xxx,3484 PR
tcp len 20 1400 -A K-S K-F IN
12:17:10.297090 ed0 @-1:-1 p 80.196.xxx.xxx -> 129.142.xxx.xxx PR icmp len
20 56 icmp unreach/needfrag for 129.142.xxx.xxx,80 - 80.196.xxx.xxx,5264 PR
tcp len 20 1400 K-S K-F OUT
12:17:10.296974 ng1 @0:23 p 129.142.xxx.xxx,80 -> 192.168.xxx.xxx,3484 PR
tcp len 20 1400 -A K-S K-F OUT
129.142.xxx.xxx - web server
80.196.xxx.xxx - my WAN
192.168.xxx.xxx - my PPTP client
To me it basicly looks like the ICMP request for fragmentation is
"overheard" by the webserver - since after five seconds it just sends
another 1400bytes packet instead of resending a fragmented packet.
You can see that none of the packets are blocked.
But then again... My networking knowledge is very mediocre. So I may be
reading the log wrong.
If you wish, I can send you a more detailed log with samples from different
From: Archie Cobbs [mailto:archie at dellroad dot org]
Sent: 30. marts 2004 20:45
To: Martin Holst
Subject: Re: [Mpd-users] Re: WinXP PPTP MRU problems
Martin Holst wrote:
> This particular post from the developer of m0n0wall explains the problem
> pretty good:
Thanks for the link. I don't know what the problem is, but "in theory"
MPD setting the MTU on an interface to any value *lower* than requested
by the peer is not a bug - M stands for maximum. In any case, if MPD did
not subtract the MPPC overhead then it would be non-compliant, because
it would be possible for a PPP frame larger than the peer's specified
MTU to be sent. As it turns out, this doesn't seem to cause problems as
apparently windows XP will still accept such a frame even though it
said it wouldn't, which is why the patch seems to workaround the problem.
However, lowering the MTU causes some packets to require fragmentation when
they otherwise would not be fragemented. This means: TCP path MTU discovery
might detect a difference, and IP fragments may get sent.
The most likely way I can imagine the presence of IP fragments causing a
problem is if there is some problem with the firewall/NAT setup that is
causing incorrect handling of ICMP 'need fragment' packets, IP fragments,
etc. I'm sure m0n0wall is more intelligently configured that that but
in the past firewalls have often been mistakenly configured to block all
IP fragments, or all incoming ICMP, or whatever, causing these sorts of
problems. For example, non-zero offset TCP packet fragments don't contain
TCP port numbers (they're only in the first fragment) and some broken
firewall configurations use this as evidence the packet should be discarded.
Another thing to try along these lines would be to enable the MSS-fixing
support in mpd if not already enabled.
Feel free to forward this email to the m0n0wall list along with my
apologies for the problems. All of the above is speculation on my part
as I haven't actually done any packet traces, so take with an appropriate
grain of salt.
Archie Cobbs * CTO, Awarix * http://www.awarix.com