Re: Strange PPPoe problem
On Saturday 25 March 2006 09:24 pm, Jacob S wrote:
[snip]
> > > # ping longbow.arroway.com -c 1 -M do -s 1472
> > > PING longbow.arroway.com (66.252.129.166) 1472(1500) bytes of data.
> > > From pool-71-244-52-50.dllstx.fios.verizon.net (71.244.52.50)
> > > icmp_seq=1 Frag needed and DF set (mtu = 1492)
> > >
> > > --- longbow.arroway.com ping statistics ---
> > > 0 packets transmitted, 0 received, +1 errors
> > >
> > > # ping longbow.arroway.com -c 1 -M do -s 1464
> > > PING longbow.arroway.com (66.252.129.166) 1464(1492) bytes of data.
> > > 1472 bytes from longbow.arroway.com (66.252.129.166): icmp_seq=1
> > > ttl=49 time=163 ms
> > >
> > > --- longbow.arroway.com ping statistics ---
> > > 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> > > rtt min/avg/max/mdev = 163.150/163.150/163.150/0.000 ms
> > >
> > > So then I added the line
> > > pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1464"
> >
> > no, the mtu is 1492. you use 1464 in the ping because your are
> > specifying the ping payload. the total packet size ends up being
> > 1464+28 = 1492. (which is what you had to begin with.) all is not
> > lost, we know PMTU works on your end provided you leave the three
> > iptable rules mentioned above. it seems like a firewall on the mail
> > server is causing icmp 3/4s from reaching the mail server. we can't
> > do much about the firewall. ie, the mail server replied with packets
> > with size = 1500 (most likely) with DF set, the other endpoint of
> > your DSL sent back an icmp 3/4 message back to the mail server to
> > send smaller packets, the firewall protecting the mail server dropped
> > it and the mail server never knew to send you packets of 1492 or less.
> >
> > there is a 'hack' that may fix this. try and put this in your ruleset
> > in the *mangle table (assuming your dsl interface is ppp0):
> >
> > -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS
> > --clamp-mss-to-pmtu
> >
> > or use this from the command line if you don't already have the
> > *mangle section:
> >
> > iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o
> > ppp0 -j TCPMSS --clamp-mss-to-pmtu
> >
> > what this does is sets the mss of the initial SYN packet to pmtu -
> > 40. the reciever (the mail server in this instance), then, uses the
> > mss to calculate the reply packet size instead of the default of
> > 1500. by doing this it would have created packets of the right size
> > (1492) and therefore doesn't need PMTU to work.
> >
> > again, the above rule is in addition to the previous three.
>
> Very nice! That time it worked. E-mail downloaded sucessfully several
> times now. :-) I'll add those 4 lines to my firewall script.
>
> The mail server I'm downloading from is also a Debian machine... where
> I have root access (even though it's not my own server). Is there
> anything I should (can?) change in it's iptables firewall so that other
> users don't have to fuss with this kind of a problem?
apply the first three rules on the mail server.
drop the fourth rule from your (home?) linux box. if you apply the first three
rules to the mail server, the whole thing should work without the fourth
rule. the fourth rule is a hack to make it work when the firewall on the
other end drops icmp 3/4 messages. or you can leave it in... shouldn't really
hurt.
full explanation follows:
ok, what you want to do is basically repeat the ping process but from the
opposite end.
now, you want your mail server getting the icmp 3/4 replies from your DSL
providers router.
in the diagram below:
A -------- B ---------X---------[cloud]------------- C --------------- D
let's say A is a client on your internal network. B the linux box where you
have the iptables, C is the firewall protecting your mail server. and D is
your mail server. note that A and B can be the same machine (the first three
rules will have removed the distinction for our purposes.) and C and D can
also be on the same machine... X is the other point in your dsl line (some
router owned by your DSL provider).
any how, what needs to happen is that when you ping with a packet size of 1500
from D to B (remember to subtract 28; just do what you did before but from
the opposite end), you should get an icmp 3/4 from X to C, and C needs to let
it thru to D. apply the first three rules to let icmp 3/4 thru in C. and ping
again from D and see if you get "frag needed" messages back to D. if you do
get the messages, you're done. if not, you'll need the clamp-mss rule since
someone else is the PMTU black hole and you can't do anything about it.
if you can get the icmp reply thru from X to C to D, you can discard the
"clamp-mss" rule in B. or leave it in. because the whole purpose was to let D
know that the link between B and X is 1492. you can let that be known by B
initiating the connection with a suggestion to D on how big the reply should
be. Or, you can let D find out about the 1492 link between B and X via the
normal process of PMTU by letting icmp 3/4 thru in your firewall so that D
can receive the icmp messages coming from X.
hope that clears it up for you. let me know if you have questions.
--
anoop
aaryal@foresightint.com
Reply to: