I think I'm seeing the 'lo' behaviour. I just added rules to block purely internal services like NFS on my external interface, and used nmap to check that my rules in fact worked. Well, I was mildly surprised to find nmap using the loopback interface when I had specified the external IP address of my machine.
On Thu, 21 Sep 2000, Christian Pernegger wrote: > I have the following lines (inspired by Robert Ziegler's Linux firewalls book) > in my firewall script: > > ipchains -A input -i $IF_EXT -s $ME_EXT -j DENY -l > ipchains -A input -i $IF_EXT -s $ME_INT -j DENY -l > ipchains -A input -i $IF_INT -s $ME_EXT -j DENY -l > ipchains -A input -i $IF_INT -s $ME_INT -j DENY -l > > He says in the book that one will never see a legit packet coming in over a > NIC > from one's own address, for packets destined to a "local" address are > delivered > via the LO interface. > > I think that's what it says in ipfw_chains(4). To quote: > > Input firewall > These rules regulate the acceptance of incoming IP > packets. All packets coming in via one of the > local network interfaces are checked against the > input firewall rules (locally-generate packets are > considered to come from the loopback interface). > > Yet if I broadcast anything from the FW machine to any of the attached > networks, > the packet destined to the machine itself comes in over eth?, not over lo and > is thus denied... > > Maybe someone could explain this to me or give me some pointers? > > Thanks > > Christian > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
