From owner-freebsd-questions@freebsd.org Sun Feb 24 10:11:20 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0D711519A10 for ; Sun, 24 Feb 2019 10:11:20 +0000 (UTC) (envelope-from asv@inhio.net) Received: from cz-prg-mx-01.inhio.net (mail.inhio.net [178.238.36.226]) by mx1.freebsd.org (Postfix) with ESMTP id 1A6628E2FA for ; Sun, 24 Feb 2019 10:11:17 +0000 (UTC) (envelope-from asv@inhio.net) Received: from titanio (titanio.inhio.net [10.0.0.21]) by cz-prg-mx-01.inhio.net (Postfix) with ESMTPSA id 91C7E2D1DE for ; Sun, 24 Feb 2019 11:11:07 +0100 (CET) Message-ID: <98749ba3046b58a8cba54e6befb976d82d45f900.camel@inhio.net> Subject: CARP auth not working on 11.2-RELEASE-p9 From: ASV To: freebsd-questions@freebsd.org Date: Sun, 24 Feb 2019 11:10:57 +0100 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-VIQsltu82BlZDOTVEB5B" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 X-Rspamd-Queue-Id: 1A6628E2FA X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asv@inhio.net designates 178.238.36.226 as permitted sender) smtp.mailfrom=asv@inhio.net X-Spamd-Result: default: False [-8.40 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; DMARC_NA(0.00)[inhio.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[mail.inhio.net]; NEURAL_HAM_SHORT(-0.86)[-0.857,0]; SIGNED_PGP(-2.00)[]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:24971, ipnet:178.238.32.0/20, country:CZ]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(-3.73)[ip: (-9.91), ipnet: 178.238.32.0/20(-4.96), asn: 24971(-3.85), country: CZ(0.07)]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2019 10:11:20 -0000 --=-VIQsltu82BlZDOTVEB5B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=3D8943 metric= 0 mtu 1500 options=3D6c07bb = =20 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=3D29 media: Ethernet 10Gbase-T status: active carp: MASTER vhid 1 advbase 1 advskew 0 SRV2: vtnet0: flags=3D8943 metric= 0 mtu 1500 options=3D6c07bb 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=20 inet 10.2.2.130 netmask 0xffffffff broadcast 10.2.2.130 vhid 1=20 nd6 options=3D29 media: Ethernet 10Gbase-T 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.= .@..p...... 0x0010: [e0 00 00 12] [21] 01 64 07 [00] 01 8c 06 -- -- -- -- ...= .!.d......... 0x0020: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- .........= ....... 0x0030: -- -- -- -- -- -- -- -- ........ 70 =3D Protocol VRRP 0a 02 02 80 =3D Source IP Address e0 00 00 12 =3D Destination IP Address 21 =3D VRRP version 2 00 =3D 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 =3D Protocol VRRP -- -- -- -- =3D Source IP Address e0 00 00 12 =3D Destination IP Address 21 =3D VRRP version 2 01 =3D Auth Type: Simple Text Authentication [RFC 2338] / Reserved [RFC 376= 8] (1) 6e 4f 63 6e .... =3D 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:=20 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=3Difconfig&sektion=3D8&apropos=3D= 0&manpath=3DFreeBSD+12.0-RELEASE+and+Ports https://www.freebsd.org/cgi/man.cgi?query=3Dcarp&apropos=3D0&sektion=3D0&ma= npath=3DFreeBSD+12.0-RELEASE+and+Ports&arch=3Ddefault&format=3Dhtml 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]. .......... --=-VIQsltu82BlZDOTVEB5B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEE5dE8BwbhhcQw2TsezaQsUNd+zIkFAlxybbEACgkQzaQsUNd+ zIl4fQf9GfhLSP+SjuVZGvUamjCUcf+QSyhYVmoPQiNfwyA+BPgv5ZKKbDLWG/A1 NAc54Z2syKH5TIKPxHPWStHxfjyqujHgDGMpmXTijP8bMjlN6nJ1p4p6JQEu8iV5 qXiYZs8i7tM5/RNGVKazHuuceZ1wrZFaYBKx2OUbhopYRNPunQ7Bbkz6+xaQBREH VDBLObgEjDAaO9ix4yzQ/SXUCBmYUv2YMKf1jU1hdsQ8DAeOrNrO+qY9aOridGz4 qwVaepJ/VLoUlm2vo+0QX9pDXBj8pea0jAOPZpKH6kGxIQ1hQbZNPtNxOSvnwGNc gGoNR0VoPE1S78AIhXdhpQETtFk6YQ== =i0Qw -----END PGP SIGNATURE----- --=-VIQsltu82BlZDOTVEB5B--