Hmmm, not necessarily. I don't see a drop rule on the OUTPUT chain and the default policy is ACCEPT. The first packet in the posted log goes out fine (hence the ICMP reply). Take a look at your logs. You have an outbound ICMP Echo (type 8) going to the internet through eth1. You then have a reply (Type 0) coming back in through...eth0?!?! You have something really funky going on here. Your rule allowing related and established traffic only applies to the external interface, as it should, but something else is going on that is delivering the traffic to your inside interface. On Tue, May 4, 2010 at 11:03 AM, Gary Smith <gary.smith@xxxxxxxxxxxxx> wrote: >> Thanks Gary. >> I went ahead with your suggestion but I still can't seem to figure out >> where the problem is. >> For example, this is me trying to ping google.com from the shell: >> >> [220040.098711] FW: IN= OUT=eth1 SRC=MYPUBIP DST=72.14.234.104 LEN=84 >> TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=871 SEQ=14 >> >> [...] >> >> [220040.342816] FW: IN=eth0 OUT= >> MAC=00:03:47:42:5c:17:00:04:ed:99:2c:fb:08:00 SRC=72.14.234.104 >> DST=MYPUBIP LEN=84 TOS=0x00 PREC=0x00 TTL=53 ID=48058 PROTO=ICMP TYPE=0 >> CODE=0 ID=871 SEQ=14 >> >> >> It all seems to be pretty kosher (except for the fact that the packets are >> being dropped).. > > > You are dropping outgoing packets. Stop doing that :). Unless you are ultra paranoid about traffic originating from your firewall, there is no need to drop OUTPUT. IMHO, the OUTPUT chain is useful for when you need to block specific outgoing traffic in a certain manner, say, port 25, to make sure that all mail flows through a specific server on your network for compliance, etc. Or in the case of proxying, where you want to ensure that all traffic going to port 80 goes through the proxy and only the proxy can go out. > > In essence, you are saying, do let my requests go out... > > Then, for the input chain, make sure you have a rule to allow established and related connections to come in (and to be forwarded) and then return packets that originated from your network should be able to return just fine. > > -A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT > -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT > > Give that a try. > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
