Заменяю DFL-260E на DFL-860E, конфиг переношу вручную, может, где и ошибся.
Кроме основного адреса IP1 в WAN, который, собственно, назначен WAN интерфейсу DFL, используются еще два
- IP2, на котором DFL создает дополнительный PPTP сервер
- IP3, на котором нужно опубликовать один из серверов локалки.
На 260E все работало, на 860E дополнительные адреса не отзываются ((
Снятый DFL-260 включить уже проблематично.

Искать за меня ошибку не прошу, прошу ответить на вопросы:
1) Известно ли о каком-то различии в этом отношении между DFL-260E и DFL-860E, прошивка на обоих 2.40.04 международная
2) Есть ли руководства, шпаргалки, howtos и т.п. по использованию дополнительных адресов на интерфейсе (кроме, конечно, основного мануала)
3) Получу ли я существенный плюс от перехода на 2.60.02?
4) Есть ли средство для просмотра сохраненной конфигурации DFL в читаемом виде?

Спасибо.

PS. С ошибкой вроде разобрался. Но на вопросы 2-4 все хотелось бы получить ответ.

Тип подключения к провайдеру какой?

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Вот тут я писал про вынос SIP'а на отдельный внешний IP.
Там есть тонкость - нужно не только приколотить входящий пакет на определенный внешний адрес, но и искодящему пакету сказать, что от вылетает с определеенного внешнего адреса, который не равен внешнему адресу на wan-порту DFL'ки.

Это все там описано: viewtopic.php?p=873935#p873935

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Витая пара, статический адрес (то есть, диапазон адресов), никаких заморочек с PPPoE и т.п. и вообще устройство подключилось, только с дополнительными адресами были проблемы, а теперь непонятки, но с ними я разбираюсь.

Да, адресов в wan, которые я могу использовать, у меня достаточно много, на них никто не покушается, с этим проблемы нет.

Тогда в дополнение к тому мануалу - нужно ARP'ами прикрутить внешние адреса на определенный интерфейс, на котором у Вас используются сервисы.

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Собственно, с этим я сейчас и разбираюсь.

Главное, что на 260 ВСЕ РАБОТАЛО! На том же месте, с теми же адресами. Естественно, и ARP был настроен.

Иногда мне кажется, что некоторые вещи начинают работать не сразу, как я их настраиваю, а некоторое время спустя и без видимых причин.
Думается, что это чудит именно ARP с его кешами...

Спасибо, мануал изучаю.

Насчет тонкости не вполне понял. Это - для случаев, когда сессия инициируется внутренним сервером, так? Потому что вроде для сессий, инициированных извне, работает правило, описывающее трансляцию входящих пакетов. Или я неправ?

Так, допустим мы имеем хост A в интернете и хост B в локалке, странслированный на IP2 на DFL.

1. А начинает сессию с B, отправляя пакеты на IP2, DFL транслирует пакеты этой сессии как входящие, так и исходящие, правильно?

2. B начинает сессию с A, если правила исходящей трансляции нет, но есть обычный NAT, на A приходят пакеты с IP1, ну и пусть. Все работает,
но A "не понимает", что работает с тем же B. В SIP это существенно, но чаще - нет. Я прав?

Имеем IP1 и IP2.
IP1 прикручен на wan, а на IP2 вешаем, например, SIP-шлюз.

Если использовать только стандартную пару SAT+Allow, то пакет прилетит от A на IP2, а обратно полетит по стандартному правилу lan-to-wan, при этом от внешнего адреса IP1.
SIP-оборудование оператора будет в непонятке, почему оно посылает пакеты на IP2, а ответка прилетает от IP1 !
Понятно?

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Для SIP-оборудования это критично, поэтому используется SAT+Allow+NAT

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

Вовсе не понятно.

Во-первых, насколько я понимаю логику DFL, которая ни разу ни Микротик и не Линукс вообще, ответные пакеты на установленные сессии правилами вообще не обрабатываются.
Во-вторых, у меня не SIP.
В-третьих, у меня там был https сервер, который прекрасно работал без "обратного" правила. Скажете, броузеру пофиг, откуда пришел ответный пакет? Гм... Сейчас это немножко разобрано, но я планирую восстановить все и тогда смогу однозначно, по tcpdump проверить, с какого IP идут ответные пакеты.

Для SIP оборудования критично, что обмен инициируется с обеих сторон. Более того, SIP оборудование регистрируется, поэтому стабильность его IP при всех условиях важна.
Это мы проходили, есть у меня SIP.

Но в данном случае речь не о SIP.

Да, все логично. Про Loopback я не додумался, надо будет применить при случае. В остальном все понятно и естественно.
Мои проблемы и непонятки, вероятно, связаны с ARP. Коварный протокол ))

Спасибо.

Про Loopback там немного неправильно написано.
Например, для www надо писать:
SAT lan/lannet core/wan_ip http_all (SAT: local_ip_www)
Allow lan/lannet core/wan_ip http_all

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...

По-моему, в этом случае ответка от сервера пойдет напрямую, а не через DFL, если он в той же lan. Соответственно, вот тут обратные адреса будут приходить сильно другие.

Ну или если для www присвоен www_public_ip:
SAT lan/lannet core/www_public_ip http_all (SAT: local_ip_www)
Allow lan/lannet corewww_public_ip http_all

_________________
С уважением, Matrox.
DFL, HPE, QNAP, Netgear и прочее железо...