Re: Strange PPPoe problem
On Thursday 23 March 2006 15:35, anoop aryal wrote:
>On Thursday 23 March 2006 01:13 pm, Jacob S wrote:
>> On Thu, 23 Mar 2006 12:27:26 -0500
>>
>> Gene Heskett <gene.heskett@verizon.net> 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.
>> >
>> > Then I suggest you use it, as, provided you replace the d-link
>> > with a linksys, something like a BEFSX41, you'll also have a very
^BEFSR41^
>> > good firewall for free AND it will all Just Work(TM). I spent 2
>> > weeks trying to make rp's PPPoE for linux work but like you, way
>> > too many things just didn't work.
The above model number is wrong, thats the one I had a 2+ week headache
with, its the BEFSR41 that I had intended to type above, sorry for the
confusion.
>> > The security of the d-link product has been questioned at length
>> > on the lists, and I can testify that the seimans speedstream
>> > product is likewise rather poor, it was owned and trashed here
>> > inside of 2 weeks, with outside config access supposedly denied
>> > from the WAN ports.
>> >
>> > My linksys has let someone by just far enough to make a log entry
>> > as they were being dropped by a combination of portsentry,
>> > tcpwrappers, and iptables, 3 times in 3 years, 2 of which came
>> > from known sources when one of vz dns servers was owned and
>> > attacked me. The third one came from a chinese address block and
>> > didn't get any farther that the log. For 3 years of 24/7/365 dsl
>> > service, I think thats very good security indeed.
>>
>> Thanks, but I'd rather keep playing with Linux to figure out why
>> it's not working
>
>i would too. ;)
>
>> than dump more money into the problem. My solution to this
>> point is using my firewall as the only computer connected to the
>> D-Link router. It works pretty well this way, but it means I'm stuck
>> with their "firewall" on the router, instead of having full control
>> from my Linux firewall.
>
>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.
I am not now having icmp problems, and I am using the same basic
firewall rules as before, only modified for the fact that azeurus is
running for FC5 ATM.
However, one of the reasons I specified the routers model number was
that I have tried one of their newer ones that supports vpn, and there
is no way in hell to get an icmp ping thru that later BEFSX41 router.
You must use a udp ping, and even thats kludgey because its not that
well supported at many sites. At linksys's instructions, I tried 5
different firmware images in the BEFSX41 without getting the
transparency I expected. That is a correction from my original post as
its the BEFSR41 that is 100% transparent, and the BEFSX41 that is badly
borked IMO.
From the results I was not getting when running rp's PPPoE I have to
assume that its filtering icmp, and possibly even some udp. Thats
unacceptable to this admittedly chrochety old fart.
>hope it helps.
>
>anoop.
>
>> Jacob
>
>--
>
>
>anoop
>aaryal@foresightint.com
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Reply to: