Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
I'm setting up a cluster of two firewalls using fwbuilder to replace our
current maintained by hand iptables scripts. Everything was going great
until I hit a snag this afternoon. I have found a work around for it but
I'm not sure if it's "safe" to use and am looking for some feedback...
Here's some info on the setup.
We're doing a symmetric active-active setup and have a number of VLANs
configured on the firewalls. corosync & pacemaker are used to provide HA
between the two nodes.
The "outside" interfaces of the firewalls are configured like:
fw1:eth0 has IP 22.214.171.124
fw2:eth0 has IP 126.96.36.199
The IP 188.8.131.52 is configured to fail over between the two firewalls for
the outside/eth0 interface.
Each VLAN has a dedicated IP address on each firewall and the HA setup
takes care of managing the default gateway for that VLAN. corosync takes
care of spreading out these gateways so that some are active on fw1 and
others are active on fw2.
When I built my cluster config in fwbuilder I assigned an interface
named eth0 to the cluster and gave it the IP 184.108.40.206.
The hosts that we do 1:1 NAT for have no problems and the rules all
generate very similar to our own rules. However when I got to setting up
the hosts that we don't do 1:1 NAT for (ie. those hosts that are RFC1918
space only and are accessed by VPN) we ran into some problems.
I setup a NAT rule where the networks that that don't have 1:1 mappings
are the original src, the eth0 interface of the cluster is the
translated source and everything else is the default.
When I compile the rule I get back something like:
$IPTABLES -t nat -A POSTROUTING -o eth0 -s 172.17.0.0/28 -j SNAT
However this wont work if the VLAN that 172.17.0.0/28 is on is not on
the same firewall that 220.127.116.11 is active on.
In our current setup we just use the MASQUERADE target and everything
After reading the documentation I discovered that the MASQUERADE target
is only used in fwbuilder when the interface is marked as dynamic.
Unfortunately the cluster interface doesn't allow me to select this
option as it is all disabled:
Here comes the work-around... I discovered that I can edit the .fwb file
by hand and set dyn="True" in the interface element. Once I did this I
re-opened the file in fwbuilder and sure enough the interface is now
marked as dynamic (even though its still disabled). I compiled my
ruleset with dyn as both True & False and the only difference is the NAT
rule in question, which now looks as I'm expecting:
$IPTABLES -t nat -A POSTROUTING -o eth0 -s 172.17.0.0/28 -j MASQUERADE
Will my work around break anything else? Is there a more preferred way
of accomplishing what I want?