Very Computer

Hello,

I'm using a PIII machine running RedHat Linux 7.1 as a firewall and
gateway to a DSL connection.  I have recompiled the kernel to use IP
masquerading, and I have setup IP masquerading for the internal
network using iptables with the specifications published in the linux
HOWTOs.

The machine belongs to a coworker, who has SBC ameritech.net dsl
service at home.  He has connected the linux machine to the service,
and he can access the internet from the linux machine itself.  When he
connects his internal network to the other network card in the linux
machine, the internal network can see the linux machine (I have samba
running on the linux machine), but the internal network cannot see the
internet.

We have DSL.net service at my office, and I connected the linux
machine to the DSL.net service and everything worked fine - both the
linux machine and the internal network connected to the linux machine
could see the internet.

So, I'm not sure where else to turn.  Could there be some limitation
in the ameritech.net service that makes it more difficult or
impossible to run a network?  The ameritech.net service is ADSL, and
the connection is made through PPPOE.  The DSL.net service is SDSL,
and the connection is just plain old TCP/IP ethernet networking.
Those are the only differences apparent to me.

Any help is appreciated,
KS

PPPoE is out of my area of expertise (straight TCP/IP on the DSL here), and
admit to being little more than a Linux (Mandrake) newbie, so this may be
wrong.  However, it's worth a shot, and you DID say ANY help.

I believe the PPPoE interface is different than the straight Ethernet
interface.  I know that is how it works on Windows, anyway -- the two are
separate logical interfaces even if they use the same physical interface --
and believe it is the same on Linux.

Assuming that is correct, your NAT/masquerading is evidently set to support
the ETH interface rather than the PPPoE interface.  That is why it worked
with straight TCP/IP.  The Linux machine itself works fine on the PPPoE
interface, but since the masquerading is on the straight Eth interface, not
on the PPPoE one, the connection isn't being shared.  Fix that, and I think
your problems will go away.

BTW, there is a fairly new IPTables vulnerability, you will probably want
to be aware of, and you may need to update your kernel to fix it.  It has
to do with the IPT IRC component, and involves kernels 2.4.14-2.4.18-pre9.
Here's a link: http://news.com.com/2100-1001-848467.html .

--
Duncan - If posted to usenet, usenet replies get priority.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

Would the MSS have to be reduced from 1500 to 14something, either on the
gateway or the computers that connect through it, when using PPPoE?

-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----

Quote:> Hello,

> I'm using a PIII machine running RedHat Linux 7.1 as a firewall and
> gateway to a DSL connection.  I have recompiled the kernel to use IP
> masquerading, and I have setup IP masquerading for the internal
> network using iptables with the specifications published in the linux
> HOWTOs.

> The machine belongs to a coworker, who has SBC ameritech.net dsl
> service at home.  He has connected the linux machine to the service,
> and he can access the internet from the linux machine itself.  When he
> connects his internal network to the other network card in the linux
> machine, the internal network can see the linux machine (I have samba
> running on the linux machine), but the internal network cannot see the
> internet.

> So, I'm not sure where else to turn.  Could there be some limitation
> in the ameritech.net service that makes it more difficult or
> impossible to run a network?  The ameritech.net service is ADSL, and
> the connection is made through PPPOE.  The DSL.net service is SDSL,
> and the connection is just plain old TCP/IP ethernet networking.
> Those are the only differences apparent to me.

I am on ameritech.net adsl and setting up firewall or masquerading for
pppoe is very easy (just like a dialup ppp connection).  The eth that
carries pppoe is just a conduit, so any IP used to bring it up is not
really used and should be an IP not on any other network to avoid routing
conflicts (I use netmask 255.255.255.255 since that IP doesn't go
anywhere).  You need to masqurade anything going from the LAN out ppp0
(just like dialup).  /etc/ppp/options should be empty except for pppoe
related options (I cp'd my options to options.ttyS3 for my telephone
modem).

Note that the eth carrying pppoe should be default mtu 1500, but pppoe has
an 8-byte header, so all internal nics should be set to mtu 1492 or lower
to minimized fragmenting in case of mtu discovery problems.  To initialize
anything when pppoe goes up or down use /etc/ppp/ip-up.local,
ip-down.local.

Also note that atech does not block any ports, so you should make sure
that hosts.allow, hosts.deny and firewall block anything from the internet
that you don't want tampered with.

I am running SuSE 7.3 on a K6-2/400 and kernel pppoe seems to run more
efficiently (less cpu load) than rp-pppoe launched from tkpppoe with its
fancy graphs.  I have successfully connected a vpn in through adsl to my
LAN using FreeS/WAN (from Linux and SSH Sentinal in Win98).

A good source of broadband info is the forums at
http://www.dslreports.com/

--
David Efflandt - All spam ignored
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://www.nsscc.com/ - free driver school Friday nights in March

I appreciate all of your comments, they are very useful.  Of course, I
have more questions now -

You are correct, I was masquerading to the external interface (eth1)
instead of the ppp interface (ppp0).  Can I simply change all of my
filtering rules from eth1 to ppp0?  Or do I still need to filter out
packets coming into eth1?  I worry a little about completely ignoring
eth1 - although it doesn't have an actual ip address indicated by the
output from /sbin/ifconfig:

eth1      Link encap:Ethernet  HWaddr 00:50:BA:B6:A1:FC  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2158 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:9

Also, what is the P-t-P value in the ppp0 section:

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:66.72.166.40  P-t-P:66.72.160.1
Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3

I apologize for not knowing much about ppp.  When we dialed in to the
internet, we naively thought that we were relatively safe because of
the slow connection and I never set up firewall rules until we got
dsl.

Thanks again,
KS

Ah, apologies again, I thought of another question.  I'm confused
about setting the MTU on the windows machines on the lan.  The few
websites that I've visited concerning this talk about setting the MTU
value in the PPPOE configuration on the windows machine.  But I don't
think I want to be using PPPOE on the windows machines, if the linux
machine is.  Am I right?  The internal network is simple tcp/ip over
ethernet, routed to the internet through eth0 of the linux machine.
So I don't understand why I would need to run pppoe on the windows
machine.

Either way, how do I set the MTU on the windows 98 machine?

Thanks,
KS

The MTU on the client Machines generally needs to be lower then the MTU on
the server, if the server is PPPoE based.  So your server should be 1492, so
the client PCs can be 1472 and they should be just fine.

--
Bob
http://www.carricksolutions.com - The largest PPPoE Help Website, including
EnterNet, WinPoet, MacPoet, Access Manager, RASPPPoE, & Networking

Quote:> Ah, apologies again, I thought of another question.  I'm confused
> about setting the MTU on the windows machines on the lan.  The few
> websites that I've visited concerning this talk about setting the MTU
> value in the PPPOE configuration on the windows machine.  But I don't
> think I want to be using PPPOE on the windows machines, if the linux
> machine is.  Am I right?  The internal network is simple tcp/ip over
> ethernet, routed to the internet through eth0 of the linux machine.
> So I don't understand why I would need to run pppoe on the windows
> machine.

> Either way, how do I set the MTU on the windows 98 machine?

> Thanks,
> KS

Quote:> I appreciate all of your comments, they are very useful.  Of course, I
> have more questions now -

Like I said eth1 should remain default mtu 1500 (to carry 1492 pppoe + 8).  
'ifconfig' (or maybe variable for network start scripts) can change it for
eth0 for LAN.  For Win see http://www.dslreports.com/faq/578
Note that Linux already has good default tcp receive window, but Win is
usually too small.

Quote:> You are correct, I was masquerading to the external interface (eth1)
> instead of the ppp interface (ppp0).  Can I simply change all of my
> filtering rules from eth1 to ppp0?  Or do I still need to filter out
> packets coming into eth1?  I worry a little about completely ignoring
> eth1 - although it doesn't have an actual ip address indicated by the
> output from /sbin/ifconfig:

Since it has no IP you should not have to worry about it.

Quote:> eth1      Link encap:Ethernet  HWaddr 00:50:BA:B6:A1:FC  
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:2121 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2158 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:100
>           Interrupt:9

> Also, what is the P-t-P value in the ppp0 section:

That is the router on the other end of pppoe (should automatically be your
default route in 'route -n' output).

Quote:> ppp0      Link encap:Point-to-Point Protocol  
>           inet addr:66.72.166.40  P-t-P:66.72.160.1
> Mask:255.255.255.255
>           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
>           RX packets:188 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:224 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:3

> I apologize for not knowing much about ppp.  When we dialed in to the
> internet, we naively thought that we were relatively safe because of
> the slow connection and I never set up firewall rules until we got
> dsl.

> Thanks again,
> KS

--
David Efflandt - All spam ignored
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://www.nsscc.com/ - free driver school Friday nights in March

I'm curious as to why the MTU used for the masqueraded hosts should be
lower.  A 1492 MTU is 20 octets less than the 1492 that accomodates the
8 extra octets beyond the standard Ethernet frame that PPPoE requires,
which would seem to be all that those hosts should need too.

Is it related to something about IP masquerading that I don't know about?

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* To extract lines:  View file with "vi -R".  Move cursor to first line.
   Press "v".  Move cursor to mark lines (Esc unmarks).  Write lines to
   fubar with ":w fubar <Enter>".  Exit with ":q <Enter>". */

One of these should be 1472 ... no??

Quote:> 8 extra octets beyond the standard Ethernet frame that PPPoE requires,
> which would seem to be all that those hosts should need too.

If you don't allow for the extra PPPoE bytes you might be causing
packets to fragment? Then somewhere along the line things might not
get handled quite right??  Just a guess.

Paul

--
The lotto must be rigged, I should have won by now.
Modular furniture is cruel and unusual.

On Fri, 08 Mar 2002 16:03:57 GMT, Paul Newhouse

Yea, and that is exactly 8 bytes total. The question is why allow for
more than PPPoE's 8 bytes. I've never seen 1472 recommended. I have
seen 1452, which IIRC is the ethernet frame header+PPPoE header. I
never understood why that was needed. Awaiting clarification ....

--
Hal Burgiss

Blush!  Yes, the first one.

Quote:>> 8 extra octets beyond the standard Ethernet frame that PPPoE requires,
>> which would seem to be all that those hosts should need too.
> If you don't allow for the extra PPPoE bytes you might be causing
> packets to fragment? Then somewhere along the line things might not
> get handled quite right??  Just a guess.

I don't know what the extra octets are for, that's why I'm asking.
Twenty octets is the header size for IP datagrams but that header is
already included in the PPPoE encapsulated PPP frame.

--

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* Speak softly and carry a +6 two-handed sword. */

Actually it was 1472 that someone suggested, but I am not sure why either.  
The way to test max mtu is to determine the largest ping data size that
will pass without fragmenting (if your ping has that option) and then add
28 to get maximum mtu.

From a masqueraded internal box I had no trouble doing:
ping -c4 -M do -s 1464 www.dslreports.com

Anything bigger and it would fragment over pppoe.
ie, 1464 + 28 = 1492 max mtu for LAN.

I saw one theory that explained why 1454 would be optimum because once it
got to the ATM it would be sending 30 full atm packets for every tcp
packet instead of 31 with 1 partially empty.  But I have not seen actual
evidence of that.  All actual tests seem to indicate that bigger is
better, short of fragmenting.  So maybe atm packets are split and
assembled at a rate that makes a slight difference in number of atm
packets insignificant.

I did see an explaination about the Win Enternet software for my Efficient
5360 modem that said they determined that MSS 1454 was optimum, but I
don't know how that relates to MTU.  Their software indicated that it had
connected with mtu 1480.

So the numbers thrown about can be confusing when you do not know if they
are MTU, MSS, RWIN or whatever.  In fact I saw one explaination of how to
calculate optimum RWIN (which you do not have to worry about for Linux),
and one of the variables was speed, but it did not mention what units for
that speed.

--
David Efflandt - All spam ignored
http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://www.nsscc.com/ - free driver school Friday nights in March

I believe this to be the case.  ATM cells are rather small, something
like 40 bytes, IIRC (don't recall the exact and to lazy to go look it up).
While that might make a measurable difference at dialup speeds, it's
hardly measurable at standard DSL speeds, and in practical use, I believe
other variables, such as noise on the line and minor variations in latency
due to routing over the shared internet, with other folks' traffic as
well, make the measurable effect of sending a partially empty ATM cell
pretty much nil.  A carefully controlled lab environment is another story,
which is why they can make the truthful under those conditions statement
about the lower number being more efficient.

Quote:> I did see an explaination about the Win Enternet software for my
> Efficient 5360 modem that said they determined that MSS 1454 was optimum,
> but I don't know how that relates to MTU.  Their software indicated that
> it had connected with mtu 1480. []

IIRC, MSS is MTU minus the IP header.  Why people can't standardize on one
term, and eliminate the confusion, is beyond me.

--
Duncan - If posted to usenet, usenet replies get priority.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin

Yes, I've already had my fingers whacked for that mistake.

Quote:> The way to test max mtu is to determine the largest ping data size that
> will pass without fragmenting (if your ping has that option) and then add
> 28 to get maximum mtu.
> From a masqueraded internal box I had no trouble doing:
> ping -c4 -M do -s 1464 www.dslreports.com
> Anything bigger and it would fragment over pppoe.
> ie, 1464 + 28 = 1492 max mtu for LAN.

Yes, a ping is an ICMP message in an IP datagram, and the datagram has
a 20 octet header with the rest being data payload.  TCP is mostly over
IP and it has a 20 octet header too which makes 40 octets overhead,
so for a TCP/IP segment originating from a standard Ethernet the MSS
(Maximum Segment (data) Size) is the 1500 octet standard Ethernet
payload size minus 40, or 1460 octets.

PPPoE has a 6 octet header followed by 2 octet PPP protocol field and
then the PPP payload, including TCP/IP headers, but with no PPP frame
FCS (CRC).  So the it can only carry up to 1452 octets of data.  To make
that happen the MTU of the Ethernet must be no greater than 1492.

Why an extra 20 octets needs to be subtracted from the 1492 octets to
facilitate PPPoE is the real question.  I don't disagree that 1472 would
"be just fine" but I don't see any need to use something other than the
maximum.  Apparently something is going on that I don't understand, but
would certainly like to.

Quote:> I saw one theory that explained why 1454 would be optimum because once it
> got to the ATM it would be sending 30 full atm packets for every tcp
> packet instead of 31 with 1 partially empty.  But I have not seen actual
> evidence of that.  All actual tests seem to indicate that bigger is
> better, short of fragmenting.  So maybe atm packets are split and
> assembled at a rate that makes a slight difference in number of atm
> packets insignificant.

I don't see how PPP over ATM relates to PPPoE at all.

Quote:> I did see an explaination about the Win Enternet software for my Efficient
> 5360 modem that said they determined that MSS 1454 was optimum, but I
> don't know how that relates to MTU.  Their software indicated that it had
> connected with mtu 1480.

I don't know anything about that hardware.

Quote:> So the numbers thrown about can be confusing when you do not know if they
> are MTU, MSS, RWIN or whatever.  In fact I saw one explaination of how to
> calculate optimum RWIN (which you do not have to worry about for Linux),
> and one of the variables was speed, but it did not mention what units for
> that speed.

Probably bits/second, aka bandwidth.

PPP-Q&A links, downloads:    http://users3.ev1.net/~ckite/public_html/
/* The signal-to-noise ratio is too low in many [news] groups to make
 * them good candidates for archiving.
 *    --- Mike Moraes, Answers to FAQs about Usenet */