Имеется два интерфейса для связи с внешним миром (wan1 и wan2). Не получается их использовать в асимметричном режиме - исходящий трафик через wan1, а соотв. ему входящий - через wan2. В журнале для wan2 при этом сообщения типа unacceptable_ack и no_new_conn_for_this_packet.

Насколько плохо я понимаю, невозможность установления TCP-соединения с каким-то внешним узлом с одновременным использованием двух внешних интерфейсов связана с особенностями реализации state-engine в NetDefendOS.

Вопрос - можно ли решить такую задачу в DFL-2500? Если да, то как?

Нельзя сделать запрос с одного IP адреса и получить ответ (в рамках той же TCP сессии) на другой, это противоречит 3му уровню.

Возможно, вы хотите обрабатывать запросы извне по WAN2, а в интернет ходить по WAN1?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Но я этого и не делаю. Наверное, я недостаточно подробно изложил свою конфигурацию. Уточняю: есть еще интерфейс lan1, к которому подключена та сеть, из которой отправляется запрос. Этот исходящий запрос маршрутизирутеся через wan1, а ответ попадает на wan2 но в lan1 не передается. Если исходящий запрос из lan1 маршрутизировать через wan2, то все в порядке - соединение устанавливается.


С этим проблем нет. Хочется немного большего - ходить в Интернет так, чтобы исходящий трафик шел по одному каналу, а входящий по другому.

Вы вашими словами опять повторили то что я написал - запрос через WAN1 (с адреса wan1_ip), а ответ вы хотите получить через WAN2 (на адрес wan2_ip). Это невозможно.

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Нет, запрос из LAN1 с адреса lan1_ip (публичный адрес, видимый извне). Никакой трансляции, чистая маршрутизация.

Замечательно. Но почему ответ (в рамках той же TCP сессии) должен вам приходить на WAN2 ?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

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

У вас что, агрегация каналов на 2 уровне? Зачем вам тогда маршрутизатор?

_________________
Хотите хороший девайс? D-Link DFL!

Хотите считать с него трафик?
http://www.raresoftware.ru/products/lan/dfltc

Нет никакой агрегации. Есть два отдельных канала, которые хочется использовать асимметрично. Про маршрутизатор я ничего не говорил - его нет. Маршрутизация извне в LAN1 осуществляется провайдером, к которому я подключен через WAN2.

Другой провайдер (WAN1) понятия не имеет о том, что в LAN1 можно направлять пакеты через wan1 (этого и не требуется). Зато он прекрасно доставляет пакеты из LAN1 в нужное место, а ответные пакеты попадают обратно через WAN2 при помощи другого провайдера.

Пакеты на самом деле ходят по одному каналу в одном направлении и по другому - в другом. Но МЭ не соображает, что входящие пакеты, поступившие по одному каналу являются ответными для исходящих, отправленных по другому каналу. В этом-то и проблема.

- спутниковый интернет ?
- попробуйте вместо Allow-правил использовать FwdFast

_________________
если человек - идиот, то это надолго

FwdFast пробовал - не помогает.

- правила созданы в двух направлениях ?
- покажите сообщение об ошибке

_________________
если человек - идиот, то это надолго

Ошибки в МЭ нет:



Но соединение не устанавливается потому, что в ответе SYN,ACK указывается странный Acknowledgment number.:




И еще, правильно ли я понимаю, что не зная заранее номера исходного порта (49471 в вышеприведенных сообщениях), я вынужден открывать все порты через FwdFast?

- да
- "странный Acknowledgment number" назначает не дфл, а веб-сервер

_________________
если человек - идиот, то это надолго

Таким образом получается, что требуемую задачу решить можно (частично - об этом ниже), но за счет потери защитных свойств МЭ и возникновения издержек, связанных с обработкой FwdFast. При этом МЭ, по сути дела, превращается в простейший маршрутизатор.

"Странный Acknowledgment number" действительно назначает сервер, а не МЭ. Но так происходит не со всяким сервером, а с достаточно удаленным (по-видимому вне пределов автономной системы провайдера исходящего канала). С близлежащими серверами, расположенными в автономных системах обоих провайдеров (имеющих отношения соседства друг с другом) соединения успешно устанавливаются. Есть подозрение, что при выходе за пределы АС sequence number исходящего пакета преднамеренно искажается маршрутизатором.