Может файлики не для той платформы залили? И, как выше спросили, какой фирмвеер?

Фирмвеер это что?

прошивка

System routerboard покажите

6.47.8

Ниже не опустить. Разве что через нетинстал(могу ошибаться), коллеги поправьте если так

Проблема в том что сделал экспорт с микротика с ос 6.41.3 а теперь надо залить на 6.47.8

Построчно с пониманием.

Построчно ошибок не выдаёт, но импорт не делает

Как это? А что происходит?

Вот как то так. Ни чего. Некоторое время думает, потом появляется надпись интерфейс с просьбой что то ввести и выдаёт ошибку

А говорите ошибок нет.

покажите конфиг посмотрим

Завтра, уже нет доступа к устройству

https://t.me/mikrotikclub/204864
Либо netinstall. Имейте в виду, что ниже factory software понизить не выйдет (можете посмотреть его в system resourses)

Спасибо

/import <filename.rsc> verbose=yes

Коллеги, у меня вопросы про мультиван с врф-манглами.

Роутер, может устанавливать через врф туннели, в том числе и l2tp+ipsec. При этом для самого первого пакета должен быть флоу:
- routing decision
- output chain
- postrouting chain
- ipsec policy

При этом на принятие маршрутного решения мы повлиять не можем, оно обязательно выполняется по таблице main, и там почти всегда стоит маршрут-заглушка на loopback. Как следствие, в цепочке output мы уже можем опираться на то, что пакеты самого роутера, над которыми нужно как-то надругаться, имеют характерный признак out_interface=loopback0. Также на этом этапе роутер выбирает src-address, который у всех пакетов, отправляющихся в loopback0, будет одинаковый, причем выбранный по таблице main.

Следующая после routing decision - цепочка output, в которой мы будем решать проблему невозможности штатно выбрать vrf для туннеля. Нам нужно манглами (в таблице mangle) сделать следующее:
1. промаркировать соединение, если оно не было промаркировано

action=mark-connection connection-mark=no-mark new-connection-mark=conn_WAN1 out-interface=loopback0 passthrough=yes

2. промаркировать правильный routing mark пакетам в нужном соединении

action=mark-routing connection-mark=conn_WAN1 new-routing-mark=vrf_WAN1 passthrough=no

После output идет цепочка postrouting. В ней мы решаем проблему невозможности указания src-address для туннеля (в последних версиях его к L2TP можно прибить гвоздями, но если адрес динамический, то указывать там нечего, да и в случае двух провайдеров с фейловером мы не можем  быть на 100% уверены, какой точно адрес нужно прибивать).

action=masquerade chain=srcnat out-interface=int_WAN1

(я знаю, как @Prislonsky не любит маскарад, но тут у меня адрес динамический, так что тут не попляшешь)

Вопрос №1: если у меня много vrf, то не катит накрыть их одним правилом с

action=masquerade out-interface-list=WAN

- почему-то в этому случае у меня сессии через вообще все врф начинают натиться в адрес одного и того же интерфейса. По моим представлениям, маскарад должен вычислять адрес независимо для каждой сессии, но такое ощущение, что он этого не делает. Приходится накрывать маскарадом каждый интерфейс отдельно. ЧЯДНТ?

Вопрос №2: уже несколько раз заметил, что (особенно после ребута или игр с конфигом) трафик, отправляемый через wan-интерфейс при наличии правила

action=masquerade

не маскарадится и отправляется с оригинальными адресами (видно в вайршарке при отслеживании всего трафика wan-интерфейса). Помогает выключить и включить все правила маскарада. Более того, если добавить бессмысленное правило

action=masquerade chain=srcnat out-interface=loopback0

, видно что в нем растут счетчики. ЧЯДНТ?

Возвращаемся к нашим кабанам. Мы исправили ошибки роутера, совершенные на этапе routing decision: указали правильный выходной интерфейс и правильный src-address. Дальше в игру вступает ipsec. Мы не лезем в его настройки, нагло пользуясь галочкой "Use IPsec" в настройках L2TP-клиента. Поскольку обработка ipsec выполняется после postrouting, логично было бы предположить, что isakmp будет брать для sa адреса, которые дошли до него, уже после NAT. Однако я наблюдаю, что он и в полиси, и в пира запихивает адрес источника из main, что естественным путем порождает неработоспособность SA.

Вопрос №3: ЧЯДНТ, почему L2TP+IPsec после надругательства манглами и натом строит SA с кривого адреса, и как ему объяснить, что он не прав?

Не в качестве ответа, а просто рассуждения...

1. Это наверное надо просто принять. Видимо, программисты так решили - для одного правила маскарада один раз вычисляется адрес исходящего интерфейса и применяется вплоть до падения интерфейса, после чего вычисляется заново. Триггер для перевычисления адреса - падение интерфейса, а не появление пакета от нового соединения.
Программисты могли принять и Вашу логику, но она сложнее для реализации.

По 2 и 3 мне сказать нечего 😕
Но я бы всеми силами старался бы упростить исходную ситуацию, чтоб не приходилось ругаться натом на исходящий айписек 🙂

action=mark-connection connection-mark=no-mark new-connection-mark=conn_WAN1 out-interface=loopback0 passthrough=yes

action=mark-routing connection-mark=conn_WAN1 new-routing-mark=vrf_WAN1 passthrough=no

action=masquerade chain=srcnat out-interface=int_WAN1

action=masquerade out-interface-list=WAN

action=masquerade

action=masquerade chain=srcnat out-interface=loopback0

В Еве поиграюсь сегодня.