CARP auth not working on 11.2-RELEASE-p9
ASV
asv at inhio.net
Sun Feb 24 10:11:20 UTC 2019
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_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
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_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
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].
..........
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190224/a9ca5707/attachment.sig>
More information about the freebsd-questions
mailing list