Shorewall and Firewall Mark LVS Setups

Combining the firewall marking needed for the correct operation of LVS with the power and flexibility of a shorewall provides an interesting challenge. At first it seems like a bit of a daunting problem. To combine shorewall, which is generally used in for protective firewalls, and the iptables mangle rules that LVS uses to correctly route packets can seem like a completely different set of requirements. However shorewall is extremely flexible and configurable, it can be made to do exactly what you require, the trick is in where to put all the little bits to make it all work.

Firstly lets look at the packet marking required for LVS operation. Within shorewall you set this up in the /etc/shorewall/tcrules Here's a sample file

#MARK   SOURCE          DEST            PROTO   DEST    SOURCE  USER    TEST   LENGTH   TOS
#                                               PORT(S) PORT(S)
1       0.0.0.0/0       192.168.50.23  tcp     http,https

This rule specifies that packets from any source sent towards 192.168.50.23 on the http and https ports will be marked with fwmark = 1. This is the shorewall equivalent of doing

iptables -t mangle -A PREROUTING -i eth0 -p tcp -s 0.0.0.0/0 -d 192.168.50.23/32 --dport http -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i eth0 -p tcp -s 0.0.0.0/0 -d 192.168.50.23/32 --dport https -j MARK --set-mark 1

which is the normal way of setting up these firewall marks according to the LVS documentation. You'll notice that there is no interface defined in the tcrules files. This is because shorewall uses the ip addresses to map into zones, and then the ruleset is built up from the zones.

The second part of getting this working is to defined the ruleset to accept packets for the Virtual IPs (VIPs) so that they can then be forwarded to the real servers by ipvs. Generally the VIP is present on the load balancer as well as the real servers. This is the case when the load balancers are controlled by the pulse service on a Redhat Enterprise Linux server. The important part to note about this is that the VIP is present on the firewall, and so shorewall considers the VIP to be part of the 'fw' zone. Therefore the ruleset must be build up with this in mind.

Assuming that the services being provides are to be externally facing then the shorewall rules will use a source address of the 'all' zone. This will match any incoming address. Here's a sample rule that will allow the firewall to accept packets destined for the VIP.

#ACTION SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINALRATE            USER/   MARK
#                                               PORT    PORT(S)         DEST   LIMIT            GROUP
ACCEPT  all             fw:192.168.50.23 tcp  80,443

With the ruleset configured like this, and the packet marking setup previously in /etc/shorewall/tcrules the packets will be marked and accepted by the firewall. At this point the packet processing is taken over by ipvs and the normal ipvs routing takes place on the packets.

And there you have it. What you need to create a load balanced cluster service protected by a strict set of firewall rules.

Links:
Shorewall Homepage
Linux Virtual Server (LVS) Homepage