> > > 1. How to verify the kernel is ok with forwarding and masquerading?
> > Take a look at what's in /proc/net. If you see ip_masquerade, then you
> > have masquerading built into the kernel. Same for ip_forward. I use
> > debian linux and these files may be in a different directory under RH.
> > > 2. How to check the forward and masq rules
> > You can see what rules are in effect as follows:
> > ipfwadm -I -l # for input rules
> > ipfwadm -O -l # for output rules
> > ipfwadm -F -l # for forwarding (and masquerading) rules
> > ipfwadm -A -l # for accounting rules
> > > 3. How to test the system.
> > > I tried testing it by pinging to an internet address from my LAN, to no
> > > avail. I have NT on the LAN set up so my linux box is the default
> > > gateway. Any suggestions?
> > I don't know your level of knowledge so I'm sorry if this is a little
> > pedantic.
> > This is what I have and maybe you can see how your setup differs.
> > #eth0 is on cable modem (24.xxx.yyy.zzz)
> > #eth1 is on LAN (192.168.1.1)
> > # deny everything
> > ipfwadm -I -p deny
> > ipfwadm -I -f
> > ipfwadm -O -p deny
> > ipfwadm -O -f
> > ipfwadm -F -p deny
> > ipfwadm -F -f
> > # permit dhcp traffic so that I can get an IP address allocated by ISP
> > # permit bootps (dhcp server) traffic into eth0
> > ipfwadm -I -a accept -S 0.0.0.0/0 bootps -D 0.0.0.0/0 -W eth0 -P udp
> > # permit bootpc (dhcp client) traffic out of eth0
> > ipfwadm -O -a accept -S 0.0.0.0/0 bootpc -D 0.0.0.0/0 -W eth0 -P udp
> > # permit localhost traffic (so ping localhost works)
> > ipfwadm -I -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> > ipfwadm -O -a accept -S 127.0.0.1/32 -D 127.0.0.1/32
> > # permit LAN traffic into and out of the firewall
> > ipfwadm -I -a accept -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth1
> > ipfwadm -O -a accept -S 0.0.0.0/0 -D 192.168.1.0/24 -W eth1
> > # permit cable modem traffic into and out of the firewall
> > ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
> > ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0
> > # masquerade the LAN
> > ipfwadm -F -a masquerade -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0
> > I don't make use of the -b option, which would simplify my rules. I don't
> > really have to use -I or -O rules but I may in the future lock things
> > down more and want placeholders in my firewall script.
> > Procedure to debug:
> > From the firewall:
> > 1 - you should be able to ping the localhost
> > 2 - you should be able to ping a host on the internet
> > 3 - you should be able to ping a host on your LAN
> > From a host on your LAN:
> > 4 - you should be able to ping the firewall
> > 5 - you should be able to ping a host on the internet
> > If you can't get one of the steps to work, then you need to see where the
> > packets are getting blocked. To figure this out, you can use tcpdump as
> > follows:
> > Let's say that step 5 doesn't work and that the "host on your LAN" has IP
> > address 192.l68.1.2. On the firewall, run this command:
> > tcpdump -i eth1 ip proto icmp
> > or
> > tcpdump -i eth1 ip proto 1
> > This will show you all packets received by the firewall on interface eth1
> > (the LAN-side of the firewall) whose ip protocol type is ICMP (what ping
> > uses). If you see echo-request packets from 192.168.1.2 then you know
> > that your internal machine's packets are getting to the firewall. If you
> > don't see echo-reply packets then you know the ping reply's aren't
> > coming out of the firewall and getting to your internal machine. What you
> > don't know is whether its the outgoing echo-request packets that aren't
> > getting out of the firewall and onto the internet in the first place or
> > its the returning echo-reply packets that aren't getting back through the
> > firewall to your internal machine. To find the answer, you need to see
> > what's happening on eth0 (the internet-side of the firewall). On the
> > firewall, run this command:
> > tcpdump -i eth0 ip proto icmp
> > or
> > tcpdump -i eth0 ip proto 1
> > tcpdump has a *LOT* of options that you can specify to allow you to focus
> > on only those packets which interest you. Check out its manpage.
> > If you see no echo-request packets, then the firewall isn't allowing them
> > out of your internal network.
> > If you see echo-request packets (you will also so echo-reply packets),
> > then the firewall isn't allowing the replies back into the internal LAN.
> > There's another wrinkle to this that I haven't mentioned.
> > Are your routing tables set up correctly? Your internal machines should
> > have the firewall's eth1 IP address set as their default gateway. You
> > mention above that this is already the case.
> > The firewall should have your ISP's router set as its default gateway. If
> > it doesn't, then your firewall won't know what to do with the echo-
> > request packets it gets from the internal machine.
> > I hope this helps.
> > --
> YESYESYESYES!!!! IT worked!! THANK YOU so much! I typed in exactly
> what you have, except changing the numbers, and it worked --- for now.
> That is, until dhcp assigns me a new ip address. How do I get the dhcp
> server to reassign the values in the ipfwadm tables when I get a new ip?
> Honestly, I think this explanation should go into the firewall howto, or
> into a mini-howto or something.
That's great that you got it working. Maybe I'll contact the LDP and see
if they want another mini-HOWTO. Thanks.
You can configure your DHCP client (dhcpcd) to to run a shell script when
it successfully gets an IP address (dhcpcd has a command line option for
this: "-c filename").
The following environment variables (amongst others) are set and passed
to the shell script: HOSTNAME, ROUTER, IPADDR, NETMASK and BROADCAST.
So, if you have all the stuff for ipfwadm in a shell script file called
/etc/init.d/rc.firewall, say, then you can start the DHCP client daemon
dhcpcd -c /etc/init.d/rc.firewall
You'll want to make this change in whatever startup script starts up
dhcpcd. Since I don't use RedHat, I don't know where that might be. Under
Debian Linux, it's /etc/init.d/dhcpc.
This shell script, rc.firewall, will have to be modified a little bit
from what we have already. You need to use $IPADDR and $NETMASK in place
of the values you have specified statically.
So, instead of this...
# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.zzz/32 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.zzz/32 -D 0.0.0.0/0 -W eth0
# permit cable modem traffic into and out of the firewall
ipfwadm -I -a accept -S 0.0.0.0/0 -D $IPADDR/32 -W eth0
ipfwadm -O -a accept -S $IPADDR/32 -D 0.0.0.0/0 -W eth0
The daemon, dhcpcd, takes care of setting up the routing table. You just
have to take care of the firewall (as above) and port forwarding rules
By the way, you could just use the subnet instead of the assigned ip
address. Since you will always be assigned a number from within the same
subnet, if you know the subnet network and netmask numbers you can just
ipfwadm -I -a accept -S 0.0.0.0/0 -D 24.xxx.yyy.0/24 -W eth0
ipfwadm -O -a accept -S 24.xxx.yyy.0/25 -D 0.0.0.0/0 -W eth0
Note that the numbers I have used above assume a full class-C
subnet (i.e., with a netmask of 255.255.255.0) but that your subnet might
be have a different netmask (like 255.255.252.0 or something). This means
that you can't use /24 (8+8+8+0) but would need to use /22 (8+8+6+0).
That way, you wouldn't have to set up dhcpcd to run rc.firewall everytime
it got a new ip address. This is true for ipfwadm, at least. If you are
using port forwarding, like ipportfw or ipautofw, then you will have to
use the -c option of dhcpcd since you will want to use the IPADDR
environment variable to change the port forwarding commands.
Glad to have been of help.