Hi guy, I have a masqueraded machine(+orkit modem) with 5 computers behind it with ppp0 MTU 1452, eth MTU 1500, no changes on the MTU on the client machines, MSS rule on the iptables ($IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu) for 6 months. believe me, i and 4 more people went up and down the internet and there are no problems what so ever. Don't change nothing in the howto. The only reason you don't need mss rule or mtu 1452, is if you have alcatel modem, which works most of the time without it. other than that leave the HOWTO alone.
p.s: i have kernel 2.4.4 (works great, no problems for about 8 months already). iptables 1.2.4, though i worked with almost all of the netfilter earlier versions and for most uses there weren't any significant problems, in fact i used it since kernel 2.3.33, and i it worked fine. p.p.s: i masqueraded with crosswired to the hub/straight to the modem+eth to hub/crosswired+eth to another hub segment and there weren't any problem with MTU or anything else, and no need to change any MTU configs at the clients.(cz of the MSS rule of course) (no changes of MTU on any of the eths, only the ppp0 which is automatically done using the pptp+pppd command). * - * - * Tzahi Fadida [EMAIL PROTECTED] Fax (+1 Outside the US) 240-597-3213 * - * - * - * - * - * -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of guy keren Sent: Wednesday, January 09, 2002 2:41 PM To: Ira Abramov Cc: IGLU Subject: Re: Solved: https(443) and ADSL/masquerading On Wed, 9 Jan 2002, Ira Abramov wrote: > personally, my MTU is set at 1452, and also forced to re-fragment in the > iptables: > > $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu > > no idea if it helps, but it doesn't hurt :) lets try to guestimate why this is indeed the solution, and yet why eli's change also works: 1. if you set the MTU of ppp0 to 1452, while that on the ethernet card on the masquareded computer is higher, then that machine, under some protocol, might send packets which are larger then the MTU of 1452, and thus cause fragmentation. as was said in the past, _some_ of the adsl modems have a bug with handling of fragmented packets(?), or some router(s) on the way blocked the DONT-FRAGMENT ICMP message, causing such fragmented packets to be lost. in any vent - this problem wasn't identical for every person and towards every server even in the past. i would suggest that the ttps packets eli's winME tried to send ineed got fragmented - this could be verified with a sniffer, to see that one (or more) of them was larger then the 1452 MTU allowed. eli - do you wish to run such a sniffer, or otherwise, anyone else that has set their MTU to 1500, and know eactly which service to which host failed to work before this change? 2. ira (like others did) has set a rule in ipchains to set the MSS (maximum segment size, for TCP connectins) to the PMTU (path MTU - i think its the MTU found during 'MTU discovery', and surely not greater then the MTU of the linux machine's outgoing interface for the connection, which is ppp0). hence, this will make sure masqueraded hosts, even if they have an MTU of 1500, don't send packets whose IP data exceeds 1452 bytes (this including the IP header). 3. it _could_ be that even without it, the mere fact that ira uses 're-fragmentation' (which, as i remember, was a requirement for any masquerading linux machine, back in 2.2 kernels - have that changed) would have caused any fragmented packets to be de-fragmented before sent again. however, if the next hop is still too small - they will also be re-fragmented (as far as i can see), so this only helps for incoming pakcets, not for outgoing ones. btw, the reason for this de-fragmentation is to allow rules handling upper-level protocols (i.e. protocols above the IP layer) to be handled properly for the full packet, since the IP fragments do not contain the TCP data of the packet). eli (or someone else with a similar problem) - could y'all check if you have the MSS-handling rule, and if not - add it, and try reducing the MTU back to 1452 on the ppp0 interface, to check if practice falls withing these theories? i know that you don't personally care since your own problem(s) were solved, but to get the howto fixed, we need input. i don't have any masqueraded host at home, so i cannot make such test. -- guy "For world domination - press 1, or dial 0, and please hold, for the creator." -- nob o. dy ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] ================================================================To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
