FortiGate Firewall IPsec VPN: Şubeler Arası Tünel

FortiGate Firewall IPsec VPN, iki ofisin ağlarını internetin üzerinden şifreli bir tünelle birbirine bağlayan yapılandırmadır. Merkezdeki bilgisayar şubedeki sunucuya kendi yerel ağındaymış gibi ulaşır, aradaki internet ise yalnız şifreli paketleri görür. Tünelin kurulması iki aşamalıdır: faz 1’de iki cihaz birbirini doğrular ve güvenli bir kanal kurar, faz 2’de hangi ağların hangi şifrelemeyle taşınacağı anlaşılır.

VPN’in ne olduğunu ve IPsec’in el sıkışmasını VPN nedir yazımızda, şube bağlantı seçeneklerini şube bağlantısı yazımızda anlattık. Bu yazı FortiGate Firewall ileri seviye rehberimizin 8. adımıdır. Burada merkezdeki FortiGate ile şubedeki bir cihaz arasında tünel kuruyorum, sonra tüneli koparıp ve bozup ne olduğunu ölçüyorum.

Lab cihazım değerlendirme lisansıyla çalışıyor ve bu lisans IPsec’te yalnız DES şifrelemeye izin veriyor. DES bugün kullanılmaması gereken bir algoritma. Tüneli yine de DES ile kurdum, çünkü yazının ölçtüğü şeyler (faz 1 ve faz 2’nin kuruluşu, rota, kara delik, loglar) şifreleme algoritmasından bağımsız. Gerçek bir cihazda seçilmesi gereken algoritmayı NIST’ten aktarıyorum.

Lab’da iki şey öne çıktı:

1. Tünel koptuğunda şubeye gidecek trafik, yalnız bir kara delik rotası sayesinde internete şifresiz çıkmadı. O rotayı kapatınca aynı ping WAN arayüzünden düz ICMP olarak çıktı.
2. FortiGate’in olay logu iki tipik arızayı, şifreleme uyuşmazlığını ve yanlış anahtarı, sebebini yazarak ayırdı.

Örnekteki sınır kapısında iki elçilik arasında diplomatik çanta taşıyan bir kurye hattı var. Çanta herkesin kullandığı yoldan gider ama yolda kimse onu açamaz. Kurye hattı kesildiğinde mektupların açık postayla gönderilmemesi gerekir. FortiGate’te kurye hattı IPsec tüneli, açık posta da varsayılan rotadır.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde merkez ve şube ofisleri birbirine bağlarken izlediğimiz sırayı anlatır.

FortiGate IPsec VPN Nasıl Olmalı?

Tünel IKEv2 ile, AES şifrelemesi ve güçlü bir Diffie-Hellman grubuyla kurulur. Ön paylaşımlı anahtar rastgele ve uzun üretilir, mümkünse anahtar yerine sertifika kullanılır. Tünel rotasının yanında aynı hedefe bir kara delik rotası durur, böylece tünel koptuğunda trafik internete şifresiz çıkmaz. Kurallar yalnız iki ofisin gerçekten konuşması gereken ağlarına ve servislerine izin verir.

Bu düzeni iki kaynak birlikte tarif ediyor:

1. NIST SP 800-77 Rev. 1 (Haziran 2020), IPsec VPN rehberi:
   • Mümkün olan her yerde IKEv1 yerine IKEv2 kullanılır. NIST’in onayladığı Diffie-Hellman grupları 14 ile 21 arasıdır, eliptik eğri grupları 19, 20 ve 21 güvenlik ve başarım açısından tercih edilir (sayfa 76).
   • 3DES, MD5, SHA-1 ve DH grupları 2 ile 5 kullanılmaz. Yerine SHA-2 ile AES-CBC ya da AES-GCM, DH grubu 14 ya da 19, 20, 21 kullanılır (sayfa 34).
   • İyi bir ön paylaşımlı anahtar rastgele üretilir ve en az 128 bit entropi taşır. Sözlük kelimelerinden türetilen kısa anahtarlar çevrimdışı sözlük saldırısına açıktır (sayfa 29). Aynı kurumun cihazları arasında ön paylaşımlı anahtar yerine açık anahtarlı kimlik doğrulama tercih edilir (sayfa 67).
2. Fortinet, merkez tarafında statik rotalar tarifi: tünel rotasıyla aynı hedefe, daha yüksek yönetim mesafesiyle bir kara delik rotası eklenir. Fortinet’e göre bu, rota tabanlı IPsec tünellerinde en iyi uygulamadır, çünkü tünel kapanınca uzak şubenin ağına giden trafiğin varsayılan rotadan gönderilmesini engeller. Aynı gerekçeyi Fortinet Community’nin kara delik rotası notu da anlatıyor.

Kararlar:

FortiGate IPsec Öncesi: Değerlendirme Lisansı Yalnız DES Önerir

Faz 1 önerisinde hangi algoritmaların seçilebildiğini komut satırında sordum (set proposal ?):

gmfw01 (deneme-p1) # set proposal 
des-md5       des-md5
des-sha1      des-sha1
des-sha256    des-sha256
des-sha384    des-sha384
des-sha512    des-sha512

Bütün seçenekler DES. Fortinet’in sanal makine kılavuzuna göre değerlendirme lisansı yalnız düşük şifrelemeyle çalışıyor. Diffie-Hellman gruplarında ise sınır yok: aynı soruya 1’den 32’ye kadar bütün gruplar listelendi. Tüneli bu yüzden des-sha256 ve DH grubu 14 ile kurdum. DES’in neden bugün kabul edilemeyeceğini şifreleme yazımızda anlattık. NIST üç katlı DES’in (3DES) bile kullanılmamasını istiyor, tek katlı DES ondan da zayıf.

FortiGate IPsec Tüneli Kurmak: Faz 1 ve Faz 2

Arayüzde en kısa yol VPN → IPsec Wizard (IPsec sihirbazı). Sihirbazın ilk ekranında şablon seçilir: Site to Site (iki ofis arası), Hub-and-Spoke (merkez ve çok şube), Remote Access (uzaktan erişim) ya da Custom (özel).

Site to Site şablonu tüneli, rotayı ve iki yönün kurallarını birlikte oluşturur. Ben her parçanın ne yaptığı görünsün diye tüneli ayrı ayrı kurdum. Merkezin WAN adresi 203.0.113.1, şubenin 203.0.113.70. Merkezdeki personel ağı 10.34.30.0/24, şubenin ağı 10.60.0.0/24.

Önce ön paylaşımlı anahtarı ürettim. NIST en az 128 bit rastgele değer istiyor:

openssl rand -base64 24

Bu komut 24 rastgele bayt, yani 192 bit üretir. Anahtar iki cihaza da yazılır. Anahtar sohbet uygulamasıyla ya da e-postayla kesinlikle gönderilmemelidir: bu kanallar mesajın bir kopyasını sunucuda ve iki tarafın cihazında saklar, anahtarı ele geçiren de kendini karşı uç gibi tanıtabilir.

Faz 1 ve faz 2 komut satırında:

config vpn ipsec phase1-interface
    edit "sube-tunel"
        set interface "port3"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal des-sha256
        set dhgrp 14
        set remote-gw 203.0.113.70
        set psksecret <on paylasimli anahtar>
        set comments "Sube baglantisi, lab: DES (degerlendirme lisansi)"
    next
end
config vpn ipsec phase2-interface
    edit "sube-tunel-p2"
        set phase1name "sube-tunel"
        set proposal des-sha256
        set dhgrp 14
        set src-subnet 10.34.30.0 255.255.255.0
        set dst-subnet 10.60.0.0 255.255.255.0
    next
end

Arayüzde aynı tünel VPN → IPsec Tunnels listesinde sube-tunel adıyla duruyor. Formun bölümleri:

1. Network (ağ): Remote Gateway (karşı uç) Static IP Address ve adresi, Interface tünelin çıkacağı WAN arayüzü.
2. Authentication (kimlik doğrulama): Pre-shared Key (ön paylaşımlı anahtar) ve IKE Version 2.
3. Phase 1 Proposal (faz 1 önerisi): Encryption (şifreleme), Authentication (bütünlük) ve Diffie-Hellman Group. Lab cihazında şifreleme listesinde yalnız DES var.
4. Phase 2 Selectors (faz 2 seçicileri): tünelden hangi yerel ağın hangi uzak ağa taşınacağını belirler.

Faz 2’deki dhgrp 14 satırı ayrıca açıklanmayı hak ediyor. Faz 2’de de bir Diffie-Hellman grubu seçmek, tünelin her yeni anahtarını yeni bir Diffie-Hellman değişimiyle üretir. Buna mükemmel ileri gizlilik (PFS) denir: bir anahtar ele geçse bile öncekiyle şifrelenmiş trafik açılmaz.

Karşı Uç: Şubedeki Cihazın Ayarları

Şubede aynı tünelin aynası kurulur. Lab’da şube tarafı bir Linux sunucusunda strongSwan ile çalışıyor. Ayar dosyasında FortiGate’teki her değerin karşılığı görünüyor:

connections {
  merkez {
    version = 2
    local_addrs = 203.0.113.70
    remote_addrs = 203.0.113.1
    proposals = des-sha256-modp2048
    local {
      auth = psk
      id = 203.0.113.70
    }
    remote {
      auth = psk
      id = 203.0.113.1
    }
    children {
      lan {
        local_ts = 10.60.0.0/24
        remote_ts = 10.34.30.0/24
        esp_proposals = des-sha256-modp2048
        start_action = trap
      }
    }
  }
}
secrets {
  ike-merkez {
    id-1 = 203.0.113.70
    id-2 = 203.0.113.1
    secret = "<on paylasimli anahtar>"
  }
}

modp2048, DH grubu 14’ün adıdır. Faz 2 seçicileri ters çevrilmiş olarak duruyor: şubenin yerel ağı merkezin uzak ağıdır. Seçiciler iki uçta birbirinin aynası değilse faz 2 kurulmaz.

FortiGate IPsec Tüneline Rota ve Kural

Tünel kurulunca trafiğin ona yönlenmesi için bir statik rota gerekir. FortiGate’te tünel, rota tablosunda bir arayüz gibi durur: hangi trafiğin tünele gireceğini rota belirler. Rota yoksa tünel ayakta görünür ama şubeye giden paketler ona girmez. Lab’da onları 10.0.0.0/8 kara delik rotası yutardı, kara delik de olmasa varsayılan rotayla internete şifresiz çıkarlardı (aşağıda ölçtüm). Buluttaki sunuculara kurulan tünelde de aynısı geçerli: buluttaki ağın adresi tünel arayüzüne rotalanır.

Arayüzde yol Network → Static Routes → Create New:

1. Destination: Subnet, karşı tarafın ağı. Lab’da şubenin ağı 10.60.0.0/24.
2. Interface: tünelin kendisi, sube-tunel. Ağ geçidi yazılmaz: FortiGate karşı ucun adresini tünelden alıyor, rota listesinde bu rotanın ağ geçidi 203.0.113.70 görünüyor.
3. Administrative Distance: 10, fabrika değeri. Kara delik rotasının mesafesinden (254) küçük olmalı, yoksa tünel ayaktayken de trafik kara deliğe düşer.

Aynı rotanın komut satırındaki karşılığı:

config router static
    edit 0
        set dst 10.60.0.0 255.255.255.0
        set device "sube-tunel"
        set comment "Sube LAN IPsec uzerinden"
    next
end

Kara delik rotası lab cihazında zaten vardı: statik rota yazımızda özel adres bloklarının (RFC 1918) servis sağlayıcıya gitmemesi için 10.0.0.0/8 hedefine mesafesi 254 olan bir kara delik rotası eklemiştik. Şubenin ağı bu bloğun içinde kaldığı için ayrı bir kara delik rotası açmadım. Bunun işe yarayıp yaramadığını aşağıda ölçtüm.

Rota trafiği tünele yönlendirir, geçip geçmeyeceğine ise kural karar verir. FortiGate için tünel de sıradan bir arayüzdür: kural listesinin sonundaki örtük ret onu da kapsar ve kural yazılmadan tünelden hiçbir paket geçmez. Kurallar iki yönde ayrı yazılır ve yalnız gerekeni açar. Merkezden şubeye ping ve web, şubeden merkeze yalnız ping.

Arayüzde yol Policy & Objects → Firewall Policy → Create New. Merkezden şubeye giden kuralın alanları:

1. Incoming Interface: personel ağı, personel.
2. Outgoing Interface: tünelin kendisi, sube-tunel. Tünel bu listede öbür arayüzlerin yanında durur.
3. Source ve Destination: iki ağın adres nesneleri, n-personel ve n-sube-lan.
4. Service: PING ve HTTP.
5. NAT: kapalı. İki ofisin özel adresleri tünelin iki ucunda birbirini olduğu gibi görür.

Şubeden merkeze dönen kural aynı formda, arayüzler ve adresler yer değiştirmiş olarak yazılır. İki kuralın komut satırındaki karşılığı:

config firewall policy
    edit 0
        set name "Personel subeye"
        set srcintf "personel"
        set dstintf "sube-tunel"
        set action accept
        set srcaddr "n-personel"
        set dstaddr "n-sube-lan"
        set schedule "always"
        set service "PING" "HTTP"
        set logtraffic all
    next
    edit 0
        set name "Subeden personele"
        set srcintf "sube-tunel"
        set dstintf "personel"
        set action accept
        set srcaddr "n-sube-lan"
        set dstaddr "n-personel"
        set schedule "always"
        set service "PING"
        set logtraffic all
    next
end

Kural yazma düzenini FortiGate policy yazımızda anlattık.

FortiGate’ten Buluta IPsec: Rota İki Uçta da Yazılır

Buluttaki sunuculara kurulan tünel de aynı parçalardan oluşur. FortiGate’te buluttaki ağın adresi tünel arayüzüne rotalanır ve iki yönün kuralı yazılır. Bulutta tünel kurmadım, bu bölüm sağlayıcıların belgelerinden. Şubeler arası tünelden iki farkı var:

1. Bulut tarafının da rotası gerekir. Tünelin bulut ucu kurumun ağını kendiliğinden bilmez:
   • AWS, Site-to-Site VPN bağlantısı kurulurken yönlendirme tipinin (statik ya da BGP) seçilmesini ve sanal ağdaki alt ağın rota tablosunun güncellenmesini istiyor (AWS Site-to-Site VPN routing options).
   • Azure’da kurumun ağ blokları local network gateway kaydına yazılır. Azure tünele hangi trafiği göndereceğine bu bloklara bakarak karar veriyor (Azure VPN Gateway configuration settings).
   • Oracle Cloud’da sanal ağın rota tablosuna DRG’ye (Dynamic Routing Gateway) giden kural eklenmezse belgeye göre trafik akmıyor (Site-to-Site VPN overview).
2. Bağlantı çoğu zaman iki tünelle gelir. AWS’de her VPN bağlantısının iki tüneli var ve AWS ikisinin de kurulmasını istiyor (Tunnel options). Oracle da her IPsec bağlantısına iki tünel açıyor. Azure’un ağ geçidi fabrika ayarında biri bekleyen iki kopyayla çalışıyor ve kurumun cihazı tek tünel görüyor. Etkin-etkin kipte tünel sayısı ikiye çıkıyor (Azure’da yüksek erişilebilir ağ geçidi).

İki tünelde FortiGate’te her tünel ayrı bir arayüz olur ve buluttaki ağa iki rota yazılır: hedef aynı, ikinci tünelin rotasında mesafe daha büyük. Birinci tünel düşünce rotası pasif olur ve tablo bir sonraki en küçük mesafeli rotayı, yani ikinci tünelinkini seçer. Tünel düşünce rotanın pasifleştiğini aşağıdaki kopuk hat ölçümünde görüyoruz. Rota sayısı büyüyorsa ya da iki tünel birlikte kullanılacaksa statik rota yerine BGP seçilir. Komşuluğu ve duyuruyu BGP yazımızda anlattık.

Doğrulama: FortiGate IPsec Tüneli Ayakta mı, Trafik Şifreli mi?

Merkezdeki personel ağından şubeye ping attım:

2026-10-04 09:55:56 UTC
--- 10.60.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3043ms
rtt min/avg/max/mdev = 0.704/1.057/1.553/0.365 ms

Tünel ilk paketle kuruldu ve dört paketin dördü geldi. FortiGate’in tünel özeti (get vpn ipsec tunnel summary):

'sube-tunel' 203.0.113.70:0  selectors(total,up): 1/1  rx(pkt,err): 4/0  tx(pkt,err): 4/0

selectors(total,up): 1/1, faz 2 seçicisinin ayakta olduğunu, rx ve tx de dört paketin iki yönde de hatasız geçtiğini söylüyor. Ayrıntılı görünüm (diagnose vpn tunnel list name sube-tunel) faz 2’nin hangi ağları taşıdığını ve kaç paket şifrelediğini yazıyor:

name=sube-tunel ver=2 serial=1 203.0.113.1:0->203.0.113.70:0 tun_id=203.0.113.70 ...
...
proxyid=sube-tunel-p2 proto=0 sa=1 ref=3 serial=1
  src: 0:10.34.30.0-10.34.30.255:0
  dst: 0:10.60.0.0-10.60.0.255:0
  SA:  ref=3 options=10202 type=00 soft=0 mtu=1446 expire=42864/0B replaywin=2048
  ...
  dec:pkts/bytes=8/672, enc:pkts/bytes=8/896

Şube tarafında da aynı tünel ayakta (swanctl --list-sas):

merkez: #1, ESTABLISHED, IKEv2, 105d7e31ed5d2e62_i f461e5ae97547710_r*
  local  '203.0.113.70' @ 203.0.113.70[500]
  remote '203.0.113.1' @ 203.0.113.1[500]
  DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  ...
  lan: #2, reqid 1, INSTALLED, TUNNEL, ESP:DES_CBC/HMAC_SHA2_256_128

Arayüzde VPN → IPsec Tunnels listesindeki Status (durum) sütunu Up (ayakta) gösteriyor:

Trafiğin gerçekten şifreli gittiğini görmek için FortiGate’in WAN arayüzünü dinledim ve bu sırada şubeye üç ping attım (diagnose sniffer packet port3 'host 203.0.113.70' 4 6 l):

2026-10-04 12:56:57.924775 port3 -- 203.0.113.1 -> 203.0.113.70: ESP(spi=0xc30bfb59,seq=0xc)
2026-10-04 12:56:57.925170 port3 -- 203.0.113.70 -> 203.0.113.1: ESP(spi=0xf07b3fa1,seq=0xb)
2026-10-04 12:56:58.954947 port3 -- 203.0.113.1 -> 203.0.113.70: ESP(spi=0xc30bfb59,seq=0xd)
2026-10-04 12:56:58.955268 port3 -- 203.0.113.70 -> 203.0.113.1: ESP(spi=0xf07b3fa1,seq=0xc)
2026-10-04 12:56:59.956322 port3 -- 203.0.113.1 -> 203.0.113.70: ESP(spi=0xc30bfb59,seq=0xe)
2026-10-04 12:56:59.956749 port3 -- 203.0.113.70 -> 203.0.113.1: ESP(spi=0xf07b3fa1,seq=0xd)

WAN’da ping yok, yalnız iki ofisin WAN adresleri arasında ESP paketleri var. İçerideki 10.34.30.10 ve 10.60.0.1 adresleri de görünmüyor. İnternet yalnız iki ucun adreslerini ve paketlerin boyunu görür. Örnekteki diplomatik çanta da yolda böyle görünür: kimin kime gönderdiği belli, içi değil.

FortiGate IPsec Hattı Koptuğunda: Kara Delik Rotası

Tünelin koptuğu anı taklit etmek için şube tarafında merkezden gelen IKE ve ESP paketlerini düşürdüm ve iki taraftaki oturumları sildim. Ardından FortiGate’in şube ağı için hangi rotayı seçtiğine baktım (get router info routing-table details 10.60.0.1):

Routing entry for 10.60.0.0/24
  Known via "static", distance 10, metric 0
    via sube-tunel tunnel 203.0.113.70 inactive


Best selected route:
Routing entry for 10.0.0.0/8
  Known via "static", distance 254, metric 0, best
  * directly connected, Null

Tünel rotası inactive, yani pasif oldu. Yerine 254 mesafeli kara delik rotası seçildi (Null). Aynı anda personel ağından şubeye ping attım ve WAN’ı dinledim:

2026-10-04 09:57:34 UTC
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2066ms

2026-10-04 12:57:34.220161 port3 -- 203.0.113.1.500 -> 203.0.113.70.500: udp 436

Ping’ler düştü ve WAN’a tek bir ICMP paketi çıkmadı. Görünen tek paket, FortiGate’in tüneli yeniden kurmak için gönderdiği IKE isteği (UDP 500).

Sonra kara delik rotasını geçici olarak kapatıp aynı ölçümü tekrarladım. Rota tablosu bu kez şunu seçti:

Best selected route:
...
Routing entry for 0.0.0.0/0
  Known via "static", distance 10, metric 0, best
  * 203.0.113.80, via port3

2026-10-04 12:58:14.544012 port3 -- 203.0.113.1 -> 10.60.0.1: icmp: echo request
2026-10-04 12:58:14.544251 port3 -- 10.60.0.1 -> 203.0.113.1: icmp: echo reply
2026-10-04 12:58:15.544837 port3 -- 203.0.113.1 -> 10.60.0.1: icmp: echo request
2026-10-04 12:58:15.545245 port3 -- 10.60.0.1 -> 203.0.113.1: icmp: echo reply

Şubeye gidecek trafik varsayılan rotayı izledi ve WAN arayüzünden şifresiz ICMP olarak çıktı. Lab’da cevap da geldi, çünkü şube cihazı aynı ağdaydı. Gerçek bir hatta bu paketler servis sağlayıcıya gider: ya kaybolur ya da yanlış bir yere ulaşır, ikisinde de şifresizdir. Ping yerine bir dosya paylaşımının ya da veritabanının trafiği olsa da aynı yolu izlerdi. Ölçümden sonra kara delik rotasını yeniden açtım.

Örnekteki kurye hattı kesildiğinde postane mektupları açık postaya vermez, kurye dönene kadar bekletir. Kara delik rotası o bekletme kuralıdır: tünel yokken şube trafiği gidecek bir yol bulamaz ve düşer.

FortiGate IPsec Sorun Giderme: Öneri Uyuşmazlığı ve Yanlış Anahtar

Tünel kurulmadığında ilk bakılacak yer olay logudur: arayüzde Log & Report → Events altında VPN olayları, komut satırında execute log display ile kategori 1, alt tür vpn. İki tipik arızayı bilerek ürettim.

Öneri uyuşmazlığı. Şube tarafının önerisini AES-256 yaptım. FortiGate logu sebebi açıkça yazdı:

date=2026-10-04 time=12:59:30 ... type="event" subtype="vpn" level="error" vd="root" logdesc="IPsec phase 1 error" msg="IPsec phase 1 error" action="negotiate" remip=203.0.113.70 locip=203.0.113.1 ... status="negotiate_error" reason="peer SA proposal not match local policy"

peer SA proposal not match local policy, yani karşı tarafın önerisi yerel ayarla uyuşmuyor. Şube tarafının logu da iki listeyi yan yana yazdı:

2026-10-04T09:59:29+00:00 ntp01 charon-systemd[3404]: received proposals: IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
2026-10-04T09:59:29+00:00 ntp01 charon-systemd[3404]: configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
2026-10-04T09:59:29+00:00 ntp01 charon-systemd[3404]: received proposals unacceptable
2026-10-04T09:59:29+00:00 ntp01 charon-systemd[3404]: generating IKE_SA_INIT response 0 [ N(NO_PROP) ]

FortiGate DES önerdi, şube AES bekliyordu, şube “öneri yok” (NO_PROP) cevabı verdi. Gerçek hayatta bu arıza çoğunlukla iki ucun farklı kişilerce kurulmasından ya da birinin güncellenip ötekinin unutulmasından çıkar. Çözüm, iki ucun önerisini yan yana yazıp aynı yapmaktır.

Yanlış anahtar. Şube tarafındaki ön paylaşımlı anahtarı değiştirdim. FortiGate logu:

date=2026-10-04 time=12:59:47 ... type="event" subtype="vpn" level="error" vd="root" logdesc="IPsec phase 1 error" msg="IPsec phase 1 error" action="negotiate" remip=203.0.113.70 locip=203.0.113.1 ... vpntunnel="sube-tunel" status="negotiate_error" reason="probable preshared key mismatch"

probable preshared key mismatch, yani büyük olasılıkla ön paylaşımlı anahtar uyuşmuyor. Şube tarafı aynı şeyi kendi diliyle yazdı:

2026-10-04T10:00:04+00:00 ntp01 charon-systemd[3404]: tried 1 shared key for '%any' - '203.0.113.1', but MAC mismatched
2026-10-04T10:00:04+00:00 ntp01 charon-systemd[3404]: generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

Öneri uyuşmazlığında tünel ilk mesajda (SA_INIT), yanlış anahtarda ikinci mesajda (IKE_AUTH) kaldı. İki durumda da sorun faz 1’de. Doğru anahtar geri yazılınca tünel ilk pingle yeniden kuruldu. FortiGate’te genel sorun giderme sırasını sorun giderme yazımızda anlattık.

Sonuç: FortiGate IPsec’te Tünelin Yokluğu da Tasarlanır

FortiGate’te IPsec tüneli faz 1, faz 2, bir rota ve iki kuralla kuruluyor. Asıl karar, tünel yokken trafiğin ne olacağıdır. Lab’da dört şey öne çıktı:

1. Değerlendirme lisansı yalnız DES’e izin verdi. Tünel DES ile kuruldu ve çalıştı, ama gerçek cihazda IKEv2, AES ve DH 14 ya da 19-21 seçilir.
2. WAN’da yalnız ESP göründü, içerideki adresler ve ping görünmedi.
3. Tünel koptuğunda kara delik rotası trafiği tuttu. Rota kapatılınca aynı trafik WAN’dan şifresiz çıktı.
4. Olay logu arızanın sebebini yazdı: öneri uyuşmazlığında peer SA proposal not match local policy, yanlış anahtarda probable preshared key mismatch.

Örnekteki kurye hattı çantayı kimseye açtırmadan taşır. Hat kesildiğinde mektupların açık postaya düşmemesini sağlayan ise postanenin bekletme kuralıdır. FortiGate’te kurye hattı tünel, bekletme kuralı kara delik rotasıdır. Sıradaki adım rehberin 9. adımı, evden ya da sahadan bağlanan çalışanlar için uzaktan erişim VPN.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn