LINUX IP Masquerading works on dsl.net, not ameritech.net?

LINUX IP Masquerading works on dsl.net, not ameritech.net?

Post by joseph Phili » Fri, 15 Mar 2002 09:42:16





> > 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.

> > 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.

> > 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).

> > 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

There is a pppoe client called "Roaring Penguin" I believe it is being
distributed with  some distributions of linux. You could get the same from
roaringpenguin.com.

Your pppoe software may have a value that says "ClampMSS". If you set this
to yes, then  it will take care of the 1412 or 1452   or what ever segment
size is being used.
Your internal LAN machines  can continue on, using the value they've always
been, blissfully unaware of all the contortions being done on the linux
system. Although the comments say that this clamping may hit your
performance( for the system then has to inspect the packet, fragment it if
needed etc. ) , I have seen no loss of performance in using the same setup
on a 486, a P200 and a P100. I am consistently able to fill out the 1.2Mb
down when accessing a sufficiently fast web/ftp server. A drop in the ocean
for your PIII.

As for your firewall rules, here are a few hints:

1. the pppd program ( the PPP Daemon) upon successfully making a connection
will call the script /etc/ppp/ip-up . If it could not establish a
connection, it will *not*  call the script.

2. pppd passes the script  parameters  such as the tty it is connected to,
the ppp interface name, the local ip of the computer, the ip of the remote
end and some other things. On redhat derived systems, this script then calls
"ip-up.local" in the same directory, which is the recommended place to put
your custom scripts such as sending spooled mail, etc.  You can also place
your firewall rules here, and take advantage of knowing your ip without
resorting to black magic.

3. When an *established* connection is lost, pppd will call /etc/ppp/ip-down
with similar arguments. If it keeps retrying and failing, nothing gets
called.

4. you can have a rc.firewall that sets up your default set of rules when
the computer brings up networking. Perhaps you could prevent masquerading
windows networking ports 137 to 139 ( NETBIOS ). both source and
destination.

Lastly, some ISP tried to block out home lans being masqueraded by blocking
connects from high (>60000) ports. Solution was to recompile the kernel with
a lower starting MASQ port.

HTH

joseph