\_ SMTP quoth Steve Holmes on 2/26/2002 04:52 as having spake thusly: \_ \_ I know, but as soon as I make default policy to DENY on the input chain, \_ all connectivity to the outside is lost. Here was a basic set of rules at \_ my last test. \_ ipchains -P input DENY \_ ipchains -A input -i lo -j ACCEPT \_ ipchains -A input -i eth0 -j ACCEPT \_ ipchains -P forward DENY \_ ipchains -A forward -s 192.168.x.y/24 -j MASQ \_ ipchains -P output -j ACCEPT \_ Now at this point I tried adding something like \_ ipchains -A input -i eth1 -p ! -y --dport 1025:65535 -j ACCEPT ipchains have been a while, but doesn't -p require an argument like 'tcp' or 'udp'? That feels like a tcp rule. \_ to the chains with no change; At this point, I can get around fine on the \_ local area network but from any machine inside or the firewalled machine \_ itself, I cannot ping anything other than the DNS itself. Some distros auto punch DNS entries into the firewall as part of the network setup. Keep in mind that *most* dns traffic and pings aren't tcp. \_ That is interesting in itself. My Static ip is 24.221.xx.xx \_ and the dns is \_ 24.221.x.y and I cn ping that with no trouble but I cannot ping other IP \_ address in other network address ranges. Not sure why that be the case. \_ All other protocols are "no go". Well, can you surf? :-) \_ Just messing around, but as soon as I added a rule like \_ ipchains -A input -i eth1 -j ACCEPT \_ then it was wide open. that makes sense to me and is what I would expect. \_ So at least ipchains is recognizing the network devices. I do find it \_ interesting that ipchains -L did not specifically mention the device \_ names. It showed ----lo but the entries that should have been eth0 and \_ eth1 showed up as ------. Shouldn't it have shown the eth devices \_ clearly? \_ \_ Thanks for the help so far. I've always run -nvL ... check the docs for meanings. David