Linux Gateway/Firewall

I am trying to set up a Linux Firewall that would serve windows
clients of various versions and would like to know how to do the
following:

- Set up a gateway. I have done the "echo "1" >
/proc/sys/net/ipv4/ip_forward" command and set my windows clients
gateway to the internal ip of the Linux server and this hasnt done the
trick yet. I then stopped and restarted the network and nfs services
and tried again, no luck. Is there a way I can test my settings?

- Kill all open ports except the ones I need open. Also, is there a
way to determine what port requests comming to a port that is closed
are comming from? This in case I close a needed port.

Thanks,
JW

Jimmy Jam wrote:

> I am trying to set up a Linux Firewall that would serve windows
> clients of various versions and would like to know how to do the
> following:
>
> - Set up a gateway. I have done the "echo "1" >
> /proc/sys/net/ipv4/ip_forward" command and set my windows clients
> gateway to the internal ip of the Linux server and this hasnt done the
> trick yet. I then stopped and restarted the network and nfs services
> and tried again, no luck. Is there a way I can test my settings?
>
> - Kill all open ports except the ones I need open. Also, is there a
> way to determine what port requests comming to a port that is closed
> are comming from? This in case I close a needed port.

Are you using addresses from private IP range in your internal network? If
yes, then you have to setup NAT.


--
pozdr
adeon

Read on www.netfilter.org

use iptables for firewalling

---------------------------------------------------------------
Maxime Ducharme
Administrateur reseau, Programmeur


"Jimmy Jam" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> I am trying to set up a Linux Firewall that would serve windows
> clients of various versions and would like to know how to do the
> following:
>
> - Set up a gateway. I have done the "echo "1" >
> /proc/sys/net/ipv4/ip_forward" command and set my windows clients
> gateway to the internal ip of the Linux server and this hasnt done the
> trick yet. I then stopped and restarted the network and nfs services
> and tried again, no luck. Is there a way I can test my settings?
>
> - Kill all open ports except the ones I need open. Also, is there a
> way to determine what port requests comming to a port that is closed
> are comming from? This in case I close a needed port.
>
> Thanks,
> JW

Jimmy Jam <(E-Mail Removed)> wrote:

> - Kill all open ports except the ones I need open. Also, is there a
> way to determine what port requests comming to a port that is closed
> are comming from? This in case I close a needed port.

Use tcpdump or ethereal if a service does not work as intended.

It is a good idea to use tcpdump and ethereal every now and then
even if all is working as expected. ;-)

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn

On Tue, 16 Sep 2003 08:21:06 -0700, Jimmy Jam wrote:

> I am trying to set up a Linux Firewall that would serve windows clients
> of various versions and would like to know how to do the following:
>
> - Set up a gateway. I have done the "echo "1" >
> /proc/sys/net/ipv4/ip_forward" command and set my windows clients
> gateway to the internal ip of the Linux server and this hasnt done the
> trick yet. I then stopped and restarted the network and nfs services
> and tried again, no luck. Is there a way I can test my settings?
>
> - Kill all open ports except the ones I need open. Also, is there a way
> to determine what port requests comming to a port that is closed are
> comming from? This in case I close a needed port.
>
> Thanks,
> JW

Ok, so I assume that you went to your windows computers of various
vintage, looked through their tcp/ip properties, and set the "gateway"
field with the LAN side address of the gateway ( 192.168.0.1 perhaps? ). I
further assume that you looked at the DNS tab and put the first dns ip as
an IP that your ISP gave you.

Then, what would happen is as follows: When windows sends a packet to some
computer not on your lan ( your isp's dns server, perhaps ), the gateway
receives the packet, unpacks it and then finds that it's not the
recepient. Consulting the routing table ( route -n ; man route ), it
finds that there are no explicit routes defined for the destination host,
and so sends it on its merry way down the default route. So now your
packet reaches the ppp0 interface ( because, when you dialout, the ppp
interface becomes the default route ). And a packet just got sent out
towards your ISP's dns server with the source ip of one of your internal
machines ( which is useless to a computer outside the LAN ). That is,
your isp's dns server knows how to reach your linux computer but not the
others behind it. What you do is, masquerade ( aka port-nat ) the packet
just as it goes out the ppp interface :

IPT=/usr/sbin/iptables

EXTIF="ppp+"

# MASQUERADE outbound traffic on the ppp

$IPT -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE


This makes it look like the linux computer is doing it, and computers on
your lan are "masked".


A few things to watchout for:


1. pppd needs the "DEFAULTROUTE" option or something in /etc/ppp/ppp.conf
before it tampers with an existing default route on your computer.

2. Your iptables should allow outbound connections.


3. If you are using 2.4 kernels, unlike in the 2.2's where MASQ had a port
range from 60000 to 61000, now, if your internal computer connects from
port 1030, the outgoing source port on the gateway will be one of 1030 or
the next available port. Not sure if it is higher or lower. Hence, you
need to be carefull with blancket blocking and allowing only "certain"
important ports through. The --state stuff of iptables would be of help
there.


4. if you create any ip or interface specific rules that get invoked when
the ppp daemon calls /etc/ppp/ip-up, you should have corresponding delete
invocations in /etc/ppp/ip-down, or wierd things can occur. No, not kernel
crashes, but it could be hairy figuring out why your firewall doesn't work
the way you want it to.


5. Anything with a source or destination port of 137 to 139 ( tcp or udp )
should NEVER reach the ppp interface. These are your windows netbios
packets, which have no business on the internet. Check the netfilter
pages.

6. Getting an internal windows machine to find the published shared drive
or folder of some other computer on the internet is not easy with windows
file sharing ( which was never built for this sort of gateway hopping ),
and may cause a lot of hair pulling. Use FTP or P2P or some other P
instead. Ofcourse, setting up IE for plain old FTP might cause hair
pulling

hth