Thank you very much for your help.

Log told me some ideas. In my case, interface assignment on both devices was slightly different. After I reassigned them, it began to work.

Thanks again!

Hi Francesco and All,

i'm exactly in the same situation, but with a physical server with two physical NICs

Two NICs with CARP on the same switch/VLAN (WAN side)

My ISP provide me 2 public IP subnets in the same cable.
This cable is pluggel in my cisco switch in a port configured in access mode with VLAN X

Other two ports on the same cisco switch are configured in access mode on the same VLAN X.
In these two ports are connected two PFS WAN NICs with this configuration:

WAN (wan)      -> em1        -> v4: a.a.a.a/27
WAN2 (opt9)    -> em3        -> v4: b.b.b.b/27

My filter.log is flooded by these messages:

rule 38/0(match): block in on em3: (tos 0x0, ttl 255, id 37753, offset 0, flags [DF], proto VRRP (112), length 56)
    a.a.a.a > 224.0.0.18: VRRPv2, Advertisement, vrid 108, prio 0, authtype none, intvl 1s, length 36, addrs(7): 77.110.34.171,61.17.65.165,90.166.164.7,254.92.249.181,89.34.91.45,24.56.193.51,49.113.148.220
00:00:00.001830 rule 38/0(match): block in on em3: (tos 0x0, ttl 255, id 64989, offset 0, flags [DF], proto VRRP (112), length 56)

and

rule 38/0(match): block in on em1: (tos 0x0, ttl 255, id 15937, offset 0, flags [DF], proto VRRP (112), length 56)
    b.b.b.b > 224.0.0.18: VRRPv2, Advertisement, vrid 226, prio 0, authtype none, intvl 1s, length 36, addrs(7): 189.142.72.18,82.162.93.207,80.97.204.246,226.201.105.180,72.151.119.172,252.49.36.205,219.112.155.93
00:00:00.178021 rule 38/0(match): block in on em1: (tos 0x0, ttl 255, id 46149, offset 0, flags [DF], proto VRRP (112), length 56)

I already checked:

VIPs configuration ( all netmask OK, Base 1 and Skew 0 for all VIPs, VHID Group # dedicated for each VIP, same pwd) netmask in WAN and WAN2 conf;

Is there a way to solve this? Or a way to hide these messages if they are not a serious network issue?
Note: I have another couple of PFS firewall in the same switch and in the same VLAN X and a third public IP subnet (c.c.c.c) , but i don't see VRRP/CARP message in filter.log. With a tcpdump on wan interface I can see VRRP messsage but this is right.

pfs 2.1-RELEASE (i386)

Thank you and best regards

Simone

In that situation the secondary would only process traffic if it is the carp master, not when it is the carp backup. If the primary fails, it would still pass traffic as expected, but when the primary is up it would have no external connectivity.

Check the logs. A packet capture will show if something is using CARP/VRRP on the wire and what VHIDs are in use. It seems unlikely that you would see VRRP traffic on the LAN unless you are not in control of the LAN side of your network.

this is ok now, it happens that one mac address is causing that trouble when it was deleted everything works fine

xxx.xxx.xxx.121 and 122 were accessible. After I modified the firewall rule (WAN address to WAN net), it began to work! Thank you very much!

I think you're right, I was messing with promiscuous mode on virtualbox nics and everything started working some what  fine but still wasn't working as intended.

What I wanted to do was set this up on my server which is running a virtual instance of pfsense for my network at home, lately my server has been having issues and I kept breaking stuff and the internet goes down for few hours; and it becomes difficult to fix things when you don't have the resources of the internet and have to rely on a mobile data plan from your phone. But anyways what I wanted to do was, I had a physical box which use to be my old pfsense router burning 80watts 24/7 which is why I went to virtual setup. Anyways I wanted to CARP to this box so I can take down the server for maintenance and still have internet and not interrupt anybody in the home, who may be playing video games, watching netflix so on.

The server runs CentOS 6.5 with KVM, and pfsense utilizes virtio drivers. I can't find anything for promiscuous mode settings for KVM, even though a web search suggest to acknowledge that a promiscuous mode setting does exist. I just have no idea how yet, although I haven't dug deep into it yet.

You can probably swap out the cables without anyone noticing.  Do the backup box first, then disable CARP on the primary and change those too.

If your NICs are all built in then I'd probably go to the switch next.  You may just have to declare a maintenance window on that one.

Had same issue yesterday.
I was connected via OpenVPN to pfSense. The OVPN server is bound on a WAN CARP VIP and my web GUI is reachable on LAN address only.

I just hit the button to add an interface and the VPN was broken. No way to get access from remote again.
That's a bad circumstance if the firewall is more than 20 km away and it's late at night!    :-
My pfSense is 2.1.1

Does anybody know if this behaviour just aply to bounded services on CARP VIPs or will it be the same if I bind OVPN on an IP Alias?

To the best of my knowledge, this is not a supported configuration.

With that said….  you could try a crossed virtual ip configuration; however, without extensive testing, I'm not sure I would attempt to toss this into a production environment...

On your LAN...

FW1 = 192.168.0.3/24
FW2 = 192.168.0.4/24

CARPVIP1 = 192.168.0.1/24 (Active on FW1 - Skew FW1=0 / Skew FW2=100)
CARPVIP2 = 192.168.0.2/24 (Active on FW2 - Skew FW1=100 / Skew FW2=0)

Have DHCP on FW1 hand out .1 as Gateway, have FW2 hand out .2 as Gateway

If either FW goes down, the VIP fails over to the other FW and responds for both gateway IP's..  You'll probably need to disable XMLRPC sync for the CARP VIPs and manually configure them.

...c

Great.  Thanks!

Thanks for the replies.

I have installed both firewalls now, and as I went through the configuration process, it all became clear.

Thanks again. :)

0/ Is the switch managed/VLAN capable? If not, go to shop.
1/ Huh? Bridging and isolation in one sentence?
2/ Where's the wireless magic thing? Cannot see any.
3/ Turn OFF the firewall on whatever you are pinging.
4/ Look at the firewall logs
5/ If you still have problems, you need to post your interfaces setup, firewall rules etc.

I got some help from the IRC pfSense channel and it seems to be working now (I tried it on my test environment).

I was suggested to uncheck "System: Advanced: Miscellaneous: State Killing on Gateway Failure". It is a new feature and checked by default (although this means inactive, see description).

Using Oracle VirtualBox.

The way to monitor it: If the heartbeats stop being seen by the slave, it takes over as master. It's logged in the system log.

If you want to decrease the sensitivity, increase the advbase on the VIPs. A higher base means that it will be less sensitive to a problem but it also takes longer to detect an outage.