Lab: Dựng Site-to-Site IPSec VPN Route-based giữa hai FortiGate

1. Liên hệ thực tế

Sau khi nắm lý thuyết ở bài trước, anh Nam mở GNS3 dựng lại đúng kịch bản HQ – Chi nhánh A để luyện tay trước khi làm trên thiết bị thật. Chị Lan dặn: "Đừng chỉ copy lệnh — làm xong bước nào, kiểm tra ngay bước đó bằng diagnose vpn và get router info routing-table all. VPN mà không kiểm tra từng bước, lúc sai không biết sai ở Phase 1, Phase 2 hay routing."

Lab này dựng lại chính xác kịch bản đã học ở bài lý thuyết: hai FortiGate có IP tĩnh, LAN 10.1.0.0/16 (HQ) và 10.2.0.0/16 (Chi nhánh A), kết nối qua Site-to-Site IPsec VPN Route-based.

2. Kiến thức cốt lõi — Các bước thực hành

2.1 Sơ đồ Lab

Yêu cầu môi trường: 2 FortiGate (VM hoặc GNS3/EVE-NG image FortiOS 7.0+), mỗi máy có tối thiểu 2 interface (wan1, internal), 1 PC/Server test ở mỗi LAN để ping kiểm tra end-to-end.

2.2 Bước 1 — Cấu hình Phase 1 + Phase 2 trên FGT-HQ

config vpn ipsec phase1-interface
    edit "vpn-chi-nhanh-a"
        set type static
        set interface "wan1"
        set ike-version 2
        set remote-gw 203.0.113.10
        set authmethod psk
        set psksecret "MatKhauManhCanKy2024!"
        set proposal aes256gcm-prfsha384
        set dhgrp 21
        set dpd on-idle
        set dpd-retryinterval 30
    next
end

config vpn ipsec phase2-interface
    edit "vpn-chi-nhanh-a-p2"
        set phase1name "vpn-chi-nhanh-a"
        set proposal aes256gcm
        set pfs enable
        set dhgrp 21
        set src-subnet 10.1.0.0 255.255.0.0
        set dst-subnet 10.2.0.0 255.255.0.0
    next
end

2.3 Bước 2 — Cấu hình Phase 1 + Phase 2 trên FGT-ChiNhanhA (đối xứng)

config vpn ipsec phase1-interface
    edit "vpn-hq"
        set type static
        set interface "wan1"
        set ike-version 2
        set remote-gw 198.51.100.5
        set authmethod psk
        set psksecret "MatKhauManhCanKy2024!"
        set proposal aes256gcm-prfsha384
        set dhgrp 21
        set dpd on-idle
        set dpd-retryinterval 30
    next
end

config vpn ipsec phase2-interface
    edit "vpn-hq-p2"
        set phase1name "vpn-hq"
        set proposal aes256gcm
        set pfs enable
        set dhgrp 21
        set src-subnet 10.2.0.0 255.255.0.0
        set dst-subnet 10.1.0.0 255.255.0.0
    next
end

⚠️ Điểm dễ sai #1: psksecret phải giống hệt tuyệt đối hai đầu. Nếu gõ tay, nên copy-paste thay vì gõ lại để tránh lệch ký tự.

2.4 Bước 3 — Kiểm tra Phase 1 đã lên chưa

Trên cả hai FortiGate, chạy:

diagnose vpn ike gateway list

Kỳ vọng thấy trạng thái tunnel với status: established (hoặc tương đương tùy phiên bản FortiOS). Nếu không thấy gateway nào xuất hiện, khả năng cao do:

• Sai remote-gw (kiểm tra lại IP public hai đầu)
• Firewall Policy chặn UDP 500/4500 trên interface wan1 (cần Policy WAN → WAN cho phép IPsec, hoặc để mặc định FortiGate tự xử lý IKE ở local-in)
• NAT/Firewall trung gian (router ISP, GNS3 cloud) chưa mở UDP 500/4500 và ESP (protocol 50)

Nếu Phase 1 lên nhưng Phase 2 chưa, chạy tiếp:

diagnose vpn tunnel list

Kiểm tra proxy id — nếu src-subnet/dst-subnet hai đầu không khớp logic (đã học ở bài lý thuyết), Phase 2 sẽ không thể thương lượng thành công.

2.5 Bước 4 — Cấu hình Routing (Static Route + Blackhole Route)

Trên FGT-HQ:

config router static
    edit 1
        set dst 10.2.0.0 255.255.0.0
        set device "vpn-chi-nhanh-a"
    next
    edit 2
        set dst 10.2.0.0 255.255.0.0
        set distance 254
        set blackhole enable
    next
end

Trên FGT-ChiNhanhA (đối xứng, đổi dst thành 10.1.0.0/16 và device thành "vpn-hq").

⚠️ Điểm dễ sai #2: Quên tạo Blackhole Route — lúc demo tắt tunnel để kiểm tra failover, nếu thiếu route này, traffic sẽ lộ ra ngoài qua default route thay vì bị drop an toàn.

Kiểm tra route đã vào bảng định tuyến:

get router info routing-table all

Tìm dòng route tới 10.2.0.0/16 (trên HQ) đi qua interface tunnel, distance mặc định (thường là 10 cho static route thường) — Blackhole Route sẽ chỉ xuất hiện/active khi route chính (qua tunnel) bị rút khỏi bảng do tunnel down.

2.6 Bước 5 — Cấu hình Firewall Policy hai chiều

Trên FGT-HQ:

config firewall address
    edit "LAN-HQ"
        set subnet 10.1.0.0 255.255.0.0
    next
    edit "LAN-ChiNhanh-A"
        set subnet 10.2.0.0 255.255.0.0
    next
end

config firewall policy
    edit 200
        set name "hq-to-chinhanh-a"
        set srcintf "internal"
        set dstintf "vpn-chi-nhanh-a"
        set srcaddr "LAN-HQ"
        set dstaddr "LAN-ChiNhanh-A"
        set action accept
        set schedule "always"
        set service "ALL"
    next
    edit 201
        set name "chinhanh-a-to-hq"
        set srcintf "vpn-chi-nhanh-a"
        set dstintf "internal"
        set srcaddr "LAN-ChiNhanh-A"
        set dstaddr "LAN-HQ"
        set action accept
        set schedule "always"
        set service "ALL"
    next
end

Tạo tương tự (đối xứng, đổi tên address object) trên FGT-ChiNhanhA.

⚠️ Điểm dễ sai #3: Bật nhầm set nat enable trên các Policy này — sẽ làm traffic bị NAT trước khi vào tunnel, khiến bên nhận thấy sai địa chỉ nguồn và không route trả lời được đúng chiều.

2.7 Bước 6 — Kiểm tra end-to-end

Từ PC test ở LAN-HQ (ví dụ 10.1.1.10), ping tới PC test ở LAN-ChiNhanhA (ví dụ 10.2.1.10):

ping 10.2.1.10

Nếu ping thành công, kiểm tra thêm ở FortiGate xem traffic có thật sự đi qua tunnel:

diagnose sniffer packet vpn-chi-nhanh-a 'icmp' 4

Lệnh này sniff packet trên chính tunnel interface — nếu thấy ICMP request/reply xuất hiện ở đây, xác nhận traffic đã đi đúng qua VPN, không phải đi vòng qua đường khác.

Kiểm tra thêm session/SA còn sống:

diagnose vpn tunnel list name vpn-chi-nhanh-a

Chú ý các trường tx pkts/rx pkts phải tăng dần khi có traffic — nếu SA lên nhưng packet counter không tăng, khả năng cao Firewall Policy hoặc routing đang chặn traffic trước khi tới tunnel.

2.8 Bước 7 — Test failover với Blackhole Route

Tạm thời shutdown interface wan1 trên FGT-ChiNhanhA (hoặc rút cáp WAN trong GNS3) để giả lập tunnel down, sau đó kiểm tra lại trên FGT-HQ:

get router info routing-table all

Kỳ vọng: route qua tunnel vpn-chi-nhanh-a biến mất, và route Blackhole (distance 254) trở thành route active duy nhất cho đích 10.2.0.0/16 — nghĩa là traffic tới LAN chi nhánh sẽ bị drop an toàn thay vì rò ra Internet qua default route.

3. Hỏi & Đáp

Ping từ LAN-HQ sang LAN-ChiNhanhA không được, Phase 1 và Phase 2 đều đã established, nên kiểm tra gì tiếp theo?

Kiểm tra theo thứ tự: (1) get router info routing-table all xem route tới LAN đối diện có tồn tại và trỏ đúng tunnel interface; (2) diagnose firewall iprope list hoặc xem log Firewall Policy xem traffic có match đúng Policy hai chiều không; (3) kiểm tra Firewall Policy trên PC/Server test (Windows Firewall, iptables) có chặn ICMP không; (4) dùng diagnose sniffer packet trên interface internal và trên tunnel interface để xác định traffic dừng lại ở đâu trong pipeline.

Vì sao Lab yêu cầu dùng diagnose sniffer packet trên chính tunnel interface thay vì trên wan1?

Sniff trên wan1 sẽ thấy traffic đã được đóng gói ESP (mã hóa), không đọc được nội dung ICMP bên trong. Sniff trên tunnel interface (vpn-chi-nhanh-a) cho thấy traffic ở dạng đã giải mã/trước khi mã hóa — đúng lớp cần kiểm tra để xác nhận Policy và routing đang hoạt động đúng.

Nếu trong Lab dùng GNS3/EVE-NG mà Phase 1 không bao giờ lên được, cần kiểm tra gì đặc thù cho môi trường ảo?

Kiểm tra cloud/switch node trung gian trong topology có filter UDP 500/4500 hoặc ESP (protocol 50) không; kiểm tra MTU giữa các node ảo (một số bridge ảo mặc định MTU thấp gây fragment IKE packet); và đảm bảo đồng hồ hệ thống (clock) của hai FortiGate không lệch quá nhiều vì lệch giờ có thể ảnh hưởng tới việc xác thực certificate (nếu dùng authmethod khác PSK).

4. Quiz

Câu 1: Lệnh nào dùng để kiểm tra Phase 1 (IKE gateway) đã established hay chưa?

• A. get router info routing-table all
• B. diagnose vpn ike gateway list
• C. diagnose sniffer packet
• D. get system status

Câu 2: Trong Lab, vì sao nên sniff packet trên tunnel interface thay vì trên wan1 để kiểm tra traffic ICMP?

• A. Vì wan1 không hỗ trợ lệnh sniffer
• B. Vì trên tunnel interface traffic ở dạng chưa/đã mã hóa ESP nên không đọc được nội dung ICMP
• C. Vì trên tunnel interface thấy traffic ở lớp đã giải mã, còn trên wan1 traffic đã đóng gói ESP nên không đọc được nội dung
• D. Không có khác biệt giữa hai vị trí sniff

Câu 3: Ở bước test failover, sau khi tắt WAN của FortiGate chi nhánh, kỳ vọng gì xảy ra trong routing-table của FGT-HQ nếu đã cấu hình đúng Blackhole Route?

• A. Route qua tunnel vẫn còn nguyên, không đổi gì
• B. Route qua tunnel biến mất, Blackhole Route (distance 254) trở thành route active để drop traffic an toàn
• C. FortiGate tự động tạo tunnel backup khác
• D. Toàn bộ routing-table bị xóa

Câu 4: Nếu tx pkts/rx pkts trong diagnose vpn tunnel list không tăng dù SA đã established và có traffic gửi đi, nguyên nhân nhiều khả năng nhất là gì?

• A. Phase 1 bị sai proposal
• B. Firewall Policy hoặc routing đang chặn traffic trước khi tới được tunnel interface
• C. psksecret sai
• D. dhgrp không khớp giữa hai đầu

👉 Đáp án

Câu 1: B diagnose vpn ike gateway list hiển thị trạng thái các IKE gateway (Phase 1), cho biết tunnel đã established hay chưa.

Câu 2: C Tunnel interface cho thấy traffic ở lớp đã giải mã/trước khi mã hóa (đúng nội dung ICMP), trong khi wan1 chỉ thấy gói ESP đã đóng gói, không đọc được nội dung bên trong.

Câu 3: B Khi route chính qua tunnel bị rút khỏi bảng định tuyến do tunnel down, Blackhole Route (distance cao hơn, ở đây 254) trở thành route active duy nhất, khiến traffic tới đích bị drop an toàn thay vì lộ ra ngoài qua route khác.

Câu 4: B SA established chỉ xác nhận tunnel đã lên ở lớp IPsec; nếu Firewall Policy hoặc routing tĩnh chặn/định tuyến sai trước khi traffic tới tunnel interface, packet counter trên tunnel sẽ không tăng dù tunnel vẫn "sống".

📚 Bài Lab thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng