Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:




honeypots logo Honeypots mailing list archives

Re: iptables & bridging won't work together
From: Mike Tremoulet <coffeemike () gmail com>
Date: Mon, 10 Jan 2005 16:07:30 -0600

What are your acutal rc.firewall rules?  I've only implemented it on a
2.6 kernel so far, but the trick for me was to change how the rule
fired.

The rc.firewall script "out of the box" uses the -i $INET_IFACE switch
to identify the inbound interface for filtering; however, the bridging
showed that both the inbound and outbound interfaces were the bridge,
not either interface.

iptables -A FORWARD -i $INET_IFACE -p tcp -m state --state NEW -j LOG
--log-prefix "INBOUND TCP: "
iptables -A FORWARD -i $INET_IFACE -p tcp -m state --state NEW -j ACCEPT

I was able to fix this by amending the rule to match on the physical
hardware, not the logical interface, like so:

iptables -A FORWARD -m physdev --physdev-in $INET_IFACE -p tcp -m
state --state NEW -j LOG --log-prefix "INBOUND TCP: "
iptables -A FORWARD -m physdev --physdev-in $INET_IFACE -p tcp -m
state --state NEW -j ACCEPT

I don't have handy what modules were required for the physdev
matching, so check on that.

For debugging, you may want to add a rule that just logs all new TCP
traffic so you can see exactly how the packets are moving across your
system:

iptables -A FORWARD -p tcp -m state --state NEW -j LOG --log-prefix "DEBUG: "

Hope this helps,
-- Mike

-- 
just a Gnome of Zurich ... feeding tiny bits of information from all over...


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]