Playing around with different firewall configurations (iptables), I have
been testing with 'Shields Up' at GRC.com. Everything is pretty locked
down except for port 80 which, while shown as closed, can be stealthed
with a little iptable's manipulation.

To experiment, I try to alter the rules on the fly by editing
the rc.firewall script, flushing and re-running. However, when I
recreate the rules, I can't get back to the internet. I get an error
message to the effect 'location not recognized' no matter where I point the
browser (firefox). I thought that this sounded like a DNS problem
but I can't understand how flushing the tables and re-running the
firewall script could interfere with this operation.

IP address & connection are configured by DHCP. No problem on bootup,
just when I flush & rerun. The firewall script does make a reference
to the DHCP server IP, but that is simply to allow packets from the
server, i.e. it simply places the IP address in a rule reference.
iptables -L shows no change in this element after flush and re-run.

I'm at a loss!

What rules do you currently have setup?

Well everything might have looked alright with iptables -L, however when
I compare routing table entries before and after, there is a change.

My net connection is through a cable modem and they are always futzing around
with their network names. It seems that on bootup, the routing table is set
with a long gateway name such as c-xxx-xxx-xxx-xxx-hsd1-<a lot more stuff>.
However, when I flush tables and re-run my firewall script, this gateway
entry in the route table gets changed to a simple IP address xxx.xxx.xxx.xxx.

The entry in iptables for the DHCP server is a simple IP address, but that
should work fine for packets from this address. However, I still don't know
why a simple netfilter tables command would alter the route table. I am
not trying to call any DHCP function in the firewall script.

Unfortunately, 'route' prints out a table of information that is truncated so
I can't tell what the actual gateway address looks like. I can only infer it
from the domain information in /etc/dhcpc/dhcpcd-eth0.info. Is there any way
to expand the route table information display?

Any suggestions as to how I might correct this?

Well, I guess I'll just continue my own education.

Seems that the route table entries were being changed by my
flush script. I have been using the script below ever since
Slack 8.0 and have never had a problem:

#!/bin/sh

#
# Configurations
#
IPTABLES="/usr/sbin/iptables"

#
# reset the default policies in the filter table.
#
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT DROP

#
# reset the default policies in the nat table.
#
$IPTABLES -t nat -P PREROUTING DROP
$IPTABLES -t nat -P POSTROUTING DROP
$IPTABLES -t nat -P OUTPUT DROP

#
# reset the default policies in the mangle table.
#
$IPTABLES -t mangle -P PREROUTING DROP
$IPTABLES -t mangle -P OUTPUT DROP

#
# flush all the rules in the filter and nat tables.
#
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
#
# erase all chains that's not default in filter and nat table.
#
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -X

Actually, the first two sections can be entered w/o any change
in the route table, but add any of the last three and bam!

Oddly enough I decided to try a different flush script from
a netfilter tutorial:

#!/bin/sh

#
# Configurations
#
IPTABLES="/usr/sbin/iptables"

#
# reset the default policies in the filter table.
#
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -P OUTPUT ACCEPT

#
# reset the default policies in the nat table.
#
$IPTABLES -t nat -P PREROUTING ACCEPT
$IPTABLES -t nat -P POSTROUTING ACCEPT
$IPTABLES -t nat -P OUTPUT ACCEPT

#
# reset the default policies in the mangle table.
#
$IPTABLES -t mangle -P PREROUTING ACCEPT
$IPTABLES -t mangle -P POSTROUTING ACCEPT
$IPTABLES -t mangle -P INPUT ACCEPT
$IPTABLES -t mangle -P OUTPUT ACCEPT
$IPTABLES -t mangle -P FORWARD ACCEPT

#
# flush all the rules in the filter and nat tables.
#
$IPTABLES -F
$IPTABLES -t nat -F
$IPTABLES -t mangle -F
#
# erase all chains that's not default in filter and nat table.
#
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -X

You'll notice that this is almost identical to the previous
albeit all of the default policies are set to ACCEPT not DROP.
This flush script left the route table intact.

Not sure why this makes a difference, but I don't know how you
can create a rather restrictive firewall if your default policies
are all ACCEPT. You would have to exclude everything you don't
want rather than allowing only those things you do.

I don't understand this, so if anyone out there is listening?

The second script is not at all restrictive, but in fact very liberal. The first script should show all ports as stealthed at your machine.

Ahem!

Maybe I was not all that clear. The first script which does nothing but flush
all tables with a default of DROP, causes changes in the routing table which
destroys internet connectivity. While it is resrictive, even if the route table
was not altered, all packets wold be dropped in the absence of any other chain
rules.

Fortunately, the second script flushes all tables with a default of ACCEPT which is
not restrictive ay all but, it has the added advantage of causing no changes
in the route table; internet connectivity is preserved. After the flush, I can run
any other firewall script that changes the default to DROP and then proceeds to
allow only what I want. The route table is still preserved.

I don't know what changes, if any, have been made to the netfilter code, but it is
apparent that the flush statements that I have been using for some time are causing
a problem with the route table in Slack 10.2.

I'm still looking for a way to display all of the route table information.

I would like to understand what has changed and why any flush statements would
effect the route table.

I honestly have no idea why that would alter the routing table. In what way does the routing table change?

See #3 above

Played around a little more with various firewall scripts and interestingly enough if I flush
the tables with DROP the route table is changed and the normal gateway is changed to a simple
xxx.xxx.xxx.xxx entry destroying internet connectivity. However, if I then restore some sort
of firewall enabling some connectivity (ACCEPT) the route table is changed to its proper config:

c-xxx-xxx-xxx-1.ilhd1.comcast.net

Apparently there is some kind of automatic interaction between DHCP and the netfiler rules.
I don't fully understand it, but I do not have a problem anymore and find I can lockout any
net activity with a simple DROP flush.

Have you tried something like the following? You only need the DROP default policy on the INPUT, OUTPUT & FORWARD chains in the filter table because you shouldn't usually be filtering in those other chains. In the mangle chain you do things like change TOS, etc and in the nat table you'll do masquerading, etc:

I tried your suggested flush script and while it is not all that
different from the one I use, it didn't correct the problem. I have
been playing around with a couple of firewall scripts that establish
the correct gateway description in the route table when they
are run after a flush/policy change. They are long, involved
things which I won't list here.

I thought that a simpler approach, would be to provide a simpler
script, easy to analyze, that does not re-establish the proper
gateway in hopes that someone might see what is missing.

# An enhanced stateful firewall for a workstation, laptop or router that isn't
# running any network services like a web server, SMTP server, ftp server, etc.
# change this to the name of the interface that provides your "uplink"

UPLINK="eth0"
DHCP=`cat /etc/dhcpc/dhcpcd-eth0.info | /bin/grep "DHCPSID" | /bin/cut -c9-23`

INTERFACES="lo eth0 eth1"
LOGGING=1

iptables -P INPUT DROP
iptables -A INPUT -i ! ${UPLINK} -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport http -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp -i ${UPLINK} -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -i ${UPLINK} -j REJECT --reject-with icmp-port
iptables -A INPUT -p udp -s $DHCP --sport 67 --dport 68 -j ACCEPT
iptables -A INPUT -j LOG --log-prefix "bad input:"

#explicitly disable ECN
if [ -e /proc/sys/net/ipv4/tcp_ecn ]
then
echo 0 > /proc/sys/net/ipv4/tcp_ecn
fi

#disable spoofing on all interfaces
for x in ${INTERFACES}
do
echo 1 > /proc/sys/net/ipv4/conf/${x}/rp_filter
done

echo "Enabling masquerading (dynamic ip)..."
iptables -t nat -A POSTROUTING -o ${UPLINK} -j MASQUERADE

Any suggestions appreciated.

As it turns out, I need to allow a specific INPUT connection to the DHCP server in order to
maintain the proper gateway address in the route table:

DHCP=`cat /etc/dhcpc/dhcpcd-eth0.info | /bin/grep "DHCPSID" | /bin/cut -c9-23`

iptables -A INPUT -p udp -s $DHCP --sport 67 --dport 68 -j ACCEPT

Apparently, there is some sort of processing in netfilter code which interacts with routing
table processing. It seems to rewrite the route table whenever firewall rules are changed.
Unless the new firewall rules specifically allow connection with the DHCP server, the route
table does not get updated with the appropriate gateway address.

I can't remember just what the configuration was when I tried the script in the above post,
but for some reason it didn't work. The above script does work, so I can empoy a INPUT -P DROP
policy in the flush and either not lose or re-establish the proper router gateway address.

I hate this trial and error experimentation to try to figure out what works and what doesn't
and would rather understand why. I have spent an inordinate amount of time searching the web
for the 'why', but have come away unsatisfied. I suppose for the time being, I'll have to be
content that I have found a way to make this problem go away.