PF1.2.3 replies to non-existent VRRP/CARP MAC

  • Hi guys,

    we've been pulling our hair out all day here, if anyone has any ideas I'm open to pretty much anything at this stage.

    Setup (these are all internal firewalls, so have "ignore RFC1918" unchecked - as all interfaces are RFC1918. we route out to the internet at a higher level, this problem purely involves the internal routing)

    node A -> PF 2.0.1 (single node) -> PF 1.2.3 (two systems using CARP VIPs) -> node B

    node B can ping node A fine.
    node A cant ping node B. on investigation, we see ICMP echo requests and replies at the in/out interfaces on PF1.2.3, and at node B. what seems to be happening is that PF1.2.3 is sending the ICMP echo replies to a VRRP MAC address (00:00:5e:00:01:01). VRRP/CARP isnt enabled on the PF2.0.1 box, and I dont see this MAC in any of the packets leaving here (or arriving at PF1.2.3). The ARP request from PF1.2.3 to PF2.0.1 for its MAC address returns the correct one (ie not the 00:00:5e…. one).

    So it seems that PF1.2.3 is overriding the destination MAC somehow, but I have no idea where this is coming from or why or how to overcome it (we've tried enabling CARP on PF2.0.1 but no effect).

    It's effectively pulled half the network offline to this box...



  • Rebel Alliance Developer Netgate

    What that means is that it's directing packets to some CARP or VRRP IP with vhid = 1.

    The 1.2.3 box wouldn't need to have CARP on to do this, it just means that at some point it got back that MAC when it did an ARP request for an IP. Check the ARP table to be sure.

    Sounds like you might need to disable reply-to, which I don't think actually worked on 1.2.3. If it's there, it's in the advanced options under Firewall/NAT.

  • Thanks Jimp,

    you're right, that MAC address turns out to be the VIP of the firewall cluster that acts as the default gateway on the WAN interface of the PF 1.2.3 cluster.

    What I dont understand though is that the route back to node A is via the PF 2.0.1 box, this route is visible in the routing table, and the arp table shows the correct MAC associated with this 2.0.1 box. So the 1.2.3 systems seem to be ignoring the routing table entry for this network and just forwarding to the default. I'd put that down to some wierdness in PF except we have another network to anotehr router where this behaviour doesnt occur (ie it just works as expected).

    I've disabled reply-to anyway. no change as yet. I'll try and bounce the primary out of hours and see if that helps (but not hopeful, I did a bounce on the backup last night and routed some traffic through there - no effect).

    In the mean time, looks like as this isnt a CARP issue this is probably posted in the wrong place, any way to get it moved?


Log in to reply