<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: CIPE 1.4.5 iptables forward rule?
From: Richard Singer <richards,AT,kingfish,DOT,corp,DOT,rainbowfish,DOT,com>
Date: Sat, 4 May 2002 03:06:43 +0200
In-reply-to: <1020444924.1996.17.camel@grimoire>

Quoting Andrew Grimberg (tykeal,AT,bardicgrove,DOT,org) on Fri, May 03, 2002 
at 
09:55:24AM -0700:
> Thanks again to Richard for the previous fix on my server mode problem.
> 
> I've got another issue now between a couple of new firewall CIPE tunnel
> endpoints that I'm setting up.
> 
> Still RedHat 7.2 and CIPE 1.4.5
> 
> I've found that if I set the default policy on the FORWARD chain to DROP
> I can't pass traffic from the tunnel into my network.
> 
> Going with the most basic example.  Assume a completely flushed table.
> 
> Gateway/FW 1 --- Internet --- Gateway/FW 2 -- Machine 2
> 
> MIP = Machine IP addy 
> 
> Pinging  from Gateway 1 to Machine 2:
> 
> (Gateway 2)
> let's start from ground zero
> service iptables stop
> 
> causes tables to flush and everything to be set to ACCEPT, forwarding is
> still enabled
> 
> (Gateway 1)
> ping 192.168.2.103
> 
> Starts to ping
> 
> (Gateway 2)
> iptables -P FORWARD DROP
> 
> (Gateway 1)
> the pings stop as expected
> 
> (Gateway 2)
> iptables -A FORWARD -i cipcb0 -s 192.168.1.0/24 -d 192.168.2.0/24 -o
> eth1 -j ACCEPT
> 
> I expect at this point to see my pings resume, they do not.
> 
> switching it from -j ACCEPT to -j LOG I start to see in my logs my pings
> coming in on on cipcb0 and trying to go to eth1 as I figured.
> 
> Does anyone have any suggestion as to why this doesn't work?
> 
> I've currently got it working in the most ugly of fashions by setting
> FORWARD to ACCEPT and then having a final catch-all rule at the end of
> the chain to DROP.  I don't like this method.
> 
> again TIA,
> -Andy-
> 

Don't forget that communication is a two way process.  You added a rule to
accept incoming packets, but not one for outgoing packets.  The pings should
be reaching machine 2, but the replies are being dropped by gateway 2.  This
could be confirmed by using tcpdump on machine 2 and gateway 2.

In general, when setting up a new batch of packet filter rules, it helps a lot
to log all dropped packets, so when something isn't working as planned, there
is information about where it is breaking.  Just add a -j LOG rule before a -j
DROP rule.  After things are working as expected, then you can leave out the
logging or limit it, as appropriate.

-- 
Richard Singer
True World Foods, Inc.
richards,AT,kingfish,DOT,corp,DOT,rainbowfish,DOT,com
richards,AT,trueworldfoods,DOT,com





<< | Thread Index | >> ]    [ << | Date Index | >> ]