Доброго дня всем.

Схема кривенькая, но всё-таки.
Внутри большого предприятия есть обособленное подразделение. Это подразделение имеет территориально удаленные друг от друга представительства. Они не взаимодействуют с ISP непосредственно. Проблема обозначилась для указанных двух представительств (К1 и К2 на схеме).
В К1 и К2 стоит по DFL-800. Между ними поднят GRE тоннель ибо шифровать трафик смысла нет, сидим внутри сети предприятия. "Чужие" адреса из каждого подразделения, естественно, пингуются. Все сервисы доступны.
Всё работало, пока один из сервисов не уехал на сервер 192.168.202.3 в К2. До переезда он работал на 192.168.201.1 и всё было хорошо.
Дело в том, что на wan1 К1 предприятие транслирует запросы из интернета по 210 порту.
Пишу правила (К1):
SAT_DEST_210, правило SAT, задаю Destination: 192.168.202.3,
SAT_SRC_210, правило SAT, задаю Source: 192.168.201.5, чтобы трафик обратно тоже шёл через тоннель.
ALLOW, правило Allow.
Соединение не появляется.
При этом в логах DFL-800 в К1 регистрируется попытка соединения по 210 порту.
conn_open для Allow_правила. Src/DstIf wan1/k1_k2_gre, Src/DstIp 8.8.8.8/10.3.20.1, Src/DstPort 59316/210
Но! В логах DFL-800 в К2 регистрируется вот что:
ruleset_drop_packet/drop для Default_Access_Rule. Src/DstIf одной строкой k2_k1_gre, Src/DskIp 25.118.154.208/192.168.202.3 Src/DstPort 59316/210
Из равенства портов в логах обеих длинков я делаю вывод, что это одно и то же подключение. Но откуда получается такой ip на втором длинке? Конечно, он не подпадает под действие правил для тоннеля.
PS Замечено, что для один и тот же ip транслируется в один и тот же, но какой-то совсем не тот.
PS 2 Также замечено, что иногда (именно иногда, 1 раз из 100, а то и меньше) на длинке в K1 регистрируется предупреждение (видимо, на обратном пути пакета) Src/DstIf wan1/k1_k2_gre Src/DstIP 25.118.154.208/192.168.202.3 Src/DstPort 59316/210 Event/Action mismatching_tcp_window_scale/adjust

Прошу прощения за возможно путанное объяснение.

Что я делаю не так?

Смысл я примерно понял, но, возможно, не до конца. Объяснение, действительно, несколько путанное. И не полное.

Победить это, наверняка можно. Только, может быть, проще пробросить порт 210 на новый адрес расположения сервиса?

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Аха но в этом случае использовать nat тогда все полусится на ура . Если использовать аллов то придктся переподнимать туннель с параметром алл нетс.

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Спрашивайте, дополню.

Уверен, что победить это можно на моей стороне. На стороне ОИТ предприятия решить это проще, особенно для меня, но долго. Взаимодействия никакого, все вопросы решаются практически на уровне генерального. Процесс может затянуться. За это время сервис, возможно, вернется в K1. Понятное же дело, что рабочую схему я не стал бы рушить своими руками от нечего делать - сдох сервер, ждём нового (это может быть ооочень долго, а может - две недели). В К1 поднимать задачу со сдохшего сервера было негде, она временно съехала в К2.

Владимир, а чем плох Allow? Ведь задача, по сути, тривиальна.
Когда-то давным-давно, помню, решал задачу доступности веб-сервера изнутри сети по внешнему ip. Тогда решал iptables'ами, но не суть. Даже не заглядывая в свои длинки, могу смело заявить, что добавив правило SAT source=lan_ip для рабочей пары правил SAT destination/Allow для внешней сети, я бы решил проблему.
Сейчас у меня проблема суть та же. Разве нет?
Смотрите /условно/:
приходит пакет на wan1, source=8.8.8.8, dest=10.3.20.1
а. dlink1 меняет source=192.168.201.5 /lan_ip/, dest=192.168.202.3 и, в соответствии с таблицей маршрутизации, отправляет его в k1_k2_gre
b. dlink2 в соответствиями с правилами gre просто перенаправляет пакет на 192.168.202.3
c. 192.168.202.3 обрабатывает пакет и отправляет ответ на dest, т.е. 192.168.201.5 через шлюз (т.е. dlink2)
d. dlink2 принимает пакет, адресованный 192.168.201.5 (вот тут и нужна замена dest на шаге а.) и отправляет его тем же путем, которым пришёл запрос, т.е. через k2_k1_gre
e. dlink1 принимает пакет, выбирает из своей таблицы подключений изначальные адреса, подменяет dest на начальный 8.8.8.8 и отправляет его на свой gw.
Всё стройно и как будто должно работать. Проблема в том, что на самом первом шаге dlink1 меняет source не на lan_ip, а на значение "от балды".
Что я упускаю из вида?

Показывайте скрином закладку сат .
В вашем рассуждении вы все верно думаете . Но не логично по отношению к dfl. Хотите быстро сдклайте nat и на закладке сат поменяйте адресс назначения на новый . Хотите красиво . Делайте как говорил раньше .

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку

Вот с таким набором правил

всё работает.
NAT'ом задаю sender address=lan_ip
SAT'ом задаю destination ip=server_ip|192.168.202.3
В логах K1 видно conn_open_natsat по правилу NAT_210
satdestrule=SAT_DEST_210 conn=open connewscrip=192.168.201.5 connewsrcport=52661 connewdestip=192.168.202.3
Src/DstIf wan1/k1_k2_gre
В подключениях появляется
TCP_OPEN wan1:8.8.8.8:51523 k1_k2_gre:10.3.20.1:210
K2 не требует дополнительных настроек, в логах ничего не регистрируется (логгирование для правил прохождения пакетов внутри тоннеля gre выключено).
В подключениях видно
TCP_OPEN k2_k1_gre:192.168.201.5:52661 lan:192.168.202.3:210
Всё работает.
Большое спасибо, Vladimir22.
Но всё равно вопрос для меня остаётся открытым: почему так неправильно отрабатывает правило Allow?

Вы можете пояснить в чём нелогичность dfl? Люблю докапываться до сути

Я не понял которую?

1. Через SAT/NAT и так понятно почему работает

2. Через SAT/Allow не работает, т.к. на внешний пакет, приходящий через GRE, DFL пытается отвечать через WAN1 интерфейс и соединение не устанавливается. Т.е. DFL не отвечает автоматически через тот же интерфейс, с которого приходит запрос. Чтобы этого достичь, требуется дополнительная настройка.

Т.е. надо настроить PBR. Это, при наличии опыта, не так сложно, но гораздо сложнее, чем 1-й вариант.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Не вполне. Почему натовским правилом sender address устанавливается правильно, а сатовским source ip устанавливается не на указанный, а на вообще непонятно откуда взятый? В обоих случаях пробую присвоить lan_ip.

C SAT/NAT происходит как трансляция адреса назначения, так и адреса источника. соединение устанавливает DFL1 c DFL2 от своего имени, т.е. своего локального адреса. Поэтому всё штатно работает через GRE туннель.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Это внешний адрес, с которого идет обращение на ваш сервис по 210 порту.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Не-не-не. Это - не мой внешний адрес.
Я как раз пробовал пару sat-правил навесить на allow-правило. Одно для замены source, другое для замены destination. И очень удивился, что source меняется, но не на то, что указано в правиле.

источник меняется правилом NAT. Использовать для этого SAT, если даже это возможно, нет нужды.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Пакету надо знать не только как достич цели но и как вернутся обратно . И в вашем случае это как раз видно .

_________________
Своим вопросом Вы загоняете меня в ГУГЛ.....
DFL-210 -архив образов
Меня можно найти в боте Телеграмма @MyKingdombot когда РКН перестанет заниматься ерундой :-)
Готовыe платить - пишите
Прикуплю неисправные девайсы ради корпусов ....-> в личку