[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

SOLVED: connection through originating fw

On Wed, Aug 11, 2010 at 01:05:07PM -0400, Andy Mason wrote:
> On Tue, 2010-08-10 at 22:41 +0200, Matej Kovac wrote:
> > Hallo,
> > 
> > I'm playing with redundant / balancing firewall after some
> > time... my setup:
> > 
> >                      /--- [ eth1    fcfw    pub eth0 ] ---\
> >  [ eth0 ]+                                                 +--- internet
> >                      \--- [ eth1    fdfw    pub eth0 ] ---/
> > 
> > fcfw & fdfw use ucarp and one virtual ip on public interfaces as
> > well as they have on eth1's, what's default gw for
> > 
> > what I did on
> > 
> > iptables -t mangle -A PREROUTING -i eth0 -m mac --mac-source <mac-of-252> -j MARK --set-mark 1
> > iptables -t mangle -A PREROUTING -i eth0 -m mac --mac-source <mac-of-253> -j MARK --set-mark 2
> > 
> > (packets get matched and counter increase, also tryed CONNMARK target)
> > 
> > two additional route tables
> > 
> > echo 111 fcfw >> /etc/iproute2/rt_tables
> > echo 222 fdfw >> /etc/iproute2/rt_tables
> > 
> > ip rule add fwmark 1 table fcfw
> > ip route add default via dev eth0 table fcfw
> > ip rule add fwmark 2 table fdfw
> > ip route add default via dev eth0 table fdfw
> > 
> > I expected that connections comming via fcfw, from would get mark
> > 1 and syn+ack would go to, but it is going to, default
> > gateway. so when public ip is on fcwf, and on fdfw, connections
> > don't work (to not even get masqueraded by fdwf holding the gw).
> > 
> > I probably make some trivial error but cannot see it for hours now...
> > 
> > -- 
> > matej kovac
> > matej.kovac@telnet.sk
> You might want to have a look at this, which could save you the mucking
> about on the client side:
> http://www.openbsd.org/faq/pf/carp.html

nice docs. I'm actually using: http://packages.debian.org/lenny/ucarp
and also played with http://packages.debian.org/lenny/conntrackd
but never got caches synchronized.

one virtual ip on public interfaces was actually one I used for tests... but
there are more - and not to have a hot-spare, but rather two workers, ip's
float between fcfw / fdfw based on their current load. so either very fast
conntrack sync would have to work very well, but I somehow feel that the
_rigth thing_ is to answer syn+ack to the same firewall who sent the syn,
not to the default gateway, which is in turn virtual IP as well. the def
gw is for new connections from DMZ.

> Unfortunately I have no idea why your approach hasn't worked, sorry.
> Looks sensible to me.  My only wild guess is to disable RPF somewhere
> (probably .100), with 
> sysctl -w net.ipv4.conf.all.rp_filter=0
> sysctl -w net.ipv4.conf.default.rp_filter=0
ah, forgot about it but after check I found they are zeroed, so not an

What was the issue is the OUTPUT chain. I marked incoming packets, but
never marked outgoing ones. relevant mangle table lines:

iptables -t mangle -A PREROUTING -m state --state ESTABLISHED,RELATED -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m state --state NEW -i eth0 -m mac --mac-source $mac252 -j CONNMARK --set-mark 1
iptables -t mangle -A PREROUTING -m state --state NEW -i eth0 -m mac --mac-source $mac253 -j CONNMARK --set-mark 2
iptables -t mangle -A PREROUTING -m connmark --mark 1 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -m connmark --mark 2 -j MARK --set-mark 2
iptables -t mangle -A PREROUTING -m state --state NEW -m connmark ! --mark 0   -j CONNMARK --save-mark

iptables -t mangle -A OUTPUT     -m state --state ESTABLISHED,RELATED -j CONNMARK --restore-mark

of course, above iproute2 rules/routes must be in place.

matej kovac

Reply to: