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 60ping -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 до посл. версии. -
1. Сохраните бэкап конфига 2.1
2. Обновите 2.1 до посл. версии.Да вот именно в этом и дело! Исторически c моей стороны (хост zavod) стояла версия 2.1, GRE канал с циской поднимался, маршрутизация работала; а вот IPSec в режиме транспорта - ну ни в какую… Я обновил pf до версии 2.2.6 (текущая) и вот тут возникла эта дурацкая проблема т. е. GRE+IPSec поднялись как надо, но из внутренней сети с моей стороны перестали ходить пакеты, тогда я откатился на версию 2.1, проект тормознул в тестовых целях поднял pf 2.2.6 дома, и вот она таже самая проблема....
А что на др. конце ? Пф, железный роутер ?
Если пф, то удалите всю "красоту" и настройте просто IPSec между ними.
попробовал удалить - и GRE отвалился совсем - вообще, и не поднимается никак….