Настройка IPsec GRE туннель между FortiOS 6.4.5 и RouterOS 6.48.1

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Стояла задача объединить филиалы с головным офисом предприятия, где находилась серверная. Fortigate 60E организовывал доступ в интернет и выполнял роль межсетевого экрана в головном офисе, в филиалах выполняли роль доступа в интернет Микротик разных моделей. Также было необходимо настроить динамическую маршрутизацию OSPF и поднять  IPsec VPN туннели с GRE. Порыскав на просторах интернета, нашел пару разрозненных статей о соединении Fortigate c микротик через IPsec VPN и GRE туннель. Решил объединить эту информацию в одной своей статье, чтобы в дальнейшем самому использовать как шпаргалку. О динамической маршрутизации OSPF напишу в следующей статье.

Итак, входные данные:

1.  Головной офис предприятия HQ FortiOS 6.4.5:

  • Публичный IP X.X.X.X (сетевой интерфейс port1)

  • Внутренняя сеть 192.168.111.0/24 (сетевой интерфейс port2)

  2. Филиал предприятия Branch Mikrotik RouterOS 6.48.1:

  • Публичный IP Y.Y.Y.Y сетевой интерфейс ether1

  • Внутренняя сеть 192.168.112.0/24 (сетевой интерфейс ether2)

На рис. схематично показано подключение главного офиса и филиала.

Опущу основный настройки Fortigate  и mikrotik, эта информация есть в интернете, сразу приступим к настройкам IPsec и GRE. Начнем настройку с mikrotik . Начнем с GRE, заходим утилитой  Winbox  на mikrotik в меню Interfaces->GRE Tunnel->+(нажимаем плюс, чтобы добавить туннель), за тем : - Local Address Y.Y.Y.Y - Remote Address X.X.X.X Укажем параметр "keepalive", который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Использовать будем значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. В отличии от настройки GRE без IPsec в этой конфигурации должна быть отключена опция "Allow Fast Path", а параметр "Local Address:" является обязательным потому что без него не получится создать автоматические настройки IPsec. Если указать параметр “IPsec Secret”, то автоматически создадутся необходимые настройки IPsec. Но их поменять будет уже не возможно, поэтому не задаю параметр “IPsec Secret”.

Назначим IP адрес GRE-туннелю. Зайдем IP->Addresses->+

Команды консоли :

/interface gre
add name=gre-tunnel1 keepalive=10s,10 local-address=Y.Y.Y.Y remote-address=X.X.X.X allow-fast-path=no
/ip address
add address=10.10.10.2/30 interface= gre-tunnel1

Настраиваем IPsec . Начнем с phase-1, идентификация устройств между собой, по заранее определенному IP адресу и ключу , настройки в IP->IPsec->Profiles.

Создаем Peer для phase-1, в IP->IPsec->Peers. Указываем имя name Branch-HQ,  адрес удаленного FortiGate HQ, локальный адрес и profile1, который соответствует phase-1.

Теперь определяем ключ IPsec phase-1.

Настройка параметров phase-2, он согласует общую политику IPsec, получает общие секретные ключи для алгоритмов протоколов IPsec (AH или ESP), устанавливает IPsec SA. Идем IP->IPsec->Proposals

И создаем политики IPsec , IP->IPsec->Policies->General. Указываем имя Peer Branch-HQ, мы его настраивали выше. Src. Address – внешний адрес нашего mikrotik Y.Y.Y.Y, Dst. Address – внешний адрес FortiGate HQ X.X.X.X, и указываем протокол GRE в параметре Protocol - 47.

На вкладке Action выбираем Proposal – porposal1, который мы тоже настраивали выше.

Настройка в консоли :

 /ip ipsec profile
add dh-group=modp1536,modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=24h name=profile1
/ip ipsec peer
add address=X.X.X.X local-address=Y.Y.Y.Y name=Branch-HQ profile=profile1
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms= aes-256-cbc lifetime=30m name=proposal1 
pfs-group=modp1536
/ip ipsec policy
add peer=Branch-HQ src-address= Y.Y.Y.Y dst-address= X.X.X.X protocol=47 proposal=proposal1
/ip ipsec identity
add peer=Branch-HQ secret=#!@BRaNCH@!#

Прописываем правила в файерволе  IP->Firewall->Filter Rules:

В терминале :

/ip firewall filter
add chain=input protocol=17 dst-port=500,4500 in-interface=ether1 action=accept

Пока не поднята динамическая маршрутизация , создадим статический маршрут до локальной сети головного офиса :

/ip route
add dst-address=192.168.111.0/24 gateway=10.10.10.1

На этом настройка mikrotik окончена , перейдем к настройки FortiGate.

На FortiGate настроим IPsec phase-1 в командной строке:

config vpn ipsec phase1-interface
     edit HQA-Branch
         set peertype any
         set proposal aes256-sha256
         set dpd on-idle
         set dhgrp 5 14
         set auto-discovery-sender enable
         set remote-gw Y.Y.Y.Y
         set psksecret #!@BRaNCH@!#
         set dpd-retryinterval 5
     next
 end

  Phase-2 , не забываем указать “protocol 47” и указать transport-mode (транспортный режим) для  туннеля GRE:

config vpn ipsec phase2-interface
    edit "HQA-Branch"
       set phase1name "HQA-Branch"
       set proposal aes256-sha256
       set dhgrp 5 14
       set auto-negotiate enable
       set encapsulation transport-mode
       set protocol 47
    next
end

Настроим GRE tunnel:

config system gre-tunnel
    edit "HQ-Branch"
        set interface "HQA-Branch"
        set remote-gw Y.Y.Y.Y
        set local-gw X.X.X.X
    next
end

Настроим локальный IP адрес туннельного интерфейса и укажем IP удаленного интерфейса: 

config system interface
     edit "HQ-Branch"
        set ip 10.10.10.1 255.255.255.255
        set remote-ip 10.10.10.2 255.255.255.252
        set interface "HQA-Branch"
    next
end

Трафик  GRE, который должен быть защищен IPsec, создается самостоятельно, он не принимается на интерфейсе. Следовательно, не требуется политика форвардинга, чтобы разрешить трафику GRE входить или выходить из интерфейса IPsec. Однако по замыслу FortiOS для согласования IPsec требуется политика форвардинга.  Поэтому для «активации» IPsec используется произвольная политика форвардинга (например, от самого интерфейса IPsec и обратно).

config firewall policy
     edit 2
         set name "Enable IPsec"
         set srcintf "HQA-Branch"
         set dstintf "HQA-Branch"
         set srcaddr "all"
         set dstaddr "all"
         set action accept
         set schedule "always"
         set service "ALL"
      next

  Разрешим трафик из локальной сети головного офиса port2 в туннель GRE и наоборот:

config firewall policy
     edit 3
        set name "GRE HQ->Branch"
        set srcintf "port2"
        set dstintf "HQ-Branch"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 4
        set name "GRE Branch->HQ"
        set srcintf "HQ-Branch"
        set dstintf "port2"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

После туннелирования GRE, пакеты GRE должны быть защищены IPsec. Следовательно, remote-gw gre-tunnel  должен указывать на интерфейс IPsec. Настраиваем статический маршрут:

config router static
    edit 1
        set dst Y.Y.Y.Y/30
        set device "HQA-Branch"
    next

 Создадим статический маршрут до локальной сети филиала

		edit 2
        set dst 192.168.112.0 255.255.255.0
        set device "HQ-Branch"
    next
end

И теперь поднялся IPsec и GRE , трафик из локальной сети  головного офиса попадает в локальную сеть филиала и наоборот.

Использовал следующие статьи:

1.  Fortinet

2. Wiki Микротика

Это мой второй труд , прошу сильно не пинать.

Источник: https://habr.com/ru/post/546326/


Интересные статьи

Интересные статьи

Последние ~полгода для работы с Cassandra в Kubernetes мы использовали Rook operator. Однако, когда нам потребовалось выполнить весьма тривиальную, казалось бы, операцию: поменять параметры в...
Привет, Хабр! Мы часто говорим о способах восстановления данных на магнитных и твердотельных накопителях, резервном копировании, создании RAID’ов и прочих ухищрениях, которые помогают не остаться...
Сравнивать CRM системы – дело неблагодарное. Очень уж сильно они отличаются в целях создания, реализации, в деталях.
Введение Взяться за статью, помимо тщеславия, побудила удручающая частота возникновения вопросов по этой теме в профильных группах русскоязычного телеграмм-сообщества. Статья ориентирована на ...
Часть первая. Вводная Часть вторая. Настройка правил Firewall и NAT Часть третья. Настройка DHCP Часть четвертая. Настройка маршрутизации Часть пятая. Настройка балансировщика нагрузки ...