GRE+IPSec 2.2.6-RELEASE (amd64)

[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 отвалился совсем - вообще, и не поднимается никак….

[werter]

Доброе.
Таблицу марш-ции при поднятом туннеле покажите.

[Alexey_B]

Маршруты со стороны pf 2.2.6 (HOME):

default                 93.100.146.1 UGS  5153242 1500 fxp0
5.19.253.206         93.100.146.1 UGHS 196477 1500 fxp0
84.52.98.136         93.100.146.1 UGHS 319836 1500 fxp0
93.100.1.3         93.100.146.1 UGHS 43268 1500 fxp0
93.100.146.0/23 link#3         U         166058 1500 fxp0
93.100.146.114 link#3         UHS         0         16384 lo0
94.19.255.3         93.100.146.1 UGHS 43268 1500 fxp0
127.0.0.1         link#6         UH         45         16384 lo0
192.168.2.0/24 link#2         U         9591128 1500 re1
192.168.2.1         link#2         UHS         0         16384 lo0
192.168.5.0/24 192.168.31.2 UGS         351         1400 gre0
192.168.31.1         link#8         UHS         3         16384 lo0
192.168.31.2         link#8         UH         322528 1400 gre0

Маршруты со стороны pf 2.1 (ZAVOD):

default                 84.52.98.129 UGS         2 125865704 1500 xl0
5.19.253.206         84.52.98.129 UGHS 0 69142787 1500 xl0
84.52.98.128/26 link#4         U         0 261686         1500 xl0
84.52.98.136         link#4         UHS         0 0                 16384 lo0
84.52.107.107 84.52.98.129 UGHS 0 119051         1500 xl0
93.100.146.114 84.52.98.129 UGHS 0 319935         1500 xl0
127.0.0.1         link#8         UH         0 54                 16384 lo0
192.168.1.0/24 192.168.30.1 UGS         0 24                 1400 gre0
192.168.2.0/24 192.168.31.1 UGS         0 4                 1400 gre1
192.168.5.0/24 link#2         U         0 208221065 1500 em1
192.168.5.1         link#2         UHS         0 0                 16384 lo0
192.168.20.0/24 link#1         U         0 132174         1500 em0
192.168.20.1         link#1         UHS         0 0                 16384 lo0
192.168.30.1         link#10         UH         0 18042         1400 gre0
192.168.30.2         link#10         UHS         0 0                 16384 lo0
192.168.31.1         link#11         UH         0 524357         1400 gre1
192.168.31.2         link#11         UHS         0 0                 16384 lo0
195.177.123.1 84.52.98.129 UGHS 0 118752         1500 xl0
217.66.153.70 84.52.98.129 UGHS 0 15469         1500 xl0

[werter]

Могу ошибиться, но я вижу со стороны  pf 2.2.6 (HOME) только gre (192.168.5.0/24    192.168.31.2    UGS            351            1400    gre0),
ipsec не вижу.

Cо стороны pf 2.1 (ZAVOD) вижу два gre :

192.168.1.0/24    192.168.30.1    UGS            0    24                    1400    gre0   
192.168.2.0/24    192.168.31.1    UGS            0    4                    1400    gre1

P.s. И не пингуйте концы туннелей или адреса пф за ними. Пингуйте адреса лок. машин за туннелями.
Только у всех машин за пфсенсами шлюзами\gw в настр. сетевых  должны быть  ip-адреса их пфсенсов.