CARP auth not working on 11.2-RELEASE-p9

ASV asv at inhio.net
Mon Feb 25 15:31:12 UTC 2019


Clarifications:

- I know that the implementation on FreeBSD is not the same as the
OpenBSD one (as I've been pointed out)
- If the authentication is happening through SHA1-HMAC or else is not
very important.
- The crucial part is to understand if the authentication is working or
not and if not is due to a configuration error or a bug.

Created also a thread here: 
https://forums.freebsd.org/threads/carp-auth-not-working-on-11-2-release-p9.69771/#post-418839
Thank you.

On Sun, 2019-02-24 at 11:10 +0100, ASV wrote:
> Good morning to you all,
> I'm experiencing an annoying issue with the new CARP implementation
> (changed since FBSD 10+) on two identical FreeBSD 11.2-RELEASE-p9
> servers.
> Here the configuration strings in /etc/rc.conf (password same lenght
> and type but modified):
> SRV1: "inet vhid 1 advskew 0 pass add44c97ec0dcd4568b63770c1fe11ef
> alias 10.2.2.130/32"
> SRV2: "inet vhid 1 advskew 100 pass add44c97ec0dcd4568b63770c1fe11ef
> alias 10.2.2.130/32"
> 
> --- IFCONFIG OUTPUT
> SRV1:
> vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
>         options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MT
> U,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_I
> PV6>                                               
>         ether 1e:44:d1:79:bb:2e
>         hwaddr 1e:44:d1:79:bb:2e
>         inet 10.2.2.134 netmask 0xfffffe00 broadcast 10.2.3.255
>         inet 10.2.2.130 netmask 0xffffffff broadcast 10.2.2.130 vhid
> 1
>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>         media: Ethernet 10Gbase-T <full-duplex>
>         status: active
>         carp: MASTER vhid 1 advbase 1 advskew 0
> 
> SRV2:
> vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
>         options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MT
> U,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_I
> PV6>
>         ether 02:ec:50:e2:9c:16
>         hwaddr 02:ec:50:e2:9c:16
>         inet 10.2.2.128 netmask 0xfffffe00 broadcast 10.2.3.255 
>         inet 10.2.2.130 netmask 0xffffffff broadcast 10.2.2.130 vhid
> 1 
>         nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>         media: Ethernet 10Gbase-T <full-duplex>
>         status: active
>         carp: BACKUP vhid 1 advbase 1 advskew 100
> 
> As I did't enable the preemption I'm testing the failover manually
> and
> it works well just as connectivity to the service IP .130.
> Everything works very well BUT authentication!
> As I've read around some apparent issues with passwords longer than
> 32
> chars and I remember years back having troubles with a similar issue
> for a redundant PBX setup, I've tested different kind of passwords:
> - 8-10 chars random wiht special chars
> - 8 chars random no special chars
> - 8 chars only letters (big/small)
> - 8 chars only letters (no capitals)
> - no password at all
> 
> The result is always the same. Therefore, having in production 2
> PFsense clusters at their latest version (2.4.4-RELEASE powered by
> FreeBSD 11.2-RELEASE-p6) I've been digging a bit more and I've
> realised
> that CARP authentication works on the PFsense cluster.
> I've dissected the advertisement packets on both, sanitizing with "
> --"
> the public IP addresses present in the packets, and here is what I
> see:
> 
> _____________________________________________________________________
> ___________________________
> --- Packet on FreeBSD, fields of interest between squared brackets
> 22:57:50.622956 IP 10.2.2.128 > vrrp.mcast.net: VRRPv2,
> Advertisement, vrid 1, prio 100, authtype none, intvl 1s, length 36
>         0x0000:  45 10 00 38 00 00 40 00 ff [70] 8e b1 [0a 02 02
> 80]  E..8.. at ..p......
>         0x0010:  [e0 00 00 12] [21] 01 64 07 [00] 01 8c 06 -- -- --
> --  ....!.d.........
>         0x0020:  -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> --  ................
>         0x0030:  -- -- -- -- -- -- --
> --                      ........
> 
> 70 = Protocol VRRP
> 0a 02 02 80 = Source IP Address
> e0 00 00 12 = Destination IP Address
> 21 = VRRP version 2
> 00 = Auth Type: NO AUTHENTICATION
> 
> 
> --- Packet on PFsense, fields of interest between squared brackets
> 23:14:19.556562 IPv4 (0x0800), length 60: XX.XX.XX.XX > 224.0.0.18:
> VRRPv2, Advertisement, vrid 101, prio 105, authtype simple, intvl 3s,
> length 20
>         0x0000:  45 c0 00 28 00 00 00 00 ff [70] 56 20 [-- -- -- --
> ]  E..(.....pV.....
>         0x0010:  [e0 00 00 12] [21] 65 69 01 [01] 03 ce ff -- -- --
> --  ....!ei.........
>         0x0020:  [6e 4f 63 6e 4f 63 00 00] 00 00 00 00 00
> 00       nOcnOc........
> 
> 70 = Protocol VRRP
> -- -- -- -- = Source IP Address
> e0 00 00 12 = Destination IP Address
> 21 = VRRP version 2
> 01 = Auth Type: Simple Text Authentication [RFC 2338] / Reserved [RFC
> 3768] (1)
> 6e 4f 63 6e .... = Auth string: nOcnOc
> _____________________________________________________________________
> ___________________________
> The output is quite clear, the FreeBSD packets are not using any
> authentication while the PFsense do and I'd love to know why. :)
> The related FreeBSD documentation in the handbook doesn't go into the
> details at any time (https://www.freebsd.org/doc/handbook/carp.html)
> therefore it's better to get the info from who actually wrote the
> tool.
> On OpenBSD FAQ pages there's much more: 
> https://www.openbsd.org/faq/pf/carp.html
> and in the specific, under "CARP Operation:
> 
> "In order to prevent a malicious user on the network segment from
> spoofing CARP advertisements, each group can be configured with a
> password. Each CARP packet sent to the group is then protected by an
> SHA1 HMAC."
> 
> This should be most likely a modified version of the one specified in
> RFC2338 which states MD5-HMAC but that's another story as CARP is a
> re-
> writing of VRRP (to my understanding), moreover the RFC is very old
> and
> MD5 is no longer considered secure, so that's good.
> 
> About the password type/lenght limitation no mention anywhere:
> https://man.openbsd.org/carp
> https://man.openbsd.org/ifconfig.8#CARP
> 
https://www.freebsd.org/cgi/man.cgi?query=ifconfig&sektion=8&apropos=0&manpath=FreeBSD+12.0-RELEASE+and+Ports
> 
https://www.freebsd.org/cgi/man.cgi?query=carp&apropos=0&sektion=0&manpath=FreeBSD+12.0-RELEASE+and+Ports&arch=default&format=html
> 
> 
> Am I missing something trivial?
> Any hint would be highly appreciated. I have no clue.
> Thanks
> 
> 
> QUOTING SOME RFC REFERENCE
> 
> The RFC3798 doesn't even mention "authentication". So let's talk only
> about RFC2338 which has 1 related chapter, the 10th.
> 10. Security Considerations
>    ..........
>    The protocol includes several
>    authentication methods ranging from no authentication, simple
> clear
>    text passwords, and strong authentication using IP Authentication
>    with MD5 HMAC.
>    ..........
> 
> 10.1 No Authentication
> 
>    The use of this authentication type means that VRRP protocol
>    exchanges are not authenticated.  This type of authentication
> SHOULD
>    only be used in environments were there is minimal security risk
> and
>    little chance for configuration errors (e.g., two VRRP routers on
> a
>    LAN).
> 
> 10.2 Simple Text Password
> 
>    The use of this authentication type means that VRRP protocol
>    exchanges are authenticated by a simple clear text password.
>    ..........
>    This type of authentication does not protect against
>    hostile attacks where the password can be learned by a node
> snooping
>    VRRP packets on the LAN.
>    ..........
> 
> 10.3 IP Authentication Header
>    The use of this authentication type means the VRRP protocol
> exchanges
>    are authenticated using the mechanisms defined by the IP
>    Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within
> ESP
>    and AH", [HMAC].
>    ..........



More information about the freebsd-questions mailing list