Firewall HA Failover เกิดอะไรขึ้นบ้างในไม่กี่วินาทีที่สลับเครื่อง

ไฟร์วอลล์ HA pair ควรเป็นของที่ไม่มีใครต้องนึกถึง จนกระทั่งวันที่ตัว active ไฟดับ, link ที่ monitor อยู่หลุด หรือมีคนเริ่ม upgrade แล้วทุกคนก็อยากรู้ว่าทำไมสาย VoIP หลุด ทำไม session ที่ถูก decrypt ถูก reset หรือทำไม core switch ยังส่ง frame ไปหากล่องที่ตายไปแล้วอยู่พักหนึ่งครับ

นี่คือบันทึกภาคสนามของผมว่าระหว่าง failover เกิดอะไรขึ้นจริง ๆ ครับ พยายามเขียนแบบไม่ยึดติดยี่ห้อเท่าที่ทำได้ โดยวางศัพท์ของ Palo Alto Networks (PAN-OS), Fortinet (FortiGate, FGCP) และ Cisco Secure Firewall Threat Defense (FTD) ไว้คู่กัน และทุกพฤติกรรมของแต่ละ vendor มีลิงก์ไปยังเอกสารของ vendor นั้นเอง ค่า default เปลี่ยนได้ในแต่ละ release ให้ถือตัวเลขในนี้เป็นจุดเริ่มต้น แล้วตรวจกับเอกสารของเวอร์ชันที่ใช้งานจริงเสมอครับ

                      ┌──────────────────┐                      
                      │  UPSTREAM SWITCH │                      
                      └──────────────────┘                      
                        //■          \\\                        
                    //■/                \\\\                    
                //■/                        \\\\                
             /■/                                \\\             
    ┌────────────────┐                    ┌────────────────┐    
    │      FW-A      │                    │      FW-B      │    
    │     ACTIVE     │•············•······│     PASSIVE    │    
    │     ▪  ·  ·    │    HA heartbeat    │     ·  ▪  ▪    │    
    └────────────────┘                    └────────────────┘    
             \■\\         steady state         ////             
                 \■\\\\                  ■/////                 
                      ┌──────────────────┐                      
                      │        LAN       │                      
                      └──────────────────┘                      
                                                                

บันทึกที่ 1: ส่วนใหญ่เลือก active/passive และ vendor ก็อธิบายเหตุผลไว้เอง

ทั้งสามเจ้าทำ pair ที่ตัวหนึ่งส่ง traffic อีกตัวรออยู่ได้ สองเจ้ามี active/active ให้ด้วย แต่ควรอ่านรายละเอียดก่อนเลือก:

• Palo Alto รองรับทั้งสองโหมด เอกสารเปรียบเทียบของเขาเองบอกว่า active/passive ออกแบบง่ายกว่าและ troubleshoot เรื่อง routing กับ traffic flow ได้ง่ายกว่า ส่วน active/active ไม่ได้ load-balance ให้เอง ต้องใช้ ECMP, ISP หลายเจ้า หรือ load balancer ช่วยกระจาย และตัวที่เหลืออยู่ต้องรับ peak load ได้ทั้งที่เปิด content inspection อยู่ (PAN-OS: HA Modes) ส่วน VM-Series บน AWS และ Azure รองรับเฉพาะ active/passive (PAN-OS: High Availability)
• FortiGate cluster แบบ FGCP ทำได้ทั้ง active-passive และ active-active โดยสมาชิกทุกตัวต้องเป็นรุ่นเดียวกัน firmware เดียวกัน และ hardware configuration เหมือนกัน (FortiOS 7.6: FGCP)
• Cisco FTD ที่จัดการด้วย Management Center มีเอกสารเรื่อง active/standby failover สำหรับ HA pair ซึ่งตัวหนึ่งส่ง traffic อีกตัวไม่ส่ง (FMC 7.4: High Availability for FTD)

ประเด็นที่ผมวนกลับมาคิดเสมอคือ active/active ช่วยได้ก็ต่อเมื่อแต่ละตัวรับโหลดทั้งหมดได้คนเดียว ถ้ารับไม่ไหว ความเสียหายของตัวหนึ่งจะกลายเป็นอาการโหลดล้น ไม่ใช่ failover ครับ

บันทึกที่ 2: link สองแบบ ทำงานคนละหน้าที่

ทุกดีไซน์ HA มี link ที่ตอบคำถามว่า "peer ยังมีชีวิตอยู่ไหม และอยู่ในสถานะอะไร" กับ link ที่ตอบว่า "ตอนนี้ peer กำลังทำอะไรอยู่" แต่ละ vendor ตั้งชื่อต่างกัน:

รายละเอียดที่ควรรู้:

• PAN-OS HA1 ขน hello, heartbeat, HA state, การ sync routing และ User-ID รวมถึง configuration โดย heartbeat เป็น ICMP ส่วน HA2 sync session, forwarding table, IPsec security association และ ARP table ไหลทางเดียวจาก active ไป passive ผ่าน Ethernet (EtherType 0x7261 เป็นค่า default), IP หรือ UDP (PAN-OS: HA Links and Backup Links)
• FGCP heartbeat เป็น Layer 2 frame ที่มี EtherType ของตัวเอง: 0x8890 สำหรับ heartbeat, 0x8892 สำหรับ session sync บน interface ที่แยกไว้ และ 0x8893 สำหรับ configuration sync Fortinet แนะนำให้ต่อ cluster สองตัวแบบ back-to-back และแยก heartbeat ออกจากเครือข่ายผู้ใช้ เพราะมีรายละเอียด configuration ของ cluster อยู่ข้างใน (FortiOS 7.6: HA heartbeat interface) การ sync configuration วิ่งบน heartbeat link ด้วย TCP/703 และ UDP/703 (FGCP)
• Failover link ของ FTD ขน unit state, hello, link status, การแลกเปลี่ยน MAC address และ configuration replication ส่วน state link เป็น optional แต่จำเป็นถ้าต้องการ stateful failover โดย Cisco แนะนำ latency ต่ำกว่า 10 ms และไม่เกิน 250 ms (FMC 7.4 HA)

Split brain คือความเสียหายที่ทุกคนกลัว: ทั้งสองตัวคิดว่าตัวเองเป็น active และตอบในนาม IP กับ MAC address เดียวกัน Fortinet อธิบายสถานการณ์นี้ไว้ตรง ๆ และมี backup heartbeat interface ไว้ป้องกัน (HA heartbeat interface) ส่วน Cisco ระบุว่าถ้า failover link ของ FTD down ตอนเปิดเครื่อง ทั้งสองตัวจะขึ้นเป็น active (FMC 7.4 HA) control link สำรองจึงเป็นประกันที่ราคาถูกมากครับ

บันทึกที่ 3: ต้องใช้เวลานานแค่ไหนกว่าจะตัดสินว่า "ตาย"

เวลาในการตรวจจับคือการแลกกันระหว่างความเร็วกับ false alarm และค่า default ของแต่ละ vendor ไม่เท่ากัน ซึ่งมักทำให้คนที่สลับไปมาระหว่างยี่ห้อแปลกใจ:

• PAN-OS: heartbeat ทุก 1,000 ms เป็นค่า default และหายติดกันสามครั้งจะ trigger failover (PAN-OS: Failover) จากนั้นตัว passive รอ promotion hold time ก่อนขึ้นเป็น active: 2,000 ms ในโปรไฟล์ timer แบบ "Recommended" และ 500 ms ในแบบ "Aggressive" (PAN-OS: HA Timers)
• FortiGate: heartbeat ทุก 2 × 100 ms และหาย 20 ครั้งถือว่าสมาชิกตาย ค่า default จึงอยู่ราว 4 วินาที การลด interval หรือใช้หน่วย 10 ms บนรุ่นที่รองรับจะได้ต่ำกว่าหนึ่งวินาที (HA heartbeat interface; Failover protection)
• FTD: เมื่อไม่ได้รับ hello บน failover link สามครั้งติดกัน ตัวอุปกรณ์จะส่งข้อความทดสอบออกทาง interface อื่น และตัว standby จะขึ้นเป็น active ก็ต่อเมื่อไม่มี interface ใดได้รับคำตอบเลย ค่า default ของเวลาตรวจจับตัว active ที่เสียคือ 15 วินาที ตั้งได้ตั้งแต่ 800 ms ถึง 45 วินาที (FMC 7.4 HA)

เร็วกว่าไม่ได้แปลว่าดีกว่าเสมอ control plane ที่ยุ่งจนพลาด hello ไม่กี่ครั้งอาจ trigger failover ที่ก่อความวุ่นวายมากกว่า "ปัญหา" ที่มันตอบสนองครับ ตัวอย่างเช่น Cisco พูดถึง heartbeat ผ่าน data plane เพื่อช่วยกัน false failover ตอนที่ control plane แออัด (หน้าเดียวกัน)

บันทึกที่ 4: session sync เป็นตัวตัดสินว่าผู้ใช้จะรู้สึกอะไร

failover ที่เก็บ session table ไว้ได้เรียกว่า "stateful" คือ connection เดิมวิ่งต่อบนตัว active ใหม่ได้ แต่ไม่ใช่ทุกอย่างจะอยู่ใน table นั้นครับ

 ACTIVE ●                               STANDBY ●               
 session table            HA data link  session table           
 ───────────────────────  ────════────► ─────────────────────── 
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
                                                                
 ───────────────────────                ─────────────────────── 

สิ่งที่รอด โดยคร่าว ๆ แยกตาม vendor:

• Palo Alto sync session, forwarding table, IPsec SA และ ARP table ผ่าน HA2 (HA Links) แต่เอกสารระบุว่าหลัง failover ไฟร์วอลล์ไม่รองรับ HA sync สำหรับ decrypted SSL session (PAN-OS: Reference: HA Synchronization)
• FortiGate: session pickup ไม่ได้เปิดเป็นค่า default (Session failover) เมื่อเปิด session-pickup แล้ว TCP session จะ sync ส่วน UDP และ ICMP ต้องเปิด session-pickup-connectionless เพิ่ม และ Fortinet ชี้ว่า QUIC (HTTP/3) ก็ต้องใช้ค่านี้ด้วย (Session pickup) session ที่ตรวจด้วย proxy-based profile จะไม่ failover ส่วนแบบ flow-based failover ได้แต่จะไม่ถูกตรวจอีกหลังจากนั้น (Pass-through sessions) management session ที่เข้าตัวไฟร์วอลล์ต้องเริ่มใหม่ ขณะที่ IPsec SA ถูก sync (Terminated sessions)
• Cisco FTD replicate NAT translation, TCP และ UDP connection, Snort connection state, ARP table, IPsec SA และ routing table เป็นต้น แต่ ไม่ replicate DHCP lease, multicast routing, connection ที่ยังเป็น embryonic หรืออายุสั้น และ decrypted TLS connection ซึ่งจะถูก reset (FMC 7.4 HA)

รูปแบบที่เห็นตรงกันทั้งสามเจ้า: flow ที่แค่ forward ผ่านมักรอด ส่วนอะไรก็ตามที่ไฟร์วอลล์ต้องถือ state ต่อ session ไว้เยอะ (decryption, proxy) มักไม่รอด ถ้า traffic ที่ถูก decrypt สำคัญกับธุรกิจ ควรพูดให้ชัดก่อน planned failover ไม่ใช่หลังจากนั้นครับ

บันทึกที่ 5: เครือข่ายต้องรับรู้ว่าไฟร์วอลล์ย้ายที่แล้ว

switch ส่ง frame ตาม MAC address ถ้าตัว active ใหม่ตอบด้วย MAC คนละตัว อุปกรณ์รอบข้างทุกตัวต้องอัปเดต ARP cache HA pair จึงย้าย IP และ MAC address ของตัว active (ส่วนใหญ่เป็น virtual MAC) ไปพร้อมบทบาท active และตัว active ใหม่จะส่ง gratuitous ARP ให้ switch เรียนรู้ใหม่ว่า MAC นั้นอยู่ที่ port ไหนครับ

แนวคิดเดียวกับ VRRP ซึ่งเป็นโปรโตคอลมาตรฐานด้าน first-hop redundancy โดยสเปก VRRPv3 ฉบับปัจจุบันคือ RFC 9568 (ปี 2567 ใช้แทน RFC 5798) กำหนด virtual router MAC เป็น 00-00-5E-00-01-{VRID} สำหรับ IPv4 (section 7.3) ให้ backup ที่ขึ้นมารับหน้าที่ broadcast gratuitous ARP (section 6.4.2) และให้ backup ถือว่า router ตัว active ตายหลัง (3 × Active_Adver_Interval) + Skew_Time โดย Active_Adver_Interval คือ interval ที่ตัว active ประกาศมา ส่วน advertisement interval default คือหนึ่งวินาที (section 6.1) ซึ่ง RFC 5798 ใช้ค่าเดียวกันแต่เรียกด้วยชื่อเดิมว่า "Master"

รายละเอียดฝั่งไฟร์วอลล์:

• FortiGate: หลัง failover interface ของ primary ตัวใหม่จะมี virtual MAC และ IP address เดียวกับ primary ตัวที่เสีย ส่ง gratuitous ARP 5 ครั้งเป็นค่า default ห่างกัน 8 วินาที (arps, arps-interval) และ link-failed-signal ปิด interface ชั่วครู่เพื่อบังคับให้ switch ตอบสนองถ้า GARP ไม่พอ cluster ที่อยู่ใน broadcast domain เดียวกันควรใช้ group ID ไม่ซ้ำกัน ไม่อย่างนั้น virtual MAC จะชนกัน (Cluster virtual MAC addresses)
• Palo Alto: หน้าเอกสารที่อธิบายเรื่องนี้พูดถึง floating IP address ใน Layer 3 active/active HA โดยระบุว่าเมื่อไฟร์วอลล์ตัว active ใหม่รับหน้าที่ จะส่ง gratuitous ARP ออกทุก interface ที่ต่ออยู่ เพื่อบอก Layer 2 switch ว่า virtual MAC ย้ายไปอยู่ที่ไหน (Floating IP Address and Virtual MAC Address)
• Cisco FTD: ตัว active ใหม่รับ active IP และ MAC address ไปใช้ ถ้าตัว secondary บูตขึ้นมาก่อน มันจะเป็น active ด้วย MAC ของตัวเอง เพราะไม่รู้ MAC ของ primary Cisco จึงแนะนำให้ตั้ง virtual MAC บนทั้งสองตัว นอกจากนี้ FTD ไม่ส่ง gratuitous ARP สำหรับ static NAT address เมื่อ MAC เปลี่ยน (FMC 7.4 HA)

สิ่งที่ผมเช็กตรงนี้ง่ายมาก: ก่อนทดสอบ ให้รู้ว่าทั้งสองตัวต่อกับ switch port ไหน แล้วดู MAC address table บน upstream switch ระหว่าง failover ถ้า MAC ไม่ย้าย ปัญหาไม่ได้อยู่ที่ไฟร์วอลล์ครับ

บันทึกที่ 6: monitoring, preemption และอาการ flapping

heartbeat พิสูจน์ได้แค่ว่า peer ยังมีชีวิต ส่วน link monitoring และ path monitoring พิสูจน์ว่ามันยังทำงานได้:

• link group และ path group ของ PAN-OS ให้เลือกว่าต้องเสียแค่บางตัว (any) หรือทั้งหมด (all) path monitoring ping ทุก 200 ms เป็นค่า default และถือว่าปลายทางเข้าไม่ถึงหลังพลาด 10 ครั้ง (PAN-OS: Failover)
• FortiGate failover เมื่อ monitored interface เสีย, ไฟดับ และเลือกเปิดได้สำหรับ SSD เสียหรือใช้ memory สูงต่อเนื่อง (Failover protection)
• FTD monitor named physical interface เป็นค่า default และ failover เมื่อจำนวน interface ที่เสียถึง threshold ของ policy (ค่า default คือ interface เสียเพียงตัวเดียวก็ failover), เมื่อ Snort instance ล่มเกิน 50% หรือเมื่อใช้ disk เกิน 90% ส่วน standby ที่เสียหรือ failover link ที่เสียจะไม่ทำให้เกิด failover (FMC 7.4 HA)

Preemption ตัดสินว่าตัวที่ "ต้องการให้เป็นหลัก" จะดึงบทบาท active กลับเมื่อฟื้นหรือไม่ ทุกครั้งที่ failback คือ failover อีกหนึ่งครั้ง จึงควรเลือกอย่างตั้งใจ:

• PAN-OS: เลข priority ต่ำกว่าชนะ preemption ปิดเป็นค่า default และต้องเปิดบนไฟร์วอลล์ทั้งสองตัว (Device Priority and Preemption) timer Flap Max (default 3) จะ suspend ตัวที่เด้งไปมาไม่หยุด โดยนับเป็น flap เมื่อตัวที่เปิด preemption หลุดจาก active ภายใน 20 นาที หรือ link/path อยู่ไม่ถึง 10 นาที (HA Timers)
• FortiGate: priority สูงกว่าชนะ (0–255, default 128) แต่ถ้า override ปิดอยู่ (ค่า default) จะเทียบ uptime ก่อน priority โดยมี margin 300 วินาที และ monitored interface ที่เสียจะ reset uptime ของตัวนั้น เอกสาร Fortinet เรียกลำดับสองแบบนี้ว่า MUPS และ MPUS: monitored interfaces, uptime, priority, serial number (HA primary unit selection criteria)
• Cisco FTD แบบ active/standby: ตัวที่เคยเป็น active เมื่อฟื้นจะกลับมาเป็น standby ไม่ได้ดึงบทบาทคืน (FMC 7.4 HA)

บันทึกที่ 7: เช็กก่อน change และการทำ manual failover อย่างปลอดภัย

ก่อนจะแตะ pair ใน change window นี่คือรายการที่ผมอยากตอบได้ว่า "ใช่" ทุกข้อ:

1. ทั้งสองตัวปกติและ sync กันอยู่ รุ่นเดียวกัน PAN-OS เวอร์ชันเดียวกัน ฐานข้อมูล application, URL และ threat เป็นปัจจุบัน และ license ตรงกัน ซึ่ง Palo Alto ระบุเป็น prerequisite (Set Up Active/Passive HA) และทั้งสองตัวรายงานว่า configuration sync กันอยู่
2. session sync ไหลอยู่จริง คู่มือ upgrade ของ Palo Alto ยืนยันเรื่องนี้ด้วยการดูว่า hardware counter ของ HA2 เพิ่มขึ้น (show high-availability interface ha2) (Upgrade an HA Firewall Pair)
3. รู้ว่าอะไรจะถูก reset session ที่ถูก decrypt, session ที่ตรวจผ่าน proxy และ traffic แบบ connectionless ถ้าไม่ได้ sync (บันทึกที่ 4)
4. มีแผนถอยกลับที่ไม่ขึ้นกับสิ่งที่กำลังทดสอบ เช่น console access และคำสั่งที่ทำให้ตัวเดิมกลับมาเป็น active

จากนั้นใช้ controlled failover ของ vendor เอง ไม่ใช่ดึงสาย:

• PAN-OS: Device > High Availability > Operational Commands > Suspend local device ยืนยันว่า peer ขึ้นเป็น active แล้วกด Make local device functional (Verify Failover or Suspend HA)
• FortiGate: execute ha failover set 1 และ execute ha failover unset 1 เพื่อยกเลิก Fortinet ระบุว่าใช้สำหรับทดสอบและงาน maintenance และควรใช้ใน maintenance window เท่านั้น (Force HA failover)
• Cisco FTD: Switch Active Peer ในหน้า Devices > Device Management ของ Management Center หลังจาก refresh สถานะของ pair ให้ Management Center ตรงกับตัวอุปกรณ์ก่อน (FMC 7.4 HA)

ระหว่างทดสอบ ผมดูสามอย่าง: HA state บนทั้งสองตัว, MAC table ของ upstream switch และ session ทดสอบที่อยู่นานหนึ่ง session (SSH ผ่านไฟร์วอลล์ก็พอ) เพื่อดูว่ามันรอดไหมครับ

บันทึกที่ 8: upgrade HA pair มักพลาดตรงไหน

upgrade คือช่วงที่ HA ถูกใช้งานหนักที่สุด เพราะแต่ละตัวต้อง reboot โดยตั้งใจครับ

• preemption ทำงานสวนทาง ขั้นตอนของ Palo Alto เริ่มจากปิด preemption บน peer หนึ่งตัว แล้ว suspend และ upgrade ทีละตัว จากนั้นเปิด preemption กลับตอนท้าย และเตือนว่าถ้า peer ห่างกันตั้งแต่สอง feature release ขึ้นไป ตัวที่เก่ากว่าจะเข้าสถานะ suspended พร้อมข้อความ "Peer version too old" (Upgrade an HA Firewall Pair)
• เดาลำดับเอาเอง uninterrupted upgrade ของ FortiGate จะ upgrade ตัว subordinate ก่อน เลือก primary ใหม่จากตัวที่ upgrade แล้ว จากนั้นจึง upgrade primary เดิม cluster อาจจบที่ primary คนละตัวกับตอนเริ่ม และยังเตือนว่าการเปลี่ยนค่าใน CLI ที่ต้อง reboot อาจทำให้สมาชิกทุกตัว reboot พร้อมกัน (Upgrading FortiGates in an HA cluster)
• ลืมว่าบทบาทสลับกันแล้ว บทความของ Cisco TAC อธิบายว่า FMC upgrade ตัว standby ก่อน แล้ว failover ก่อนจะ upgrade ตัว active เสร็จ และแนะนำให้สลับกลับเพื่อให้ primary เป็น active เหมือนเดิม (Cisco: Upgrade FTD HA managed by FMC) บทความนี้เขียนบน release ที่เก่ากว่า จึงควรตรวจกับ guide ของเวอร์ชันที่ใช้อยู่

ทั้งหมดนี้ไม่ใช่เรื่องพิสดารครับ HA failover ส่วนใหญ่ทำให้คนแปลกใจก็เพราะค่า default (เวลาตรวจจับ, session pickup, preemption) ไม่เคยถูกเลือกอย่างตั้งใจ อ่านมันสักครั้ง จดไว้ข้าง ๆ pair นั้น แล้วไม่กี่วินาทีของ failover ก็จะกลายเป็นเรื่องน่าเบื่อ ซึ่งคือเป้าหมายพอดีครับ

แหล่งอ้างอิง

• Palo Alto Networks: High Availability (PAN-OS 11.1)
• Palo Alto Networks: HA Modes
• Palo Alto Networks: HA Links and Backup Links
• Palo Alto Networks: Failover
• Palo Alto Networks: HA Timers
• Palo Alto Networks: Device Priority and Preemption
• Palo Alto Networks: Floating IP Address and Virtual MAC Address
• Palo Alto Networks: Reference: HA Synchronization (PAN-OS 11.1)
• Palo Alto Networks: Set Up Active/Passive HA
• Palo Alto Networks: Verify Failover or Suspend HA (PAN-OS)
• Palo Alto Networks: Upgrade an HA Firewall Pair (PAN-OS 11.1)
• Fortinet: FGCP (FortiOS 7.6)
• Fortinet: HA heartbeat interface
• Fortinet: Failover protection
• Fortinet: Session failover
• Fortinet: Session pickup
• Fortinet: Pass-through sessions
• Fortinet: Terminated sessions
• Fortinet: Cluster virtual MAC addresses
• Fortinet: HA primary unit selection criteria
• Fortinet: Force HA failover for testing and demonstrations
• Fortinet: Upgrading FortiGates in an HA cluster
• Cisco: High Availability for Firewall Threat Defense (Management Center 7.4)
• Cisco TAC: Upgrade FTD HA Managed by FMC
• RFC 9568: Virtual Router Redundancy Protocol (VRRP) Version 3
• RFC 5798: VRRP Version 3 (obsoleted by RFC 9568)