GRE+IPSec 2.2.6-RELEASE (amd64)



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



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

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



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



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









    ![Ping Default to remote.JPG](/public/imported_attachments/1/Ping Default to remote.JPG)
    ![Ping Default to remote.JPG_thumb](/public/imported_attachments/1/Ping Default to remote.JPG_thumb)
    ![Ping LAN to remote.JPG](/public/imported_attachments/1/Ping LAN to remote.JPG)
    ![Ping LAN to remote.JPG_thumb](/public/imported_attachments/1/Ping LAN to remote.JPG_thumb)



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



  • 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)) всё работает штатно….



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



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



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




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



  • 2 Alexey_B

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



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

    ![GRE gateway.JPG](/public/imported_attachments/1/GRE gateway.JPG)
    ![GRE gateway.JPG_thumb](/public/imported_attachments/1/GRE gateway.JPG_thumb)
    ![route lan - to zavod.JPG](/public/imported_attachments/1/route lan - to zavod.JPG)
    ![route lan - to zavod.JPG_thumb](/public/imported_attachments/1/route lan - to zavod.JPG_thumb)



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



  • трассировка из 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
    в остальных случаях пакеты не проходят…

    ![traceroute 1.JPG](/public/imported_attachments/1/traceroute 1.JPG)
    ![traceroute 1.JPG_thumb](/public/imported_attachments/1/traceroute 1.JPG_thumb)
    ![traceroute 2.JPG](/public/imported_attachments/1/traceroute 2.JPG)
    ![traceroute 2.JPG_thumb](/public/imported_attachments/1/traceroute 2.JPG_thumb)
    ![traceroute 3.JPG](/public/imported_attachments/1/traceroute 3.JPG)
    ![traceroute 3.JPG_thumb](/public/imported_attachments/1/traceroute 3.JPG_thumb)



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



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

    ![auto Outbound NAT rules 2.1.JPG_thumb](/public/imported_attachments/1/auto Outbound NAT rules 2.1.JPG_thumb)
    ![auto Outbound NAT rules 2.1.JPG](/public/imported_attachments/1/auto Outbound NAT rules 2.1.JPG)
    ![auto Outbound NAT rules 2.2.6.JPG](/public/imported_attachments/1/auto Outbound NAT rules 2.2.6.JPG)
    ![auto Outbound NAT rules 2.2.6.JPG_thumb](/public/imported_attachments/1/auto Outbound NAT rules 2.2.6.JPG_thumb)



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

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



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



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



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



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



  • Маршруты со стороны 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



  • Могу ошибиться, но я вижу со стороны  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-адреса их пфсенсов.