Hello, I've found that after recstart of standby node of OpenBSD firewall cluster after sasyncd startup flows are synchronized from master but SAD's are not. I've investigated problem and found that this patch breaks this function:
[ https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pfkeyv2.h.diff?r1=1.89&r2=1.90&f=h | https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pfkeyv2.h.diff?r1=1.89&r2=1.90&f=h ] And propably there is other patch that make this function not work properly. The reason is because during synchronization of states sasyncd aquiers states, encrypts almost-raw kernel message, send it to other sasyncd daemon where this message is decrypted and sent to kernel to set new states. Fortunetly kernel in function pfkeyv2_parsemessage() performs sanity checks of received from sasyncd message and finds out that it knows nothing about SADB_X_EXT_REPLAY extension end returns EINVAL and state is not created. I've added for tests part of code to allow this extension to pass sanity checks and then I've hit another extension that it is not allowed on message whitch is SADB_X_EXT_COUNTER. After adding this to parser function new states are created as they should be but i suppose that in some cases SADB_X_EXT_MTU extension also may be set and if so sasyncd silently will not create states either. please find out patch in attachment. How I discovered found error and solution? Following message that should create state is not valid according to the kernel: net_read: post decrypt 0203000243000000000000000000000002000100cdc34e701001050c0402000004000200 000000000000000000000000d2e3cd650000000000000000000000000400040000000000 0000000000000000a80c0000000000000000000000000000040003000000000000000000 00000000100e0000000000000000000000000000030005000000000010020000d45b18a6 00000000000000000300060000000000100200000d3012d5000000000000000005000a00 0100000000000000000000003231322e39312e32342e3136362f33320000000000000000 04000b0001000000000000000000000031332e34382e31382e3231332f33320005000800 000100005374b0606dc43282d401cf26ad15693c1336852981a56cd6c57c0098ef22dc51 05000900000100002883b249a6964a07aa7f86571e70eb495e200fb692cff1434a78c49a 05b14d38010014000102000001001300000000000300150000000000100200000a020f00 0000000000000000030011000000000010020000ffffff00000000000000000003001600 0000000010020000ac1f00000000000000000000030012000000000010020000fffff000 000000000000000001001f00119400000200270000000000010000000000000009002400 000000000000000000000000000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000000000000000008070605 04030201 net_read: computed hash 1ee903f3fa270d5e55dafddf0f251e8230d080cc net_handle_messages: got msg type 1 len 536 from peer 172.31.255.245 pfkey_queue_message: pfkey ADD len 536 seq 12 sasyncd: pfkey: msg ADD write() failed on socket 4: Invalid argument net_read: got hash So I've enabled encdebug recompiled kernel, restarted it found following message related to this "Invalid argument" message: /bsd: pfkeyv2_parsemessage: extension header 39 not permitted on message type 3 When I've added handling of SADB_X_EXT_REPLAY to the parser function and restarted the kernel states was still not created but this time following error was recorded: /bsd: pfkeyv2_parsemessage: extension header 36 not permitted on message type 3 So I've added similar change for extension SADB_X_EXT_COUNTER too. I additionally see that in pfkeyv2.h in my version of OpenBSD (7.3) there is also SADB_X_EXT_MTU extension that will cause message parser fail if it will appear. Additionally in current there is also SADB_X_EXT_IFACE extension that that pfkeyv2_parsemessage is also unaware. Rafał Ramocki Technical Care Center E-mail: [ mailto:rafal.ramo...@eo.pl | rafal.ramo...@eo.pl ] eo NETWORKS S.A. NIP: 527-260-44-18 WWW: [ https://eo.pl/ | eo.pl ] ul. Jagiellońska 78, KRS: 0000332547 TEL: (022) 532-15-30 03-301 Warszawa BDO: 000200011 FAX: (022) 532-15-31 Sąd Rejonowy dla m.st.. Warszawy w Warszawie XIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy i kapitał wpłacony: 205 937,90 złotych. Zapoznaj się z naszą polityką prywatności [ https://eo.pl/rodo/polityka-prywatnosci/ | tutaj ] Read our privacy policy [ https://eo.pl/en/gdpr/privacy-policy/ | here ]
Index: net/pfkeyv2_parsemessage.c =================================================================== RCS file: /cvs/src/sys/net/pfkeyv2_parsemessage.c,v retrieving revision 1.60 diff -u -p -r1.60 pfkeyv2_parsemessage.c --- net/pfkeyv2_parsemessage.c 14 Jul 2021 22:39:26 -0000 1.60 +++ net/pfkeyv2_parsemessage.c 16 Feb 2024 16:32:31 -0000 @@ -143,9 +143,9 @@ uint64_t sadb_exts_allowed_in[SADB_MAX+1 /* GETSPI */ BITMAP_ADDRESS_SRC | BITMAP_ADDRESS_DST | BITMAP_SPIRANGE, /* UPDATE */ - BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_ADDRESS_PROXY | BITMAP_KEY | BITMAP_IDENTITY | BITMAP_X_FLOW | BITMAP_X_UDPENCAP | BITMAP_X_TAG | BITMAP_X_TAP | BITMAP_X_RDOMAIN, + BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_ADDRESS_PROXY | BITMAP_KEY | BITMAP_IDENTITY | BITMAP_X_FLOW | BITMAP_X_UDPENCAP | BITMAP_X_TAG | BITMAP_X_TAP | BITMAP_X_RDOMAIN | BITMAP_X_REPLAY | BITMAP_X_COUNTER, /* ADD */ - BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_KEY | BITMAP_IDENTITY | BITMAP_X_FLOW | BITMAP_X_UDPENCAP | BITMAP_X_LIFETIME_LASTUSE | BITMAP_X_TAG | BITMAP_X_TAP | BITMAP_X_RDOMAIN, + BITMAP_SA | BITMAP_LIFETIME | BITMAP_ADDRESS | BITMAP_KEY | BITMAP_IDENTITY | BITMAP_X_FLOW | BITMAP_X_UDPENCAP | BITMAP_X_LIFETIME_LASTUSE | BITMAP_X_TAG | BITMAP_X_TAP | BITMAP_X_RDOMAIN | BITMAP_X_REPLAY | BITMAP_X_COUNTER, /* DELETE */ BITMAP_SA | BITMAP_ADDRESS_SRC | BITMAP_ADDRESS_DST | BITMAP_X_RDOMAIN, /* GET */ @@ -858,6 +858,19 @@ pfkeyv2_parsemessage(void *p, int len, v return (EINVAL); } break; + case SADB_X_EXT_REPLAY: + if (i != sizeof(struct sadb_x_replay)) { + DPRINTF("bad REPLAY header length"); + return (EINVAL); + } + break; + case SADB_X_EXT_COUNTER: + if (i != sizeof(struct sadb_x_counter)) { + DPRINTF("bad COUNTER header length"); + return (EINVAL); + } + break; + #if NPF > 0 case SADB_X_EXT_TAG: if (i < sizeof(struct sadb_x_tag)) {