Re: Strange PPPoe problem

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 24 Mar 2006 10:33:07 -0600
anoop aryal <aaryal@xxxxxxxxxxxxxxxx> wrote:

On Friday 24 March 2006 06:55 am, Jacob S wrote:
On Thu, 23 Mar 2006 14:35:20 -0600

anoop aryal <aaryal@xxxxxxxxxxxxxxxx> 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-----

Relevant Pages

  • Re: Strange PPPoe problem
    ... have PPPoe on my firewall. ... until it tries to download the mail (I see it login, ... sounds like icmp 3/4 packets are being dropped somewhere. ... firewall on the mail server is causing icmp 3/4s from reaching the mail ...
    (Debian-User)
  • Re: Strange PPPoe problem
    ... PING longbow.arroway.com 1472bytes of ... packets transmitted, 0 received, +1 errors ... mail server is causing icmp 3/4s from reaching the mail server. ... we can't do much about the firewall. ...
    (Debian-User)
  • Re: Hoeveel routing entries
    ... Why don't you use a firewall a correct antispam configuration ... for your mail server for this? ... This way the packets that are blocked ... problems related to performance of the routing table. ...
    (comp.os.linux.networking)
  • Re: iptables and dhcp
    ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
    (comp.os.linux.networking)
  • Re: Trouble accessing Outlook Web Access from behind firewall
    ... When starting the firewall I also set ... > rejected and dropped packets are logged, however I see nothing in my log ... > # Higher ports needed to accept incoming/outgoing calls ...
    (comp.security.firewalls)