FortiGate Firewall Uzaktan Erişim VPN: IPsec ve FortiClient

FortiGate Firewall uzaktan erişim VPN, evden ya da sahadan çalışan bir kişinin bilgisayarını internetin üzerinden şifreli bir tünelle kurum ağına bağlayan yapılandırmadır. Şubeler arası tünelden üç farkı var:

1. Karşı ucun adresi bilinmez. Çalışan her gün başka bir ağdan bağlanır. FortiGate bu yüzden tüneli kimin açacağını adresten değil kimlikten tanır. Bu tünele dial-up (bağlanan istemcili) tünel denir.
2. Bağlanan bir cihaz değil bir kişidir. Kurumun ortak anahtarının yanında her kişi kendi kullanıcı adı ve parolasıyla doğrulanır.
3. Bilgisayar kurum ağında bir adres alır. FortiGate bağlanan bilgisayara bir havuzdan adres ve hangi ağlara tünelden gideceğini söyler.

Bu yazı FortiGate Firewall ileri seviye rehberimizin 9. adımıdır. Şubeler arası tüneli FortiGate IPsec VPN yazımızda kurduk. Burada Fortinet’in FortiClient için verdiği örnek yapılandırmayı kuruyorum, bir istemciyi bağlıyorum ve hattaki paketlere bakıyorum.

Lab’da iki sınır var. Değerlendirme lisansı IPsec’te yalnız DES şifrelemeye izin veriyor, şubeler arası tünelde olduğu gibi. İstemci tarafında da FortiClient değil, aynı protokolü konuşan bir Linux istemcisi (strongSwan) var. FortiClient’ın kendi ekranını Fortinet’in belgesinden aktarıyorum.

Lab’da dört sonuç öne çıktı:

1. Fortinet’in örneğindeki aggressive mode, istemcinin kimliğini ve ön paylaşımlı anahtardan türetilen hash’i hatta şifresiz gönderdi.
2. Bağlanan istemci havuzdan adres aldı ve tünelden yalnız kurum ağının rotası geldi, internet trafiği tünelin dışında kaldı.
3. FortiGate’te statik rota yazmadım: istemcinin adresine giden rotayı FortiGate kendisi ekledi. Bu ayarı kapatınca tünel kuruldu, ama istemcinin paketleri dönüş yolu denetiminde düştü.
4. Yanlış parolada FortiGate’in logu kullanıcıyı ve sebebi ayrı ayrı yazdı.

Örnekteki sınır kapısında şubeler arası kurye hattının yanında bir de yolcu kapısı var. Yolcular tek tek gelir, kapı her birinin kimliğine bakar, içeride kullanacağı geçici bir kart verir ve yalnız gideceği binaların yolunu açar. FortiGate’te yolcu kapısı uzaktan erişim tüneli, geçici kart da havuzdan verilen adrestir.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde uzaktan çalışanları kurum ağına bağlarken izlediğimiz sırayı anlatır.

FortiGate Uzaktan Erişim VPN Nasıl Olmalı?

Uzaktan erişim IKEv2 ile kurulur ve her çalışan kendi kimliğiyle, tercihen sertifikayla ya da en azından iki aşamalı doğrulamayla bağlanır. Bütün çalışanların paylaştığı bir ön paylaşımlı anahtar tek başına güvenlik sağlamaz. Bağlanan bilgisayar yalnız işi için gereken ağlara ve servislere erişir. Ayrık tünel açılıp açılmayacağı bilerek seçilir ve yazılır.

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. IKEv1 kullanılıyorsa aggressive mode’dan kaçınılır, çünkü ana kipe (main mode) göre çok daha zayıf güvenlik sağlar (sayfa 76).
   • Ön paylaşımlı anahtar kurulması en kolay ama açık ara en az güvenli yöntemdir. Uzaktan erişimde EAP-TLS ya da makine sertifikasıyla kimlik doğrulama kullanılır (sayfa 67).
   • Ayrık tünelde istemci aynı anda hem kurum ağıyla hem internetle konuşur. Ele geçirilmiş bir bilgisayar bu yüzden saldırgana kurum ağına giden bir yol açabilir. Ayrık tüneli kapatmak bu etkiyi sınırlar (sayfa 64-65).
2. Fortinet FortiOS 7.0 yönetim kılavuzu, FortiClient as dialup client: sihirbazla ve komut satırıyla kurulan örnek IKEv1 aggressive mode, XAuth (kullanıcı adı ve parolayla ek doğrulama) ve ön paylaşımlı anahtar kullanıyor. Sihirbazda ayrık tünel fabrika ayarında açık. Aynı belge aynı arayüze birden çok dial-up tünel tanımlanırsa her birine ayrı bir eş kimliği (peer ID) verilmesini istiyor.

Fortinet’in kendi örneği NIST’in kaçınılmasını istediği iki şeyi, aggressive mode’u ve paylaşılan anahtarı kullanıyor. Lab’da bu örneği kurup bedelini ölçtüm. Karar tablosu ölçümden sonra:

Fortinet’in FortiClient Örneği: Sihirbaz Ne Kuruyor?

Arayüzde yol VPN → IPsec Wizard. İlk ekranda Template type (şablon türü) Remote Access (uzaktan erişim), Remote device type (uzak cihaz türü) Client-based (istemcili) seçilir, istemci olarak da FortiClient:

Sihirbaz beş adımda tüneli, adres havuzunu, kuralı ve rotaları birlikte kurar. Adımları ve Fortinet’in örnek değerlerini belgesi sayıyor:

1. VPN Setup: ad, şablon ve istemci türü.
2. Authentication: gelen arayüz (WAN), kimlik doğrulama yöntemi Pre-shared Key ve anahtar, User Group (kullanıcı grubu).
3. Policy & Routing: iç arayüz ve iç ağ, istemci adres aralığı, DNS sunucusu ve Enable IPv4 Split tunnel (ayrık tüneli aç), fabrika ayarında açık.
4. Client Options: parolanın istemcide saklanması, otomatik bağlanma gibi istemci seçenekleri.
5. Review Settings: oluşturulacak nesnelerin listesi.

Sihirbazı sonuna kadar çalıştırmadım: sihirbaz kendi kuralını da ekler ve lab cihazımda değerlendirme lisansının 10 kural sınırı doluydu. Aynı yapıyı komut satırından kurdum, yer açmak için şubeler arası tünelin bir kuralını sildim. Aşağıdaki yapılandırma Fortinet’in belgesindeki örnekle aynı satırları taşıyor.

FortiGate Uzaktan Erişim VPN Kurulumu: Kullanıcı, Havuz ve Tünel

Önce bağlanacak kullanıcılar ve grupları. Lab’da yerel bir test kullanıcısı açtım:

config user local
    edit "uzak.test"
        set type password
        set passwd <parola>
    next
end
config user group
    edit "vpn-uzak-calisan"
        set member "uzak.test"
    next
end

Gerçek kurulumda kullanıcı FortiGate’te tutulmaz, gruba kurumun dizini bağlanır: çalışan işten ayrılınca VPN hakkı da dizindeki hesabıyla birlikte kapanır. Active Directory grubunu FortiGate’e bağlamayı AD entegrasyonu yazımızda anlattık.

İstemcilere verilecek adres havuzu, kurumun hiçbir ağıyla çakışmayan ayrı bir blok:

config firewall address
    edit "n-vpn-istemci"
        set type iprange
        set comment "Uzaktan erisim VPN istemci havuzu"
        set start-ip 10.99.0.10
        set end-ip 10.99.0.50
    next
end

Tünel, Fortinet’in örneğindeki değerlerle (ad ve ağlar lab’ın):

config vpn ipsec phase1-interface
    edit "uzak-erisim"
        set type dynamic
        set interface "port3"
        set mode aggressive
        set peertype any
        set net-device disable
        set mode-cfg enable
        set proposal des-sha256
        set dpd on-idle
        set comments "Uzaktan erisim, Fortinet FortiClient ornegi: IKEv1 aggressive + XAuth"
        set dhgrp 14
        set xauthtype auto
        set authusrgrp "vpn-uzak-calisan"
        set assign-ip-from name
        set dns-mode auto
        set ipv4-split-include "n-personel"
        set ipv4-name "n-vpn-istemci"
        set psksecret ENC [gizlendi]
        set dpd-retryinterval 60
    next
end
config vpn ipsec phase2-interface
    edit "uzak-erisim-p2"
        set phase1name "uzak-erisim"
        set proposal des-sha256
        set dhgrp 14
    next
end

Satırların işi:

1. type dynamic: karşı ucun adresi yazılmaz, doğru ön paylaşımlı anahtarı bilen her istemci tüneli açmaya başlayabilir.
2. mode aggressive: IKEv1’in kısa el sıkışmasını seçer. Bedelini aşağıda ölçtüm.
3. xauthtype auto ve authusrgrp: ön paylaşımlı anahtardan sonra kullanıcıdan adı ve parolası istenir, kullanıcı bu grupta olmalıdır.
4. mode-cfg enable, ipv4-name, dns-mode auto: istemciye havuzdan adres ve DNS sunucusu verilir. Lab’da istemciye FortiGate’in kendi DNS sunucuları (192.168.1.10 ve 8.8.8.8) geldi.
5. ipv4-split-include "n-personel": istemciye yalnız personel ağının rotası verilir, ayrık tünel budur. Satır olmazsa bütün trafik tünelden gelir.
6. peertype any: istemcinin kimliği ne olursa olsun kabul edilir. Fortinet aynı arayüzde birden çok dial-up tünel varsa her birine ayrı kimlik (peertype one, peerid) verilmesini istiyor.

Arayüzde aynı tünel VPN → IPsec Tunnels listesinde uzak-erisim adıyla duruyor:

Son parça, havuzdan iç ağa izin veren kural. Tünel arayüzü de kural listesinin sonundaki örtük retle kapalıdır, kural yazılmadan bağlanan çalışan hiçbir yere ulaşamaz. Arayüzde yol Policy & Objects → Firewall Policy → Create New:

1. Incoming Interface: tünel, uzak-erisim. Bağlanan bütün çalışanlar bu tek arayüzden gelir.
2. Outgoing Interface: personel.
3. Source: havuzun adres nesnesi, n-vpn-istemci. Kaynak, çalışanın havuzdan aldığı adrestir.
4. Destination ve Service: n-personel, PING ve HTTP.

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

config firewall policy
    edit 0
        set name "Uzak calisan personele"
        set srcintf "uzak-erisim"
        set dstintf "personel"
        set action accept
        set srcaddr "n-vpn-istemci"
        set dstaddr "n-personel"
        set schedule "always"
        set service "PING" "HTTP"
        set logtraffic all
    next
end

Tek yön yeter: çalışanın açtığı bağlantının cevabı, FortiGate’in oturum tablosundaki kayda göre geri döner. Kural yalnız personel ağına ve iki servise izin veriyor. Uzaktan çalışana “her yere her şey” açmak, VPN’i iç ağın kapısı yapmak demektir. Kural yazma düzenini FortiGate policy yazımızda anlattık.

FortiClient Tarafı

Fortinet’in belgesine göre FortiClient’ta Remote Access (uzaktan erişim) ekranında Add a new connection (yeni bağlantı ekle) seçilir:

1. VPN türü IPsec VPN, Remote Gateway (uzak ağ geçidi) FortiGate’in WAN adresi.
2. Authentication Method Pre-Shared Key ve anahtar.
3. Gerekiyorsa Advanced Settings → Phase 1 altında Local ID (yerel kimlik), FortiGate’te tanımlı eş kimliğiyle aynı.
4. Kaydedip bağlanırken kullanıcı adı ve parola girilir.

Lab’da istemci yerine aynı ayarları taşıyan strongSwan çalıştı: IKEv1 aggressive mode, uzak-dizustu kimliği, ön paylaşımlı anahtar ve XAuth kullanıcısı uzak.test.

Doğrulama: Bağlanan Kullanıcı Ne Aldı?

İstemci bağlandı:

[IKE] installing new virtual IP 10.99.0.10
[CFG] selected proposal: ESP:DES_CBC/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ
[IKE] CHILD_SA personel{3} established with SPIs ce34c284_i b2af2768_o and TS 10.99.0.10/32 === 10.34.30.0/24
initiate completed successfully

İki satır yapılandırmanın iki parçasını gösteriyor:

1. virtual IP 10.99.0.10: istemci havuzun ilk adresini aldı.
2. TS 10.99.0.10/32 === 10.34.30.0/24: tünel yalnız istemcinin adresiyle personel ağı arasındaki trafiği taşıyor. Ayrık tünel satırı istemciye bu kadarını söyledi.

İstemciden personel ağındaki bir makineye ping tünelden geçti:

3 packets transmitted, 3 received, 0% packet loss, time 2065ms
rtt min/avg/max/mdev = 0.698/0.887/1.161/0.193 ms

FortiGate’te bağlı kullanıcıyı diagnose vpn ike gateway list gösteriyor. Tünelin bağlanan her istemci için ayrı bir kopyası açılıyor, adı tünelin adı ve bir sıra numarası (uzak-erisim_0):

name: uzak-erisim_0
version: 1
addr: 203.0.113.1:500 -> 203.0.113.75:500
xauth-user: uzak.test
peer-id: uzak-dizustu
peer-id-auth: no
assigned IPv4 address: 10.99.0.10/0.0.0.0
IKE SA: created 1/1  established 1/1  time 10/10/10 ms
IPsec SA: created 1/1  established 1/1  time 10/10/10 ms

Kullanıcı adı, istemcinin bildirdiği kimlik ve verilen adres bir arada. peer-id-auth: no satırı, kimliğin doğrulanmadan kabul edildiğini söylüyor: peertype any ayarının sonucu. Arayüzde VPN → IPsec Tunnels listesinde tünelin Status (durum) sütunu bağlı istemci sayısını yazıyor:

FortiGate Uzaktan Erişimde Statik Rota Gerekir mi?

Gerekmez. Şubeler arası tünelde şubenin ağını tünele elle rotalamıştık. Uzaktan erişimde bu rotayı FortiGate, bağlanan her istemci için kendisi ekliyor. İstemci bağlıyken rota tablosu (get router info routing-table all):

...
S       10.60.0.0/24 [10/0] via sube-tunel tunnel 203.0.113.70, [1/0]
S       10.99.0.10/32 [15/0] via uzak-erisim tunnel 10.99.0.10, [1/0]
...

İlk satır şube tünelinin elle yazılan rotası. İkinci satırı kimse yazmadı: istemcinin aldığı 10.99.0.10 adresi, mesafe 15 ile tünele rotalanmış. Bağlantıdan önce tabloda bu satır yoktu. Rotayı ekleyen, tünelin add-route ayarı ve fabrika ayarında açık. show komutu fabrika değerlerini yazmadığı için ayar ancak show full-configuration ile görünüyor:

show full-configuration vpn ipsec phase1-interface uzak-erisim | grep add-route

        set add-route enable

Ayarın ne işe yaradığını görmek için kapatıp istemciyi yeniden bağladım. Tünel kuruldu ve istemci adresini aldı, ama personel ağına attığı on pingin hiçbiri cevap almadı. FortiGate’in tünel özeti paketlerin geldiğini, hiçbirinin geri gitmediğini gösteriyor (get vpn ipsec tunnel summary):

...
'uzak-erisim_0' 203.0.113.75:0  selectors(total,up): 1/1  rx(pkt,err): 10/0  tx(pkt,err): 0/0

Paketin nerede düştüğünü debug flow söylüyor:

2026-10-05 06:43:12 id=20085 trace_id=1 func=print_pkt_detail line=5845 msg="vd-root:0 received a packet(proto=1, 10.99.0.10:7420->10.34.30.10:2048) tun_id=10.99.0.10 from uzak-erisim. type=8, code=0, id=7420, seq=1."
2026-10-05 06:43:12 id=20085 trace_id=1 func=init_ip_session_common line=6024 msg="allocate a new session-000000ce, tun_id=10.99.0.10"
2026-10-05 06:43:12 id=20085 trace_id=1 func=ip_route_input_slow line=2267 msg="reverse path check fail, drop"
2026-10-05 06:43:12 id=20085 trace_id=1 func=ip_session_handle_no_dst line=6110 msg="trace"

Paket kurala varmadan dönüş yolu denetiminde (reverse path check) düştü. FortiGate bir paketi kabul etmeden önce, kaynağına dönen yolun paketin geldiği arayüzden geçip geçmediğine bakıyor. Rota olmayınca 10.99.0.10 için seçilen yol tünel değil, lab’daki 10.0.0.0/8 kara delik rotası oldu. Bu düşüş logda da görünmüyor, nedenini sorun giderme yazımızda ölçmüştük. Ayarı geri açınca on pingin onu da geçti.

Ölçüm sırasında bir yan bulgu çıktı: istemci bağlıyken tünelin add-route ayarını değiştirdiğimde istemcinin tüneli düştü ve yeniden bağlanması gerekti. Uzaktan erişim tünelinde ayar değiştirmeden önce o an bağlı çalışanları hesaba katın.

FortiGate Uzaktan Erişimde Ayrık Tünel: Hangi Trafik Tünelden Geçer?

İstemcinin rota tablosuna tünel yalnız bir satır ekledi:

10.34.30.0/24 via 203.0.113.1 dev ens224 proto static src 10.99.0.10

Personel ağına giden trafik tünele giriyor, geri kalan her şey istemcinin kendi internet bağlantısından çıkıyor. Bunun iki sonucu var:

1. Kazanç: çalışanın internet trafiği kurumun hattını meşgul etmez ve kurumun hattı kesilse bile çalışan internete çıkabilir.
2. Bedel: çalışanın internet trafiği FortiGate’in web filtresinden, antivirüsünden ve loglarından geçmez. NIST’in uyarısı da bu: ele geçirilmiş bir bilgisayar aynı anda hem internete hem tünele bağlıysa saldırgana kurum ağına giden bir yol açar.

Ayrık tüneli kapatmak için ipv4-split-include satırı kaldırılır ve FortiGate’e havuzdan internete çıkan bir kural yazılır. O zaman çalışanın bütün trafiği kurumun güvenlik profillerinden geçer. Hangisinin seçileceği kurumun kararıdır, ama bilerek verilip yazılır.

Aggressive Mode’un Bedeli: Hatta Ne Görünüyor?

Bağlantı kurulurken istemcinin WAN tarafını yakaladım (tcpdump -vv). İlk iki paket aggressive mode’un bütün kimlik değişimi:

10:39:30.622921 IP (tos 0x0, ttl 64, id 57873, offset 0, flags [DF], proto UDP (17), length 520)
    203.0.113.75.500 > 203.0.113.1.500: [bad udp cksum 0x7a53 -> 0x0715!] isakmp 1.0 msgid 00000000 cookie 0349c1bf8e1d0797->0000000000000000: phase 1 I agg:
    ...
    (id: idtype=FQDN protoid=0 port=0 len=12 uzak-dizustu)
    ...
10:39:30.625217 IP (tos 0x0, ttl 64, id 19358, offset 0, flags [none], proto UDP (17), length 624)
    203.0.113.1.500 > 203.0.113.75.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 0349c1bf8e1d0797->ca83fc01f35be25b: phase 1 R agg:
    ...
    (id: idtype=IPv4 protoid=0 port=0 len=4 203.0.113.1)
    (hash: len=32)

İki şey hatta şifresiz duruyor:

1. İstemcinin kimliği: uzak-dizustu ilk pakette düz metin gidiyor. Kimliğe kullanıcının adını ya da bilgisayarın adını koyan bir kurum, bunu hattı dinleyen herkese söylüyor.
2. Anahtardan türetilen hash: FortiGate’in cevabındaki hash alanı, ön paylaşımlı anahtar kullanılarak hesaplanmış bir değer. NIST’in rehberi ön paylaşımlı anahtarın, el sıkışmayı gözleyen birinin sözlük kelimeleriyle çevrimdışı deneyebileceği bir değer bıraktığını yazıyor. Aggressive mode bu değeri ilk cevapta, kimlik doğrulanmadan önce veriyor.

Ana kip (main mode) kimliği şifreli mesajlarda gönderir. IKEv2 de kimliği, anahtar değişiminden sonraki şifreli mesajda gönderir.

Bu saldırıyı lab’da denemedim, ama yakalamada değerin şifresiz durduğu görülüyor. NIST’in IKEv1’de aggressive mode’dan kaçınılmasını istemesinin sebebi bu. Bütün çalışanların bildiği bir ön paylaşımlı anahtar, aggressive mode’la birleşince tek başına koruma olmaktan çıkar. Asıl korumayı kullanıcının kendi kimliği ve iki aşamalı doğrulama sağlar. İki aşamalı doğrulamanın seçeneklerini 2FA yazımızda anlattık.

Örnekteki yolcu kapısında aggressive mode, yolcunun adını kapıda yüksek sesle söylemesi ve görevlinin parolanın ipucunu herkesin duyacağı yerde vermesidir. Main mode’da bu konuşma kapalı bir odada yapılır.

FortiGate Uzaktan Erişim Sorun Giderme: Yanlış Parola

Bağlanamayan kullanıcıda ilk bakılacak yer yine olay logudur. Doğru anahtar ama yanlış parolayla bağlanmayı denedim. FortiGate logu:

date=2026-10-04 time=13:40:37 ... type="event" subtype="vpn" level="error" vd="root" logdesc="Negotiate IPsec phase 1" msg="negotiate IPsec phase 1" action="negotiate" remip=203.0.113.75 locip=203.0.113.1 ... user="uzak-dizustu" ... xauthuser="uzak.test" ... vpntunnel="uzak-erisim" status="failure" result="XAUTH authentication failed"

Log üç şeyi ayrı alanlarda veriyor:

1. İstemcinin kimliği: user="uzak-dizustu".
2. Denenen kullanıcı adı: xauthuser="uzak.test".
3. Sebep: XAUTH authentication failed, yani kullanıcı doğrulaması başarısız.

Ön paylaşımlı anahtar yanlış olsaydı tünel kullanıcı adı sorulmadan, ilk aşamada düşerdi. Bu ayrım arıza bildirimini kısaltır: “parolanızı kontrol edin” ile “VPN profilinizi yeniden yükleyin” farklı cevaplardır. FortiGate’te genel sorun giderme sırasını sorun giderme yazımızda anlattık.

Sonuç: FortiGate Uzaktan Erişimde Sihirbazın Varsayılanı Yetmez

FortiGate’te uzaktan erişim VPN’i sihirbaz birkaç adımda kuruyor. Kurduğu yapı çalışıyor, ama Fortinet’in örneği NIST’in kaçınılmasını istediği iki şeyi, aggressive mode’u ve paylaşılan anahtarı kullanıyor. Lab’da beş şey öne çıktı:

1. Aggressive mode istemcinin kimliğini ve anahtardan türetilen hash’i hatta şifresiz gönderdi.
2. Bağlanan istemci havuzdan adres aldı, ayrık tünel yalnız personel ağının rotasını verdi.
3. FortiGate istemciye dönen rotayı kendisi ekledi. add-route kapatılınca istemcinin paketleri dönüş yolu denetiminde düştü.
4. FortiGate bağlı kullanıcıyı adı, kimliği ve adresiyle gösterdi. Kimlik doğrulanmadan kabul edildi (peer-id-auth: no).
5. Yanlış parolada log kullanıcıyı ve sebebi ayrı alanlarda yazdı.

Örnekteki yolcu kapısı her yolcuya geçici bir kart verir ve yalnız gideceği binaların yolunu açar. Kapının güvenliği ise yolcunun kimliğini kimin duyabildiğine ve hangi binalara girebildiğine bağlıdır. FortiGate’te bu iki karar IKE kipi ile kuraldır. Sıradaki adım rehberin 10. adımı, ikinci internet hattı ve SD-WAN.

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