Discussion:
[Shorewall-users] VRRP and Keepalived
James Shubin
2011-03-12 08:28:02 UTC
Permalink
Hi Tom, Shorewall,

I've been working on a highly-available two-node server setup. I'm using
Keepalived for its implementation of VRRP, and naturally also using
shorewall. The two nodes send multicast packets back and forth, and if
they get blocked by shorewall, VRRP doesn't work properly ;)

It seems the working configuration for /etc/shorewall/rules is:
#ACTION SOURCE DEST PROTO
ACCEPT $FW net:224.0.0.18 vrrp
ACCEPT net $FW:224.0.0.18 vrrp
ACCEPT $FW loc:224.0.0.18 vrrp
ACCEPT loc $FW:224.0.0.18 vrrp

I thought I'd document this here, because it took a bit of brain
scratching to realize all this at first. Please let me know if it looks
like I'm doing the right thing. I wasn't sure if there is a better way
to do this or if it's too permissive (it does work though).

I thought about adding the: mcast_src_ip keyword to my keepalived
config, (and to the SOURCE column in the above rules) but I wasn't sure
which IP I should actually choose.

Secondly I tried to create all this as a macro, but I wasn't sure if
there was a sane way to get it to include the :224.0.0.18 address. In my
imagination I would have wanted to do something like:

VRRP/ACCEPT $FW net
VRRP/ACCEPT net $FW
VRRP/ACCEPT $FW loc
VRRP/ACCEPT loc $FW

to produce the above. Wasn't sure if shorewall macros can support this.
You'll notice there are two pairs of rules, because I have a public VIP
and also a private VIP on the lan.

Thanks, and HTH,
James
Tom Eastep
2011-03-12 16:09:33 UTC
Permalink
Post by James Shubin
Hi Tom, Shorewall,
I've been working on a highly-available two-node server setup. I'm using
Keepalived for its implementation of VRRP, and naturally also using
shorewall. The two nodes send multicast packets back and forth, and if
they get blocked by shorewall, VRRP doesn't work properly ;)
#ACTION SOURCE DEST PROTO
ACCEPT $FW net:224.0.0.18 vrrp
ACCEPT net $FW:224.0.0.18 vrrp
ACCEPT $FW loc:224.0.0.18 vrrp
ACCEPT loc $FW:224.0.0.18 vrrp
I thought I'd document this here, because it took a bit of brain
scratching to realize all this at first. Please let me know if it looks
like I'm doing the right thing. I wasn't sure if there is a better way
to do this or if it's too permissive (it does work though).
I thought about adding the: mcast_src_ip keyword to my keepalived
config, (and to the SOURCE column in the above rules) but I wasn't sure
which IP I should actually choose.
Secondly I tried to create all this as a macro, but I wasn't sure if
there was a sane way to get it to include the :224.0.0.18 address. In my
VRRP/ACCEPT $FW net
VRRP/ACCEPT net $FW
VRRP/ACCEPT $FW loc
VRRP/ACCEPT loc $FW
to produce the above. Wasn't sure if shorewall macros can support this.
You'll notice there are two pairs of rules, because I have a public VIP
and also a private VIP on the lan.
Hi James,

With this macro:

# This macro handles bi-directional VRRP traffic
###############################################################################
PARAM SOURCE DEST:224.0.0.18 vrrp
PARAM DEST SOURCE:224.0.0.18 vrrp

You can do it with just two rules:

VRRPBI(ACCEPT) $FW net
VRRPBI(ACCEPT) $FW loc

As you mention above, however, it is a bit permissive because it accepts
VRRP from all net/loc SOURCES. You could tighen that up by qualifying
'net' with the IP address of the other firewall but you can't use a
bi-directional macro in that case:

# This macro handles VRRP traffic
################################################################################
PARAM SOURCE DEST:224.0.0.18 vrrp

with rules:

VRRP(ACCEPT) $FW net
VRRP(ACCEPT) net:<other ip> $FW
VRRP(ACCEPT) $FW loc
VRRP/ACCEPT) loc:<other ip> $FW

Thanks!
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
Loading...