On Tue, May 4, 2010 5:45 pm, Bill Prochazka wrote: > 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. >> -- That actually makes sense. But Gary's solution worked and both forwarding from LAN & local transmission are ok. (I still have troubles with forwarding tho) What puzzles me the most is that I had been running that same iptables setup for years without problems..then one day BHAM! it just stopped working -JK -- 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
