GRE+IPSec 2.2.6-RELEASE (amd64)

[Alexey_B]

Здравствуйте уважаемые форумчане! После обновления с версии 2.1-RELEASE (amd64) до 2.2.6-RELEASE (amd64)
столкнулся со следующей неприятностью - есть туннель GRE+IPSec, туннель поднимается, но не проходят
пакеты из сети LAN в сеть GRE и далее,  шлюз и маршрут для GRE указаны, маршрутизация работает, при пинге
от интерфейса GRE или default, а из LAN - ни в какую; правила файрвола на интерфейсах GRE и IPSec -
разрешено всё, для LAN - из LAN разрешено всё и везде. По форуму искал, ничего похожего не увидел, если кто сталкивался с подобной проблемой прошу откликнуться, буду благодарен за любые советы.

[werter]

Доброе. Покажите скрины fw на интерфейсах.

P.s. Добавьте на LAN явное разрешающее правило для прохождения трафика из ЛАН в др. сеть, к-ая через туннель GRE+IPSec доступна.
И поставьте его первым.

[Alexey_B]

Спасибо за ответ! Явные правила на LAN создал - эффекта нет…. Скрины выложу позже.

[Alexey_B]

Скрины правил и пинга в удалённую сеть через GRE-IPSec


[PbIXTOP]

А какие различия показывает tcpdump при прохождении и не прохождении ping?

[Alexey_B]

ping -s 1000 192.168.5.30

пакеты по 1000 байт - проходят,
вывод tcpdump:

10:02:04.704322 IP 192.168.31.2 > 192.168.31.1: ICMP echo request, id 39511, seq 47992, length 60
10:02:04.704334 IP 192.168.31.1 > 192.168.31.2: ICMP echo reply, id 39511, seq 47992, length 60
10:02:05.146767 IP 192.168.31.1 > 192.168.5.30: ICMP echo request, id 3425, seq 4, length 1008
10:02:05.149253 IP 192.168.5.30 > 192.168.31.1: ICMP echo reply, id 3425, seq 4, length 1008
10:02:05.644767 IP 192.168.31.1 > 192.168.31.2: ICMP echo request, id 24403, seq 46258, length 60
10:02:05.646220 IP 192.168.31.2 > 192.168.31.1: ICMP echo reply, id 24403, seq 46258, length 60
10:02:05.712898 IP 192.168.31.2 > 192.168.31.1: ICMP echo request, id 39511, seq 48248, length 60
10:02:05.712908 IP 192.168.31.1 > 192.168.31.2: ICMP echo reply, id 39511, seq 48248, length 60

ping -s 1000 -S 192.168.2.1 192.168.5.30

пакеты по 1000 байт с адреса LAN - не проходят

вывод tcpdump

10:06:08.134085 IP 192.168.31.1 > 192.168.31.2: ICMP echo reply, id 39511, seq 44153, length 60
10:06:08.379739 IP 192.168.31.1 > 192.168.31.2: ICMP echo request, id 24403, seq 42675, length 60
10:06:08.381237 IP 192.168.31.2 > 192.168.31.1: ICMP echo reply, id 24403, seq 42675, length 60
10:06:08.865755 IP 192.168.31.1 > 192.168.5.30: ICMP echo request, id 61218, seq 6, length 1008
10:06:08.874290 IP 192.168.5.30 > 192.168.31.1: ICMP echo reply, id 61218, seq 6, length 1008
10:06:09.145403 IP 192.168.31.2 > 192.168.31.1: ICMP echo request, id 39511, seq 44409, length 60
10:06:09.145414 IP 192.168.31.1 > 192.168.31.2: ICMP echo reply, id 39511, seq 44409, length 60
10:06:09.466442 IP 192.168.31.1 > 192.168.31.2: ICMP echo request, id 24403, seq 42931, length 60
10:06:09.467887 IP 192.168.31.2 > 192.168.31.1: ICMP echo reply, id 24403, seq 42931, length 60
10:06:09.910021 IP 192.168.31.1 > 192.168.5.30: ICMP echo request, id 61218, seq 7, length 1008
10:06:09.912828 IP 192.168.5.30 > 192.168.31.1: ICMP echo reply, id 61218, seq 7, length 1008

пакеты длиной 60 байт - мониторинг шлюза,

т. е. пакеты из интерфейса GRE на интерфейс LAN, при этом на удалённой стороне - (версия 2.1-RELEASE (amd64)) всё работает штатно….

[Alexey_B]

т. е. пакеты из интерфейса GRE на интерфейс LAN не возвращаются (передаются), при этом на удалённой стороне - (версия 2.1-RELEASE (amd64)) всё работает штатно….

[werter]

Доброе.
А из сети за pf пакеты проходят в удален. сеть ?

[Alexey_B]

Нарисовал схему, чтобы совсем было понятно.

[PbIXTOP]

По tcpdump
конечно много мусора, но там вроде видно что во втором варианте пинг на 192.168.5.30 проходит. Если вы не трогали настройки nat, адрес должен был транслироваться по умолчанию.
Для проверок я обычно использую машины внутри сети и снимаю дамп со всех возможных интерфейсов, чтобы точнее определять nat, маршруты или всеже правила настроены неправильно.

[werter]

2 Alexey_B

А из сети за pf пакеты проходят в удален. сеть ?
Проверьте из лок. сети за pfsense. И шлюзом у машин должен быть pfsense.

[Alexey_B]

В том и дело, что из LAN через GRE пакеты не проходят, выглядит это как будто интерфейс GRE не принадлежит маршрутизатору, при этом в версии 2,1 - всё работает как надо (см. схему); на машинах в LAN pf - в качестве дефолтного маршрутизатора, на скринах настройки шлюза и маршрута через туннель в удалённую сеть


[werter]

Доброе.
А на каком этапе затыкается команда tracert с обоих концов ?

[Alexey_B]

трассировка из LAN (192.168.2.10) в удалённую сеть:
C:\Documents and Settings\Alexey>tracert 192.168.5.30

Трассировка маршрута к 192.168.5.30 с максимальным числом прыжков 30

1    <1 мс    <1 мс    <1 мс  pfsense.home.lan [192.168.2.1]
  2    *        *        *    Превышен интервал ожидания для запроса.
  3    *        *        *    Превышен интервал ожидания для запроса.
  4    *        *        *    Превышен интервал ожидания для запроса.
  5    *        *    ^C
C:\Documents and Settings\Alexey>

трассировка из удалённой сети (192.168.5.30) в LAN:
C:>tracert 192.168.2.10

Трассировка маршрута к 192.168.2.10 с максимальным числом прыжков 30

1    <1 мс    <1 мс    <1 мс  192.168.5.1
  2    *        *        *    Превышен интервал ожидания для запроса.
  3    *        *        *    Превышен интервал ожидания для запроса.
  4    *        *        *    Превышен интервал ожидания для запроса.
  5    *        *        *    Превышен интервал ожидания для запроса.
  6    *        *        *    Превышен интервал ожидания для запроса.
  7    *        *    ^C
C:>

во вложениях скрины traceroute с маршрутизаторов, на первой картинке трассировка идёт с интерфейса - any
в остальных случаях пакеты не проходят…


[werter]

А логах fw ничего ?  Принудительный\ручной роутинг точно нужен? Там же в настройках ipsec указывается какие сети маршрутизировать.

[Alexey_B]

Влогах файрволла - чисто, смотри скриншот. Да, маршрутизация нужна, поэтому и муть вся с GRE-IPSec (т.е. - transport mode). Пришла вдруг мысль - не может эта ситуация быть связана с автоматически сгенерированными правилами Firewall: NAT: Outbound? Я сейчас заглянул туда и ужаснулся - даже ума не приложу что надо поправить, при этом на маршрутизаторе версии 2.1 ничего подобного нету - смотрите скриншоты, если подскажите что можно сделать - чтобы всё заработало - буду крайне признателен.


[werter]

А что на др. конце ? Пф, железный роутер ?

Если пф, то удалите всю "красоту" и настройте просто IPSec между ними.

[Alexey_B]

Сейчас pf v. 2.2.6 <-> pf v. 2.1 - это тестовая среда, как только заработает нужно будет обеспечить транспорт GRE+IPSec к циске, там к сожалению других вариантов нет…. Пробовал  GRE+IPSec с версии 2.1 к циске - к сожалению IPSec не поднимается, с версии 2,2,6 с IPSec всё нормально - но вот такая ситуация с GRE.

[werter]

1. Сохраните бэкап конфига 2.1
2. Обновите 2.1 до посл. версии.

[Alexey_B]

@werter:

1. Сохраните бэкап конфига 2.1
2. Обновите 2.1 до посл. версии.

Да вот именно в этом и дело! Исторически c моей стороны (хост zavod) стояла версия 2.1, GRE канал с циской поднимался, маршрутизация работала; а вот IPSec в режиме транспорта - ну ни в какую… Я обновил pf до версии 2.2.6 (текущая) и вот тут возникла эта дурацкая проблема т. е. GRE+IPSec поднялись как надо, но из внутренней сети с моей стороны перестали ходить пакеты, тогда я откатился на версию 2.1, проект тормознул в тестовых целях поднял pf 2.2.6 дома, и вот она таже самая проблема....

@werter:

А что на др. конце ? Пф, железный роутер ?

Если пф, то удалите всю "красоту" и настройте просто IPSec между ними.

попробовал удалить - и GRE отвалился совсем - вообще, и не поднимается никак….