Wan, opt1, opt2 - multirouting
-
может приведет к каким то идеям: попробовал симитировать эту ситуацию, подергав клиента и попереключав его между wan и opt1, опять вход по одному каналу, выход по другому, пошел спать, ночью проснувшись проверил - нормализировалось. и вход и выход по opt1 (клиентя на нем оставлял)
-
может приведет к каким то идеям: попробовал симитировать эту ситуацию, подергав клиента и попереключав его между wan и opt1, опять вход по одному каналу, выход по другому, пошел спать, ночью проснувшись проверил - нормализировалось. и вход и выход по opt1 (клиентя на нем оставлял)
Для большей ясности, все данные, которые ты привёл (по моей просьбе) - это когда нормально работало, или когда вход по одному, выход по другому?
-
когда вход по одному, выход по другому
-
Я так понимю 91… это твой клиент удалённый.
У тебя loadbalancer случаем не сконфигурирован нигде?
Данный IPsec терминируется на pfSense или за pf какая коробка стоит? -
loadbalancer нету
IPsec напрямкю между пфсенсом и длинком, за ними уже локалки. -
Чудеса какие-то. У тебя обратный трафик идёт через WAN, но при этом использует source IP с OPT1.
Я не могу этого объяснить, извиняй.
Как физически организованы подключения к провайдерам на WAN и на OPT1, есть что-нибудь общее (типа свича)? -
есть что-нибудь общее (типа свича)
-нету -
Version 1.2.3-release?
-
1.2.2
built on Thu Jan 8 22:39:31 EST 2009пробовал и
Version 1.2.3-release
-пробовал, тоже самое…правда еще часть клиентов отпадает, планируется смена прова - заодно под это дело и версию обновлю... -
Проблему наверняка можно решить, добавив статический маршрут на OPT1
91.x10.2хх.1хх/32 -> 83.x0.209.249
но вообще какая-то загадка природы. -
а что означает:
Disable reply-to on WAN rules
With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.
?