On Tue, 2002-02-26 at 04:52, Steve Holmes wrote:
> 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.1.0/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
> 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.  That is
> interesting in itself.  My Static ip is 24.221.98.238 and the dns is
> 24.221.30.3 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".
----
Is your sprint broadband subnet mask correct?

does 'cat /etc/sysconfig/network' list...
GATEWAYDEV = "eth1"
GATEWAY = "ip_address_for_gateway_supplied_by_Sprint"

?
----
> 
> 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?
> 
---
the devices involved are picked by the routing tables...

route -n

which should list the network address for your internal lan, the network
address for your public ip, the loopback adaptor, and the last entry is
for your gateway - all addresses other than those within the two network
defined by your ip addresses and subnet masks bound to the nic's.

I would think that ipchains possibly doesn't have to have the interfaces
specifically called out except that it might slow the rule sets down to
omit them. 

also note - that the order of the chain rules might impact how they are
treated - if a packet runs into a rule that is deny/reject before accept
or the default policy - it will act on that rule and that rule alone. 
Best way to learn is to absorb someone else's first and then play with
it - which is why I gave you the URL to David Ranch's rulesets.

Therefore, if you want to play with things...make a file - called
reset-ipchains...chmod to 700 (executable) and have it do something
like...
#!/bin/sh
/sbin/ipchains -P input ACCEPT
/sbin/ipchains -P output ACCEPT
/sbin/ipchains -P forward ACCEPT
/sbin/ipchains -F input
/sbin/ipchains -F output
/sbin/ipchains -F forward
(this will flush all chains - reset policy back to default - a good
starting point)

Then create another file...in psuedo code but similar to reset-ipchains
above...
first set all policies
then flush all rulesets
then do input rules
then do output rules
then do forward rules (masquerade)

Craig