VPN na FortiGate

Dokumentację konfiguracji tuneli VPN na urządzeniach FortiGate (w języku angielskim) można znaleźć na stronie producenta pod adresem https://docs.fortinet.com/document/fortigate/7.2.3/administration-guide/954635/getting-started

oraz https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/a06117ca-5fbf-11ed-96f0-fa163e15d75b/FortiOS-7.2.3-Administration_Guide.pdf

Dane dostępowe do klastra FortiGate

Dane dostępowe do VDOM w klastrze FortiGate można znaleźć w panelu Atman Cloud – https://panel.atman.pl/my-cloud. Należy wybrać zakładkę Środowiska chmurowe a następnie zakładkę VPN.

pic1

Jeżeli w panelu nie ma zakładki VPN, usługa VPN nie została uruchomiona dla Twojego środowiska. W celu jej uruchomienia zgłoś się do opiekuna handlowego.

Dostęp do panelu VDOM

Panel VDOM jest dostępny wyłącznie z adresów IP zgłoszonych do Atman. Jeżeli strona logowania VDOM nie otwiera się (przekroczony czas połączenia), najczęstszą przyczyną jest połączenie z adresu spoza tej listy.

Aby dodać lub zmienić adresy IP, wyślij zgłoszenie na adres servicedesk@atman.pl i podaj:

  • nazwę usługi Atman Cloud,

  • listę adresów IP w formacie x.x.x.x/32,

  • adresy, które należy usunąć z listy.

Zgłoszenie musi wysłać osoba uprawniona do zarządzania usługą. W innym przypadku Atman poprosi administratora konta o potwierdzenie.

Limity VDOM

Liczba tuneli, polityk firewall i obiektów adresowych w VDOM jest ograniczona. Po osiągnięciu limitu dodanie kolejnego elementu kończy się komunikatem The VDOM property limit has been reached. W celu zwiększenia limitu zgłoś się do opiekuna handlowego.

Instrukcja migracji tuneli VPN OpenStack-a na klaster FortiGate

W nowym rozwiązaniu klient dostaje jedną wirtualną domenę (VDOM) na klastrze Fortigatów z osobnym publicznym adresem IP. Dostęp do klastra VDOM’u jest możliwy poprzez protokół https (https://<adres_IP_vdom>) oraz ssh. Po zalogowaniu się do VDOM’u należy skonfigurować adresację połączeniową pomiędzy FortiGate a środowiskiem cloud (routerem chmurowym) oraz ustawienie routingu na tym routerze. Poniżej została przedstawiona poglądowa architektura połączeń nowego rozwiązania.

pic2

Konfiguracja połączenia pomiędzy klastrem FortiGate a środowiskiem chmurowym

Po stronie OpenStacka dostajemy łącznik pomiędzy chmurą a vdom’em w klastrze Fortigatów. Łącznik będzie widoczny w zakładce Network -> Networks. Sieć zostanie dodana i będzie miała w nazwie CROSSCONNECT.

pic3

W naszej sieci połączeniowej konfigurujemy adresację połączeniową pomiędzy routerem w chmurze a vdom’em w FortiGate.

pic4

Następnie wypełniamy poniższe formatki. W naszym przykładzie wykorzystaliśmy adresacje 10.255.255.0/30 ale może to również być inna dowolna adresacja.

pic5

pic6

UWAGA

W zakładce Subnet Details opcja Enable DHCP musi być odznaczona. Przy włączonym DHCP OpenStack zajmuje pierwszy wolny adres z puli (w przykładzie 10.255.255.2) na port obsługujący DHCP i metadane. Jeżeli ten sam adres zostanie ustawiony na interfejsie FortiGate, tunel zestawi się, ale ruch pomiędzy chmurą a VPN nie będzie przechodził – patrz Tunel jest zestawiony, ale ruch nie przechodzi.

Powstałą sieć dodajemy do routera w OpenStacku oraz ustawiamy adres na interfejsie wewnętrznym FortiGate. W tym celu przechodzimy do zakładki Network -> Routers, następnie wybieramy nasz router i dodajemy interfejs ADD INTERFACE.

pic7

W naszym przykładzie ustawimy adres 10.255.255.1 po stronie routera w OpenStacku a adres 10.255.255.2 po stronie FortiGate.

pic8

W zakładce Static Routes naszego routera dodajemy trasy które mają być osiągalne poprzez vpn’a na FortiGate.

pic9

Poniżej przykład dodawania trasy dla prefiksu 10.12.0.0/24 który ma być osiągalny przez FortiGate. Adres 10.255.255.2 to ustawiony przez nas adres na FortiGate.

pic10

Gdy już utworzyliśmy konfigurację po stronie środowiska chmurowego to przechodzimy do konfiguracji po stronie FortiGate. Aby dokończyć połączenie z chmurą należy na interfejsie Internal’owym ustawić adres połączeniowy. W naszym przypadku 10.255.255.2/30.

pic11

pic12

Poniżej ustawiamy adres połączeniowy. W tym celu wybieramy Addressing mode Manual oraz IP/Netmask

pic13

UWAGA

Na interfejsie wewnętrznym FortiGate ustaw tylko adres z sieci CROSSCONNECT. Nie dodawaj adresów dodatkowych (Secondary IP Address) z sieci w chmurze, np. 192.168.20.1/24. FortiGate uzna wtedy tę sieć za podłączoną bezpośrednio i nie użyje trasy przez router w OpenStacku.

Dodawanie routingu po stronie FortiGate. Tutaj dodajemy sieci które są w środowisku chmurowym i chcemy je osiągać przez VPN’a.

pic14

pic15

Tworzenie VPN’ów

Tunele VPN możemy tworzyć np. w zakładce VPN -> IPsec Wizard.

pic16

Uzupełniamy formatkę. Remote IP Address to adres tunelu po drugiej stronie, pre-shared key – klucz który musi być taki sam po obu stronach tunelu.

pic17

W następnej formatce wypełniamy adresacje które mają być przesyłane przez tunel. W tym przypadku 10.255.255.0/30 i 192.168.20.0/24 są terminowane po stronie chmury. Po drugiej stronie tunelu ma znajdować się adresacja 10.12.0.0/24.

pic18

Następnie klikamy Create i tworzy nam się konfiguracja tunelu.

pic19

Kreator tworzy tunel, obiekty adresowe, trasę statyczną do sieci po drugiej stronie tunelu oraz dwie polityki firewall (z chmury do tunelu i z tunelu do chmury).

Zalecane parametry tunelu

Poniższe parametry są przykładową, bezpieczną konfiguracją wyjściową. Najważniejsze jest, aby po obu stronach tunelu ustawić te same wartości.

Parametr

Faza 1

Faza 2

Wersja IKE

IKEv2

–

Szyfrowanie

AES256

AES256

Uwierzytelnianie

SHA256

SHA256

Grupa Diffie-Hellman

14

14 (PFS włączone)

Key Lifetime

28800 s

3600 s

Dead Peer Detection

On Idle

–

Auto-negotiate

–

włączone

Selektory fazy 2 (sieci lokalne i zdalne) muszą być lustrzanym odbiciem po obu stronach: sieć lokalna po stronie FortiGate jest siecią zdalną po drugiej stronie i odwrotnie, z tą samą maską.

Jeżeli przez tunel ma być przesyłanych kilka sieci, a druga strona to np. Cisco ASA, Juniper, MikroTik lub Azure, zalecamy utworzenie osobnego selektora fazy 2 dla każdej pary sieci zamiast jednego selektora z grupą adresów.

Rozwiązywanie problemów

Większość problemów z tunelami wynika z niezgodnej konfiguracji po obu stronach tunelu albo z brakującego routingu lub polityki. Poniższe sekcje opisują, jak sprawdzić stan tunelu, odczytać przyczynę błędu i ją usunąć.

W przykładach użyto następującej adresacji:

Element

Adres

sieć w Atman Cloud

192.168.20.0/24 (instancja 192.168.20.10)

sieć CROSSCONNECT

10.10.0.0/24 – router w OpenStacku 10.10.0.1, FortiGate 10.10.0.254

sieć po drugiej stronie tunelu

10.12.0.0/24

tunel

VPN-Biuro

Sprawdzenie stanu tunelu

Monitor IPsec

Stan tuneli widoczny jest na ekranie Dashboard -> Network, w widżecie IPsec. Po kliknięciu widżetu otwiera się widok szczegółowy.

pic20

  • kolumna Phase 1 – stan negocjacji fazy 1 (uwierzytelnienie stron),

  • kolumna Phase 2 Selectors – stan selektorów fazy 2 (sieci przesyłanych przez tunel),

  • Incoming Data / Outgoing Data – ruch odebrany i wysłany przez tunel. Jeżeli rośnie tylko jedna z wartości, ruch dociera do tunelu tylko w jedną stronę,

  • przyciski Bring Up / Bring Down – ręczne zestawienie lub rozłączenie tunelu,

  • Show Matching Logs – logi zdarzeń dotyczące wybranego tunelu.

Poniżej tunel, w którym faza 1 jest zestawiona, a faza 2 nie. Najczęstszą przyczyną są niezgodne selektory – patrz Faza 2 nie zestawia się.

pic21

Konsola CLI

Polecenia CLI można wykonać bez połączenia SSH – w panelu VDOM należy kliknąć ikonę >_ w prawym górnym rogu. Otworzy się okno CLI Console. Wynik poleceń można zapisać do pliku przyciskiem Download.

pic22

Podsumowanie stanu tuneli:

get vpn ipsec tunnel summary

'VPN-Biuro' 77.79.246.39:4500  selectors(total,up): 1/1  rx(pkt,err): 200/0  tx(pkt,err): 139/0

Wartość selectors(total,up): 1/1 oznacza, że wszystkie selektory fazy 2 są zestawione. Wartość 1/0 oznacza, że faza 2 nie jest zestawiona.

Tablica routingu VDOM:

get router info routing-table all

Szczegóły tunelu:

diagnose vpn ike gateway list name <nazwa_tunelu>

diagnose vpn tunnel list name <nazwa_tunelu>

UWAGA

Wynik poleceń diagnose vpn ike gateway list i diagnose vpn tunnel list zawiera klucze szyfrujące bieżącej sesji (linie SK_ei, SK_er, SK_ai, SK_ar, dec: i enc:). Przed przesłaniem wyniku komukolwiek usuń te linie.

Logi zdarzeń VPN

Logi zdarzeń dostępne są na ekranie Log & Report -> System Events, po wybraniu z listy VPN Events. Przyczyna błędu widoczna jest po zaznaczeniu wiersza z błędem i kliknięciu Details, w polu Reason.

pic23

Komunikaty, które najczęściej wskazują przyczynę problemu:

  • IPsec phase 1 error, Reason probable preshared key mismatch – różne klucze pre-shared key po obu stronach. Ustaw ten sam klucz po obu stronach.

  • IPsec phase 1 error, Reason peer SA proposal not match local policy – różne algorytmy szyfrowania, uwierzytelniania, grupy DH lub wersja IKE w fazie 1. Patrz Tunel nie zestawia się (faza 1).

  • IPsec phase 2 error, Reason peer SA proposal not match local policy – różne algorytmy lub ustawienie PFS w fazie 2. Ustaw te same parametry fazy 2 po obu stronach.

  • IPsec DPD failed, Status dpd_failure – druga strona przestała odpowiadać (awaria, zmiana adresu IP, blokada UDP 500/4500). Sprawdź urządzenie i łącze po drugiej stronie.

Niezgodne selektory fazy 2 nie są widoczne w logach zdarzeń – faza 1 kończy się sukcesem, a faza 2 nie zestawia się. Przyczynę pokazuje dopiero log negocjacji opisany poniżej.

Szczegółowy log negocjacji

Jeżeli logi zdarzeń nie wskazują przyczyny, należy w konsoli CLI włączyć log negocjacji IKE dla adresu drugiej strony tunelu:

diagnose vpn ike log filter clear
diagnose vpn ike log filter dst-addr4 <publiczny_IP_drugiej_strony>
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable

Następnie należy zestawić tunel (np. przyciskiem Bring Up w monitorze IPsec) i odczytać komunikaty. Po zakończeniu diagnostyki należy wyłączyć log:

diagnose debug disable
diagnose debug application ike 0
diagnose vpn ike log filter clear

Komunikaty w logu negocjacji i ich znaczenie:

  • PSK auth failed: probable pre-shared key mismatch – różne klucze pre-shared key. Zestawienie tunelu rozpoczęła druga strona.

  • received notify type AUTHENTICATION_FAILED – druga strona odrzuciła uwierzytelnienie, najczęściej z powodu innego klucza pre-shared key. Zestawienie tunelu rozpoczął FortiGate.

  • no proposal chosen – różne parametry fazy 1 lub fazy 2. Porównaj sekcje incoming proposal i my proposal.

  • Negotiate ISAKMP SA Error i no SA proposal chosen – druga strona używa innej wersji IKE (np. IKEv1, gdy na FortiGate ustawiono IKEv2).

  • failed to match peer selectors – niezgodne selektory fazy 2.

  • powtarzający się sent IKE msg (RETRANSMIT_SA_INIT) bez odpowiedzi – druga strona nie odpowiada: błędny adres Remote Gateway, ruch UDP 500/4500 blokowany po drugiej stronie albo tunel wyłączony po drugiej stronie.

  • send IKEv2 DPD probe i link fail – druga strona przestała odpowiadać na zestawionym tunelu (Dead Peer Detection).

Przykład dla różnych grup Diffie-Hellman w fazie 1 – druga strona proponuje grupę 15 (MODP3072), a na FortiGate ustawiono grupę 14 (MODP2048):

ike 2:...: incoming proposal:
ike 2:...:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:...:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 2:...:         type=PRF, val=PRF_HMAC_SHA2_256
ike 2:...:         type=DH_GROUP, val=MODP3072.
ike 2:...: my proposal, gw VPN-Biuro:
ike 2:...:         type=ENCR, val=AES_CBC (key_len = 256)
ike 2:...:         type=INTEGR, val=AUTH_HMAC_SHA2_256_128
ike 2:...:         type=PRF, val=PRF_HMAC_SHA2_256
ike 2:...:         type=DH_GROUP, val=MODP2048.
ike 2:...: no proposal chosen

Przykład dla niezgodnych selektorów – druga strona zgłasza sieć 10.13.0.0/24, a na FortiGate jako sieć zdalną ustawiono 10.12.0.0/24:

ike 2:VPN-Biuro:...: TSi_0 0:10.13.0.0-10.13.0.255:0
ike 2:VPN-Biuro:...: TSr_0 0:192.168.20.0-192.168.20.255:0
ike 2:VPN-Biuro:...: comparing selectors
ike 2:VPN-Biuro:...: failed to match peer selectors

Tunel nie zestawia się (faza 1)

Należy sprawdzić, czy po obu stronach tunelu ustawione są identyczne wartości:

  • adres Remote Gateway (publiczny adres IP drugiej strony; po drugiej stronie – publiczny adres IP VDOM),

  • wersja IKE (IKEv1 lub IKEv2),

  • pre-shared key,

  • algorytm szyfrowania, algorytm uwierzytelniania i grupa Diffie-Hellman,

  • czas życia klucza (Key Lifetime),

  • identyfikatory Local ID / Peer ID (jeżeli są używane).

Jeżeli urządzenie po drugiej stronie znajduje się za NAT, ruch UDP 500 oraz UDP 4500 musi być przekierowany do tego urządzenia. FortiGate wykrywa NAT automatycznie, a tunel działa wtedy na porcie 4500.

Faza 2 nie zestawia się lub działa tylko dla części sieci

Selektory fazy 2 muszą być lustrzanym odbiciem po obu stronach: sieć lokalna po stronie FortiGate musi być siecią zdalną po drugiej stronie i odwrotnie.

  • Różne sieci (np. 10.12.0.0/24 na FortiGate i 10.13.0.0/24 po drugiej stronie) – faza 2 nie zestawia się, w logu negocjacji widoczny jest komunikat failed to match peer selectors.

  • Różne maski (np. 10.12.0.0/24 na FortiGate i 10.12.0.0/16 po drugiej stronie) – przy IKEv2 tunel zestawia się, ale FortiGate zawęża selektor do 10.12.0.0/24. Ruch z adresów spoza tej sieci (np. 10.12.5.10) nie przechodzi przez tunel. Przy IKEv1 faza 2 nie zestawi się.

  • Kilka sieci w jednym selektorze – część urządzeń (np. Cisco ASA, Juniper) obsługuje tylko jedną parę sieci na selektor. Należy utworzyć osobny selektor fazy 2 dla każdej pary sieci.

Po dodaniu nowej sieci po jednej stronie tunelu należy ją dodać również po drugiej stronie, w trasach statycznych oraz w politykach firewall, a następnie zrestartować tunel (Bring Down, Bring Up).

Tunel jest zestawiony, ale ruch nie przechodzi

Jeżeli tunel ma status Up, a ruch pomiędzy sieciami nie przechodzi, należy kolejno sprawdzić poniższe punkty.

KROK 1. Połączenie FortiGate z routerem w OpenStacku

W konsoli CLI należy wykonać ping do adresu routera w sieci CROSSCONNECT z adresu interfejsu wewnętrznego FortiGate:

execute ping-options source 10.10.0.254
execute ping 10.10.0.1

Brak odpowiedzi oznacza błąd w konfiguracji sieci CROSSCONNECT – patrz Brak komunikacji pomiędzy FortiGate a routerem w chmurze.

KROK 2. Adres FortiGate nie może być zajęty w OpenStacku

Jeżeli ping do routera działa, ale do żadnej instancji w chmurze już nie, a pakiety z chmury nie docierają do FortiGate, przyczyną może być konflikt adresów. Przy włączonym DHCP w podsieci CROSSCONNECT OpenStack przydziela pierwszy wolny adres z puli (np. 10.10.0.2 lub 10.255.255.2) portowi obsługującemu DHCP i metadane. Router w OpenStacku wysyła wtedy ruch skierowany do tego adresu do tego portu, a nie do FortiGate.

Zajęte adresy w sieci można sprawdzić poleceniem:

openstack port list --network <nazwa_sieci_CROSSCONNECT> --long -c "Fixed IP Addresses" -c "Device Owner"

Port z właścicielem network:distributed lub network:dhcp zajmuje adres, którego nie można użyć na FortiGate. W takim przypadku należy ustawić na interfejsie wewnętrznym FortiGate inny, wolny adres z tej podsieci i poprawić Next Hop w trasach statycznych routera w OpenStacku. Nowe podsieci CROSSCONNECT należy tworzyć z wyłączonym DHCP.

KROK 3. Routing w OpenStacku

Router w projekcie musi mieć trasę statyczną do sieci po drugiej stronie tunelu, wskazującą jako Next Hop adres FortiGate w sieci CROSSCONNECT. Trasy sprawdzamy w Project -> Network -> Routers -> -> Static Routes.

pic24

Trasy routera można też sprawdzić poleceniem openstack router show <nazwa_routera> -c routes.

KROK 4. Routing na FortiGate

W VDOM musi istnieć trasa do sieci w chmurze przez adres routera w sieci CROSSCONNECT oraz trasa do sieci po drugiej stronie przez interfejs tunelu (kreator tworzy ją automatycznie, razem z trasą Blackhole). Trasy sprawdzamy w Network -> Static Routes.

pic25

W tablicy routingu (get router info routing-table all) sieć w chmurze musi być widoczna jako trasa statyczna (S) przez router w OpenStacku:

S       192.168.20.0/24 [10/0] via 10.10.0.1, Internal-vdom-9, [1/0]

Jeżeli zamiast niej widoczny jest wpis C 192.168.20.0/24 is directly connected, Internal-vdom-9, na interfejsie wewnętrznym ustawiono adres z sieci w chmurze. FortiGate szuka wtedy instancji bezpośrednio w sieci CROSSCONNECT, a druga strona tunelu otrzymuje komunikat ICMP host 192.168.20.10 unreachable. Należy usunąć ten adres z interfejsu.

KROK 5. Polityki firewall na FortiGate

W Policy & Objects -> Firewall Policy muszą istnieć polityki zezwalające na ruch w obu kierunkach pomiędzy interfejsem tunelu a interfejsem wewnętrznym. W politykach dla ruchu VPN kolumna NAT musi mieć wartość Disabled. Widok wszystkich polityk w kolejności sprawdzania daje przycisk By Sequence.

pic26

Przy włączonym NAT instancja w chmurze widzi ruch z adresu FortiGate (np. 10.10.0.254), a nie z sieci po drugiej stronie tunelu. Reguły grup zabezpieczeń dla tej sieci przestają wtedy działać.

Którą politykę dopasuje FortiGate do danego ruchu, można sprawdzić przyciskiem Policy lookup.

KROK 6. Grupy zabezpieczeń instancji

Grupa zabezpieczeń przypisana do instancji musi zezwalać na ruch z sieci po drugiej stronie tunelu (reguła z Remote IP Prefix równym tej sieci, np. 10.12.0.0/24). Opis w rozdziale Grupy zabezpieczeń (Security Groups).

pic27

KROK 7. Firewall w systemie operacyjnym

Należy sprawdzić firewall wewnątrz instancji (np. Windows Defender Firewall, ufw, firewalld, iptables).

KROK 8. Druga strona tunelu

Należy sprawdzić routing i polityki firewall na urządzeniu po drugiej stronie tunelu oraz to, czy urządzenia w sieci lokalnej mają trasę do sieci w chmurze.

Śledzenie pakietów na FortiGate

Którędy FortiGate przesyła pakiety i czy je odrzuca, pokazuje polecenie diagnose debug flow. Przykład dla ruchu do instancji 192.168.20.10:

diagnose debug flow filter clear
diagnose debug flow filter addr 192.168.20.10
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 10

Następnie należy wygenerować ruch (np. ping z sieci po drugiej stronie tunelu) i po zakończeniu wyłączyć diagnostykę:

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear

Poprawny przebieg – pakiet z tunelu trafia do routera w OpenStacku, a odpowiedź wraca do tunelu:

received a packet(proto=1, 10.12.0.1:6463->192.168.20.10:2048) ... from VPN-Biuro.
find a route: flag=00000000 gw-10.10.0.1 via Internal-vdom-9
Allowed by Policy-2:
received a packet(proto=1, 192.168.20.10:6463->10.12.0.1:0) ... from Internal-vdom-9.
find a route: flag=00000000 gw-77.79.246.39 via VPN-Biuro

Najczęstsze wyniki i ich przyczyny:

  • Denied by forward policy check (policy 0) – brak polityki firewall dla tego ruchu (KROK 5).

  • SNAT 10.12.0.1->10.10.0.254 – włączony NAT w polityce VPN (KROK 5).

  • pakiet przekazany do routera (Allowed by Policy), ale brak odpowiedzi z interfejsu wewnętrznego – brak trasy w OpenStacku, blokada w grupie zabezpieczeń lub w firewallu instancji (KROK 2, 3, 6, 7).

  • brak jakichkolwiek wpisów – ruch nie dociera do FortiGate. Sprawdź drugą stronę tunelu lub routing w OpenStacku.

Polecenie diagnose sniffer packet nie jest dostępne dla konta administratora VDOM – do śledzenia ruchu należy używać diagnose debug flow.

Brak komunikacji pomiędzy FortiGate a routerem w chmurze

Jeżeli z FortiGate nie odpowiada adres routera OpenStack w sieci CROSSCONNECT, należy sprawdzić:

  • czy sieć CROSSCONNECT została dodana jako interfejs routera (ADD INTERFACE) z poprawnym adresem,

  • czy adres i maska na interfejsie wewnętrznym FortiGate należą do tej samej podsieci,

  • czy w tablicy ARP FortiGate widoczny jest adres routera: get system arp.

Jeżeli adres routera nie pojawia się w tablicy ARP mimo poprawnej konfiguracji po obu stronach, należy wysłać zgłoszenie do Atman – może to oznaczać problem z siecią połączeniową po stronie Atman.

Połączenia zawieszają się przy większych transferach

Jeżeli ping przez tunel działa, ale zawieszają się większe transfery (np. kopiowanie plików, RDP, zapytania do bazy danych), przyczyną może być rozmiar pakietów. Tunel IPsec dodaje własne nagłówki, więc maksymalny rozmiar pakietu w tunelu jest mniejszy niż 1500 bajtów – np. dla IKEv2 z AES256/SHA256 i drugą stroną za NAT wynosi 1422 bajty.

Rozmiar pakietów przechodzących przez tunel można sprawdzić pingiem z ustawioną flagą „nie fragmentuj”:

  • Linux: ping -M do -s 1394 192.168.20.10

  • Windows: ping -f -l 1394 192.168.20.10

Jeżeli ping o mniejszym rozmiarze działa, a o większym nie, należy ograniczyć rozmiar segmentów TCP (MSS) w politykach VPN na FortiGate. W konsoli CLI:

config firewall policy
    edit <ID_polityki>
        set tcp-mss-sender 1350
        set tcp-mss-receiver 1350
    next
end

Polecenie należy wykonać dla obu polityk VPN (z chmury do tunelu i z tunelu do chmury). ID polityk tunelu pokazuje polecenie show firewall policy | grep -f <nazwa_tunelu> – numer znajduje się w wierszu edit <ID>.

Tunel okresowo się rozłącza

Najczęstsze przyczyny okresowych rozłączeń:

  • różne czasy życia kluczy (Key Lifetime) w fazie 1 lub 2 – przy odnawianiu kluczy (rekey) tunel może się rozłączyć,

  • wyłączone PFS po jednej stronie i włączone po drugiej – przy IKEv2 problem ujawnia się dopiero przy pierwszym odnowieniu kluczy fazy 2,

  • brak ruchu w tunelu – jeżeli druga strona zestawia tunel tylko „na żądanie”, zalecamy włączenie opcji Auto-negotiate w fazie 2 oraz Dead Peer Detection (On Idle) w fazie 1,

  • zmienny adres IP drugiej strony (np. łącze bez stałego adresu IP).

W logach zdarzeń rozłączenie przez Dead Peer Detection widoczne jest jako IPsec DPD failed.

Co podać w zgłoszeniu

Jeżeli problem nie został rozwiązany, należy wysłać zgłoszenie na adres servicedesk@atman.pl i podać:

  • nazwę usługi Atman Cloud i nazwę tunelu w VDOM,

  • publiczny adres IP drugiej strony tunelu oraz typ urządzenia (np. MikroTik, Cisco ASA, Azure VPN Gateway),

  • datę i godzinę wystąpienia problemu,

  • parametry fazy 1 i fazy 2 po drugiej stronie tunelu,

  • wynik poleceń get vpn ipsec tunnel summary i get router info routing-table all,

  • adresy instancji, z którymi nie ma komunikacji.

Nie przesyłaj w zgłoszeniu klucza pre-shared key ani linii z kluczami sesji z wyników poleceń diagnose.