Привет, @najimurad, ты решил эту проблему? У меня такая же ситуация: если я отключаю фаерволл DC, мой CT может пинговать внешний адрес, а если включаю — пинга нет. Я пытался создать правило ACCEPT ALL IN, но проблема осталась...

Пробовали включить предварительный просмотр технологии nftables на каждом узле? У меня было много проблем с файрволом на роутерных виртуальных машинах, пока я это не сделал.

У меня на продакшн-кластере работает EVPN с использованием nftables. С iptables была та же проблема — обратный трафик блокировался. Несколько месяцев назад я создавал по этому поводу тему, но просто включение этого режима решило все мои проблемы. Возможно, это всё ещё экспериментально, но стоит хотя бы проверить.

Настроить EVPN оказалось довольно просто, как только разобрался — под капотом там просто FRR. Документация, правда, оставляет желать лучшего, нужны примеры из лабораторных условий и сценарии взаимодействия. Сейчас у нас это работает с коммутаторами Dell OS10 и внешней маршрутизацией без SNAT.

Когда я тестировал это, у меня было 2 выходных узла с основным выходным узлом. Я тщательно проверял разные конфигурации EVPN, чтобы решить эту проблему. И настроил более свободные правила PVE-файрвола. Логировал все “марсианские” пакеты и настроил rp_filter. Но, как я уже упоминал, оказалось, что iptables каким-то образом блокировал пересылку обратного трафика (при том что у меня не было никаких кастомных правил iptables). А ручная команда "iptables -I FORWARD 1 -j ACCEPT" позволила пропускать обратный трафик. Насколько я понимаю, iptables и rp_filter работают по разной логике, так что правила файрвола были как-то неправильно настроены. Мои знания не идеальны, возможно, я что-то упустил. Но я думал, что EVPN SNAT будет работать сразу из коробки, а в моём случае так не получилось.

извиняюсь, неправильно информацию дал