Кирилл Васильев

Поднимете туннель, IPSEC over GRE, а концы туннелей будут шлюзами, только не забудьте про output цепочку для построения самого туннеля и ipsec

это, всё?
а конфиги?

как обычно жесть в ответах, а теперь по существу, а именно по вашему конфигу

add action=fasttrack-connection chain=forward connection-state=established,related
add chain=forward connection-state=established,related

Если не уверенны, то лучше цепочку forward в фильтре не трогать, темболее что у вас скорее всего forward это только трафик попадающий под NAT
Отключите эти правила

add chain=input connection-state=established,related in-interface=ether1-gateway

Здесь всё правильно, весь трафик который будет попадать под следующие правила будет connection-state=new
Оставляем как есть

add action=reject chain=input connection-state=new in-interface=ether1-gateway

Указывая reject вы злоумышленнику даёте явно понять, что порты закрыты, reject лучше всего делать на внутреннюю сеть или в сторону партнёров, но точно не для трафика в сторону интернета!
Замените на drop
Читай пояснения для вышестоящего правила, убери connection-state=new, так на данном месте фаервола только и будет new

add action=drop chain=input connection-state=invalid in-interface=ether1-gateway

Данное правило, должно быть самым первым так как, это невалидный трафик, смысл напрягаться фильтру, если мы заранее знаем что этот трафик не нужен.
Переместить правило на самый верх
При таком настроенном фильтре, микротик находится в самом защищённом режиме.
если вам необходимо открыть порт для доступа к микротику, то вы создаёте правило над последним правилом.
Если вы будете открывать ssh к микротику, то прочитайте эту статью wiki.mikrotik.com/wiki/Bruteforce_login_prevention

Всё остальное, такие как /ip service - это всё от лукавого, в любой момент времени может получится так что вам потребуется доступ к по ssh из самого не предсказуемого места.
если уж хотите вообще не открывать всем порты, то читаем про port Knocking тут wiki.mikrotik.com/wiki/Port_Knocking

выключите правила в фильтре drop forward, потом проверяйте NAT.
Сначала настраиваем mangle потом NAT и уже в конце подытоживаем фильтром

Невнимательность

/ip dhcp-server network
add address=10.20.10.0/32 dns-server=10.20.10.2 gateway=10.20.10.2 netmask=24
add address=172.16.0.0/32 dns-server=10.20.10.2 gateway=172.16.0.2 netmask=24 ntp-server=172.30.7.2

А должно быть

/ip dhcp-server network
add address=10.20.10.0/24 dns-server=10.20.10.2 gateway=10.20.10.2 netmask=24
add address=172.16.0.0/24 dns-server=10.20.10.2 gateway=172.16.0.2 netmask=24 ntp-server=172.30.7.2

и укажите на микротике адрес релея в dhcp сервере.

Также объясните для чего вам такая конструкция?

/ip route vrf
add interfaces=Voice routing-mark=1

Вашаете общую очередь на интерфейс, с ограничением в ширину канала (допустим 10mb/s)
Далее делаете два наследника от это очереди и в более приаритетной задаёте limit-at 10mb/s, а у обеих очередей max-limit ставите 10mb/s, тем самым для одной очереди вы гарантируете канал, для второй отдаёте, всё что осталось

Несколько вариантов, скорее всего астериск пытается поднять транк, до поднятия VPN на микротике.
Явно в фаерволе микротика запретите такой трафик.
Скорее всего через сутки транк поднимается из за conaction-tracker микротика, прибейте явно руками конекты от вашего астериска.
также если вы не используете вообще NAT для sip трафика, то выключите хелпер /ip firewall service-port disable sip