|
||||||||
I have sent the following to Archie Cobbs of the MPD-list. -----Original Message----- 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 Hi Archie! 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: ***************************************** Brief: 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 of 1396. m0n0wall logs all traffic through PPTP-interface and WAN. Log shows 1400byte-packets incoming on PPTP-interface when trying to access e.g. web servers. m0n0wall sends an "icmp unreach/needfrag" back - to no avail. Log example: 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 Log explanation: 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 sessions. /Martin -----Original Message----- 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: > http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=44&actionargs[]=95 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 __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com |