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 ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 3/12/11 12:28 AM, James Shubin wrote:> 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.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 \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On Sat, 2011-03-12 at 08:09 -0800, Tom Eastep wrote:> > # 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> $FWThis is very elegant, shorewall has great macros! I tested this and it works perfectly. I''ve attached a copy for inclusion into shorewall (in case it hasn''t been done already) If devel would prefer an actual git patch, then please let me know. James PS: I cleaned up the formatting slightly to make the macro more readable... ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
> > PS: I cleaned up the formatting slightly to make the macro more > readable...Thanks, James. The macro will be included in 4.4.19. -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 \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d