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 10.0.0.252 fcfw pub eth0 ] ---\
> > [ 10.0.0.100 eth0 ]+ +--- internet
> > \--- [ eth1 10.0.0.253 fdfw pub eth0 ] ---/
> >
> > fcfw & fdfw use ucarp and one virtual ip on public interfaces as
> > well as they have 10.0.0.254 on eth1's, what's default gw for 10.0.0.100.
> >
> > what I did on 10.0.0.100:
> >
> > 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 10.0.0.252 dev eth0 table fcfw
> > ip rule add fwmark 2 table fdfw
> > ip route add default via 10.0.0.253 dev eth0 table fdfw
> >
> > I expected that connections comming via fcfw, from 10.0.0.252 would get mark
> > 1 and syn+ack would go to 10.0.0.252, but it is going to 10.0.0.254, default
> > gateway. so when public ip is on fcwf, and 10.0.0.254 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
issue.
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
matej.kovac@telnet.sk
Reply to: