3.9.1

управление от кш пакеты на порт 5109 и обратно

Они ещё по LAN доступны друг другу, но общаются только через внешние интерфейсы почему-то

в tcpdump не вижу попыток по такому порту

да и в целом все другие 3.9.1 точки то доступны, а эти КШ и ЦУС вообще находятся в одной сети и внешними и внутренними адресами

Но он не за NAT...

посмотрите правила, вдруг...

Нет, никаких правил нет

Говорю же, КШ и ЦУС друг другу доступны в рамках одной сети LAN и одной сети WAN

и общаются они в рамках одной сети? а не так чтоб в одну сторону по одной, а обратно по другой?

Судя по tcpdump на данный момент да

Ключи, кстати, обновились, судя по сведениям о загруженных ключах

А по дампу трафика на внешнем интерфейсе КШ есть служебные пакеты с ip адресом ЦУС?

Также, можно посмотреть дамп  на внешнем интерфейсе ЦУС, приходят ли пакеты и отвечает ли он

пакеты приходят "от КШ до ЦУС ходят пакеты с порта 10000(кш) на 5107 и 5106 (цус)", но ЦУС на них не отвечает

Возможно ключи не совпадают. Можно через ПУ ЦУС выгрузить ключ для данного КШ и загрузить его локально

а это ни о чем не говорит?

На всякий случай ещё раз уточню положение:
КШ с ЦУС имеет протухший ключ
Просто КШ имел протухший ключ
После смены ключа на "просто КШ" в ПУ ЦУС отображается как "Отключен", при этом со всеми другими КШ туннели продолжают работать.
При этом ключи на "просто КШ" обновились, судя по дате в сведениях о загруженных ключах

VPN и управление разные ключи. На ЦУС горит значек смены ключа для КШ, который является параллельным сервисом ЦУС+КШ этот ключ меняется только локально. Если у Вас сейчас асинхронная маршрутизация получилась, видите ли Вы в tcpdump что пакеты от ЦУС до внешнего интерфейса "просто КШ" идут с внутреннего интерфейса? Просто если пакеты приходят на ЦУС, то ответ должен идти куда-то, надо найти куда они уходят. Если не куда не уходят, то либо у вас эти адреса попадют в защищаему сеть с кем есть VPN у ЦУС, либо с ЦУС что-то произошло и надо очистить текущие сессии или просто ребутнуть.