-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 24 Mar 2006 10:33:07 -0600 anoop aryal <[EMAIL PROTECTED]> wrote:
> On Friday 24 March 2006 06:55 am, Jacob S wrote: > > On Thu, 23 Mar 2006 14:35:20 -0600 > > > > anoop aryal <[EMAIL PROTECTED]> wrote: > > > > > On Thursday 23 March 2006 10:58, Jacob S wrote: > > > > > >-----BEGIN PGP SIGNED MESSAGE----- > > > > > >Hash: SHA1 > > > > > > > > > > > >Howdy list, > > > > > > > > > > > >I recently changed ISPs, away from static ips on a dsl line > > > > > >to a > > > > > > single dynamic ip on Veriz*n's new Fi*S (fiber optic) > > > > > > service. The new service uses PPPoe - not a problem, or so > > > > > > I thought - I have PPPoe on my firewall. > > > > > > > > > > > >Now, I have used PPPoe from this very same firewall on a > > > > > >different dsl line before and it worked great. But for some > > > > > >reason when I do PPPoe for the new fiber line only http > > > > > >traffic works properly. When downloading e-mail, everything > > > > > >is fine until it tries to download the mail (I see it login, > > > > > >get the number of messages to download, and then it tries to > > > > > >start downloading). At this point the e-mail just hangs > > > > > >until it finally times out. It does not seem to be > > > > > >port-related, as I have setup the e-mail server with > > > > > >port-forwarding rules to allow me to download mail on > > > > > >non-standard ports and it exhibits the same problem. And if > > > > > >I do PPPoe on the provided D-Link router, instead of on my > > > > > >firewall, everything (including e-mail) works great. > > > > > > <snip> > > > > > > google PMTU to read about this in more detail, but it seriously > > > sounds like icmp 3/4 packets are being dropped somewhere. if you > > > setup your firewall to allow icmp packets of type 3/4 thru, you > > > should be all set (well, you'd hope so anyway). a set of rules > > > like so should do the trick: > > > > > > -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT > > > -A OUTPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT > > > -A FORWARD -p icmp --icmp-type fragmentation-needed -j ACCEPT > > > > > > then, make sure you have the iputils-ping package installed (not > > > the netkit-ping) and try: > > > > > > ping your.mail.host -c 1 -M do -s 1472 > > > > > > and you should get back an icmp reply saying what the mtu should > > > be. subtract 28 from it and try pinging with that size and it > > > should go thru. eg, if the reply says mtu = 1492, try: > > > > > > ping your.mail.host -c 1 -M do -s 1464 > > > > > > and it should go thru just fine. if you get a request timeout, > > > that means that some routers are just dropping your packets > > > without an icmp 3/4 message. keep reducing the size of your > > > packet and see if you can get anything thru. read up on PMTU for > > > possible solutions. there are ways to stop automatic PMTU > > > discovery etc. > > > > Ok, things are getting stranger here. > > > > I ran the iptables rules you suggested and here's the ping results: > > > > # 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? Thanks! Jacob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEJglskpJ43hY3cTURAnWGAKDoBk72Dmy6dFX8+xpz/WPEHifcfgCcDLs9 fQ4AplR+gsd5rVb+U4UoaBI= =4Jvh -----END PGP SIGNATURE-----
