[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keepalived-devel
Subject:    [Keepalived-devel] firewall rules for the vrrp interface
From:       Sial Nije <sialnije () gmail ! com>
Date:       2014-05-19 3:28:12
Message-ID: CAHO7rrcaH8owCYAjM1AifAt3K7MJaCu57uuSQ9Xdpee1RdgP_A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Greetings,

I am trying to set up VRRP on my WAN interface and is puzzled by some
conflicting behavior on firewall rules.

My set up is like this:
- Vyatta-6.4 which is Debian 6.05 and uses keepalived 1.2.2
- rfc 3768 mode
- WAN interface is eth0
- VRRP interface is a separate interface named eth0v1 (created by
keepalived I assume)

Before adding VRRP, I have firewall rules attached to eth0 only. After
adding VRRP, I notice that these rules don't apply to packets destined for
the VRRP IP address. So looks like the kernel treats eth0v1 as a separte
entity. This looks reasonable.

The strange part is I also have firewall rules on eth0 whether to forward
packets to the internal network.
If eth0v1 is a separate interface, packets should be forwarded to the
internal network without restriction. There are no firewall rules
on eth0v1 yet so nothing to block forwarding.
But this is not the case.
I found that I need to add forward rules for both eth0 and eth0v1. Most of
the time the rules for eth0v1 are hit. Occasionally kernel
does not think the forwarding rules on eth0v1 match and I have to clone
forwarding rules on eth0.
By the way, the packets to be forwarded to the internal network are IPSec
packets encapsulated in UDP (rfc 3948).
Don't know if UDP encapsulation has something to do with the inconsistent
behavior or not.

Thanks for help.
sial

[Attachment #5 (text/html)]

<div dir="ltr"><div><div><div><div><div><div><div><div>Greetings,<br><br></div><div>I \
am trying to set up VRRP on my WAN interface and is puzzled by some conflicting \
behavior on firewall rules.<br></div><br></div><div>My set up is like this:<br> \
</div>- Vyatta-6.4 which is Debian 6.05 and uses keepalived 1.2.2<br>- rfc 3768 \
mode<br></div>- WAN interface is eth0<br>- VRRP interface is a separate interface \
named eth0v1 (created by keepalived I assume)<br><br></div> Before adding VRRP, I \
have firewall rules attached to eth0 only. After adding VRRP, I notice that these \
rules don&#39;t apply to packets destined for the VRRP IP address. So looks like the \
kernel treats eth0v1 as a separte entity. This looks reasonable.<br> <br></div>The \
strange part is I also have firewall rules on eth0 whether to forward packets to the \
internal network.<br></div>If eth0v1 is a separate interface, packets should be \
forwarded to the internal network without restriction. There are no firewall \
rules<br> on eth0v1 yet so nothing to block forwarding. <br>But this is not the \
case.<br></div>I found that I need to add forward rules for both eth0 and eth0v1. \
Most of the time the rules for eth0v1 are hit. Occasionally kernel<br> \
</div><div>does not think the forwarding rules on eth0v1 match and I have to clone \
forwarding rules on eth0.<br></div><div>By the way, the packets to be forwarded to \
the internal network are IPSec packets encapsulated in UDP (rfc 3948).<br> \
</div><div>Don&#39;t know if UDP encapsulation has something to do with the \
inconsistent behavior or not.<br><br></div><div>Thanks for \
help.<br></div><div>sial<br></div><div><br></div><div><div><div><div><div><br></div></div>
 </div></div></div></div>



------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs

_______________________________________________
Keepalived-devel mailing list
Keepalived-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel


[prev in list] [next in list] [prev in thread] [next in thread]