Seeing CARP multicast traffic on inapplicable interface
-
I have a pretty simple setup by most people's standards. I have two pfSense firewalls in a CARP failover setup (technically one of the firewalls is not active right now because I'm in the process of testing 2.0-RC3). They have the following interfaces:
WAN (fxp0) - Internet
LAN (fxp1) - Connected to primary LAN
OPT1 (fxp2) - Used for pfsync directly between the two firewalls
OPT2 (rl0) - Connected to secondary LANThe active firewall is running 2.0RC3 (snapshot from Sun Sep 11 21:36:53 EDT 2011).
The WAN interface has a CARP IP address (x.x.49.178) and WAN IP address (x.x.49.180) assigned to it. The LAN has a similar setup (CARP: 192.168.5.1, LAN: 192.168.5.3).The CARP itself is working fine (I had it working when both boxes were running pfSense 1.2.3).
What is interesting is what started happening when I added the OPT2 interface for a secondary LAN. The secondary LAN subnet is 192.168.3.0/24, which then actually has another switch connected to it to subdivide into another LAN segment (it's essentially independent from the primary LAN). What is happening is I am now seeing a log entry every second for blocked CARP multicast traffic from the WAN IP to the OPT2 interface.
Sep 15 12:06:12 firewall-office2 pf: 00:00:01.000974 rule 11/0(match): block in on rl0: (tos 0x10, ttl 255, id 14550, offset 0, flags [DF], proto VRRP (112), length 56)
Sep 15 12:06:12 firewall-office2 pf: x.x.49.180 > 224.0.0.18: VRRPv2, Advertisement, vrid 10, prio 0, authtype none, intvl 1s, length 36, addrs(7): 10.115.242.51,27.189.174.69,215.209.30.82,102.2.72.244,135.155.120.66,138.75.156.232,61.52.149.37The question becomes why is there CARP multicast traffic going from the WAN interface to the OPT2 interface when they have nothing to do with each other in regards to the CARP setup? Obviously the machines on OPT2 are not going to care about who the current CARP master is on the WAN because it's a completely different subnet. When I do a tcpdump on the firewall itself to look at the other CARP multicast traffic, the LAN CARP address doesn't do this (it is only broadcasting on the LAN interface). It doesn't try to broadcast on WAN or OPT2.
The funny thing is that even if I put in a rule on OPT2 to explicitly block traffic from x.x.49.180 > 224.0.0.0/4, any protocol, it is still showing blocked packets in the logs (even though I don't have that rule set up to log matches).
It's not a huge amount of generated traffic, but it's filling up my logs very quickly (I have remote syslog turned on). This doesn't seem normal. What might I have that is misconfigured?
-
You somehow have layer2 connected between WAN and OPT2. Otherwise the traffic would not be seen on OPT2.
-
Bingo. I'm not a network admin by any means (sysadmin is my primary role), but that gave me enough information to figure out the problem. I didn't explain the details of how all of the switches were connected (which appeared to be more important than I thought), but here's the diagram for future people.
Internet | | ------------- | L L L L L | Switch 1 ------------- | | | --------- (to router WAN) | | WAN | ------------- | | W L L L L | Router 1 | ------------- firewall1 | | | | | | | | | | LAN OPT2 ------- -------- (to secondary LAN switch)The CARP multicast was going out of the firewall WAN, then reaching the router WAN. The router WAN (D-Link DI-524) was setup to pass multicast traffic through to the LAN, which then made it show up on the same network as OPT2. I disabled the multicast forwarding on the DI-524 and the packets stopped.
For those that wonder why I'm doing it this way, the two firewalls on the secondary LAN also use load balancing on their WAN interfaces and need three IP addresses. I don't have enough public IP addresses to assign to the two pfSense firewalls plus the other two firewalls, so I'm doing a 1-1 NAT of one public IP through the DI-524 onto the virtual IP of the two firewalls on the secondary LAN. The OPT2 interface is for creating an IPsec tunnel between the two networks that doesn't traverse any of the public Internet.
Thanks for your help.
