Virtual IP, машрутизация, каскад роутеров.

werter

Ок. Вам виднее по-ситуации.
Немного непонятна схема .

Как сделал бы я:

172.16.20.1/22 - на LAN pfsense
192.168.1.250/24 - на WAN pfsense со шлюзом\DNS 192.168.1.1

И зачем вам Virtual IP ?

Далее :

0. Выключаем на время все fw, антивирусы etc. (сторонние и нативные) на проверямых машинах в обеих сетях.
1. Отключаем блокирование "серых" сетей на WAN pfsense.
1.1. Включаем NAT в автомате на pfsense (на время!).
2. Включаем логирование fw на pfsense
3. Оставляем только одно правило на LAN и WAN pfsense - разрешено всё всем и по всем протоколам
3. Запускаем tracert с машины в новой сети (за pfsense) до машины в старой. Смотрим на каком этапе затык.
4. Если затык после WAN pfsense - переводим NAT в режим мануала и рисуем правило вручную с NO NAT на WAN pfsense для сети 172.16.20.0/22.
5. Если и это не поможет - разбирайтесь c вашим Зюхелем.

P.s. И да, я надеюсь у машин в новой сети шлюзом указан LAN пфсенса - 172.16.20.1/22 ?
P.p.s.

На Кинетике настроен маршрут 172.16.20.1/22 –> 192.168.1.250

Правильнее :
В сеть 172.16.20.0/22 "ходить" через 192.168.1.250.
Если же все равно не получается - на время вместо Зюхеля поставить простой свитч и проверить.

Можно еще попробовать объединить LAN и WAN pfsense в бридж.

hatifnatt

На 1 интерфейсе все висит потому как в WAN будет включен внешний канал в конце концов, и если сейчас настраивать используя его - то потом, возможно, опять придется "все ломать" в пределах пф-а. Понятно что с 2-мя сетевухами все понятнее выглядит, я даже притащил из дома сетевушку 2-ю чтоб на них разные сети настроить, но она не завелась такое было уже у меня на 8-й ветке FreeBSD, просто и быстро починить не удалось, использовал другую сетевуху в итоге, а там и 9-ка подоспела.

Попробую по предложенной вами схеме, на самом деле тоже есть сомнения в работе маршрутизации на зухеле, но в интернет он выпускает машину из 172 сети, значит как-то она работает.

PS

И да, я надеюсь у машин в новой сети шлюзом указан LAN пфсенса - 172.16.20.1/22 ?

Само собой.

PPS

Правильнее :
В сеть 172.16.20.0/22 "ходить" через 192.168.1.250.

Сказать правильнее так, согласен, но смысл был донесен главное :)

hatifnatt

В итоге проверив вариант:

0. Выключаем на время все fw, антивирусы etc. (сторонние и нативные) на проверямых машинах в обеих сетях.
1. Отключаем блокирование "серых" сетей на WAN pfsense.
1.1. Включаем NAT в автомате на pfsense (на время!).
2. Включаем логирование fw на pfsense
3. Оставляем только одно правило на LAN и WAN pfsense - разрешено всё всем и по всем протоколам
3. Запускаем tracert с машины в новой сети (за pfsense) до машины в старой. Смотрим на каком этапе затык.
4. Если затык после WAN pfsense - переводим NAT в режим мануала и рисуем правило вручную с NO NAT на WAN pfsense для сети 172.16.20.0/22.
5. Если и это не поможет - разбирайтесь c вашим Зюхелем.

Вернулся обратно к своему варианту на 1-ом интерфейсе, потому как в таблице маршрутизации никакой разницы нет (кроме имен интерфейсов), да и в результате тоже, при использовании WAN порта, все проблемы сохраняются.

Если же на машине в Old LAN (192.168.1.20) прописать шлюзом по умолчанию pfSense т.е 192.168.1.250, то есть связь между сетями и выход в интернет тоже.
Но если включить в консоли "10) Filter Logs" то видим там, что странным образом влияет на работу интернета, он вроде как работает, но не совсем.

    192.168.1.20.61474 > 173.194.71.147.443: Flags [FP.], cksum 0xdb7b (correct), seq 3371874979:3371875084, ack 4219013402, win 258, length 105
00:00:00.115961 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28695, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61482 > 54.229.20.0.80: Flags [.], cksum 0x5cee (correct), ack 313932758, win 259, length 0
00:00:00.304373 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28696, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61482 > 54.229.20.0.80: Flags [F.], cksum 0x5cee (correct), seq 2809880254, ack 313932758, win 259, length 0
00:00:00.134213 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 18941, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61421 > 74.125.143.100.443: Flags [R], cksum 0xb6e4 (correct), seq 3004498629, win 0, length 0
00:00:00.052865 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 8182, offset 0, flags [DF], proto TCP (6), length 114)
    192.168.1.20.61293 > 195.19.71.17.143: Flags [P.], cksum 0x1bad (correct), ack 3707938538, win 256, length 74
00:00:00.266186 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13812, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0xf242 (correct), ack 1744882530, win 256, length 0
00:00:00.043149 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 28697, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61482 > 54.229.20.0.80: Flags [.], cksum 0x5cee (correct), ack 313932758, win 259, length 0
00:00:00.149918 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13813, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0x55b4 (correct), ack 1744882530, win 256, options [nop,nop,sack 1 {1744882451:1744882530}], length 0
00:00:00.239989 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 13820, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.20.61488 > 173.194.71.101.443: Flags [.], cksum 0x55b4 (correct), ack 1744882530, win 256, options [nop,nop,sack 1 {1744882451:1744882530}], length 0
00:00:00.131035 rule 3/0(match): block in on em0: (tos 0x0, ttl 128, id 308, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.20.61483 > 65.55.223.38.40011: Flags [R], cksum 0x91cf (correct), seq 2785096126, win 0, length 0

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

Вторая проблема с Кинетика не проходит пинг на машины в New NET на pfSense видим

20:11:19.714612 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1024, length 1480
20:11:19.714628 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1024, length 1480
20:11:20.715674 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1280, length 1480
20:11:20.715689 IP 192.168.1.1 > 172.16.22.1: ICMP echo request, id 40457, seq 1280, length 1480

т.е. до pfSens-а пакеты доходят - а дальше нет - проверил даже вайршарком на машине 172.16.22.1 до нее пакеты не доходят.

werter

Вернулся обратно к своему варианту на 1-ом интерфейсе

Ок, попробуем след. :

1. Оставляем WAN пфсенса без кабеля и переводим его на DHCP.
2. Создаем Virtual IP на 192.168.1.250/24 типа IP Alias
3. Заходим в Routing и добавляем шлюз - Interface: LAN , Name: любое , Gateway:192.168.1.1 . Галка Default Gateway - снята.
4. Заходим в System: Static Routes . Задаем маршрут Destination network : 192.168.1.0/24, Gateway: выбираем созданный в предыдущем меню.
5. Идем в Firewall: Rules:LAN и рисуем самым верхним правило - разрешено все всем и всюду , протокол - любой.

NAT оставьте в автомате.

hatifnatt

Снял галку Default Gateway, прописал статический маршрут - потерял доступ из 192 сети!
При попытке пинга наблюдаю следующее, со стороны откуда выполняется пинг - вижу просто "Превышен интервал ожидания запроса", а вот на самом пф-е вижу и запросы и даже ответы

13:17:54.870008 IP 192.168.1.20 > 192.168.1.250: ICMP echo request, id 1, seq 140, length 40
13:17:54.870048 IP 192.168.1.250 > 192.168.1.20: ICMP echo reply, id 1, seq 140, length 40
13:17:59.633828 IP 192.168.1.20 > 192.168.1.250: ICMP echo request, id 1, seq 141, length 40
13:17:59.633844 IP 192.168.1.250 > 192.168.1.20: ICMP echo reply, id 1, seq 141, length 40

```только вот до клиента они не доходят.

werter

Хм..А в логах fw что?

P.s. И последнее - объединить в бридж LAN и WAN (подключив WAN и получив от момеда адрес\прописав вручную)

hatifnatt

Как лучше логи посмотреть? Через консоль "10) Filter Logs" или есть лучше методы?
Бридж попробую.

werter

Т.е. во всех этих "плясках" вы до сих пор логи fw и не смотрели?! Жесть… :(

hatifnatt

Кто сказал что я не смотрел? Я смотрел так как описал выше, через консоль.

werter

О какой консоли речь?
Я о вкладке Diagnostics:System logs:Firewall. Вы в ней смотрели? Там очень наглядно видно что, как и почему блокируется.