Đã Cấu Hình NAT Static Và ACP Trên Cisco FTD Nhưng Traffic Không Chạy - Đây là cách khắc phục!

[Haiduong]

Nếu bạn đang làm việc với Cisco Firepower Threat Defense (FTD) qua Firepower Management Center (FMC), chắc hẳn bạn đã từng gặp tình huống này: Bạn cấu hình NAT static để Cách Chọn Zone Cho NAT Và ACP thêm Access Control Policy (ACP) để cho phép traffic inbound, nhưng... chẳng có gì xảy ra. User từ bên ngoài không thể truy cập server, log thì im lìm, và bạn ngồi dHãy tưởng tượng bạn đang xây một ngôi nhà: NAT static giống như "cửa chính" để khách bên ngoài (Internet) vào nhà (server nội bộ), còn ACP là "bảo vệ" kiểm tra vé vào cửa. Nhưng nếu bảo vệ kiểm tra sai vị trí, khách sẽ bị chặn ngay từ ngoài cổng!

Tôi từng mắc phải lỗi này, tôi nhận ra đây là một "bẫy" phổ biến mà hàng ngàn admin gặp phải. Hôm nay, tôi viết bài blog này để chia sẻ sâu sắc về vấn đề, giúp bạn tránh mất thời gian và hiểu rõ hơn về "cơ chế ngầm" của FTD. Hãy cùng khám phá!

---

1. Tại Sao Đây Là Lỗi Phổ Biến?
Hãy tưởng tượng bạn đang xây một ngôi nhà: NAT static giống như "cửa chính" để khách bên ngoài (Internet) vào nhà (server nội bộ), còn ACP là "bảo vệ" kiểm tra vé vào cửa. Nhưng nếu bảo vệ kiểm tra sai vị trí, khách sẽ bị chặn ngay từ ngoài cổng!

Lỗi phổ biến nhất:

• Trong ACP rule cho traffic inbound (outside → inside), nhiều người dùng IP public (pre-NAT) trong Destination Networks, thay vì IP private (post-NAT) của server.

-> Kết quả? Rule không match, traffic bị drop bởi default deny.

---

2. Hiểu Sâu Về Quy Trình Xử Lý Gói Tin Trên FTD

Để sửa lỗi, bạn phải nắm rõ "luồng máu" của FTD. FTD xử lý gói tin theo thứ tự nghiêm ngặt (theo Cisco Firepower Management Center Configuration Guide, version 7.x+):

1. Ingress Interface (Outside): Gói tin đến từ Internet, ví dụ:
   • Source: 8.8.8.8 (client IP)
   • Destination: 203.0.113.50 (public IP, port 80)
2. NAT Untranslation: NAT static dịch destination IP từ public sang private.
   • Post-NAT: Destination trở thành 192.168.1.10 (server IP, port 80)
3. ACP Check: FTD áp dụng ACP rule trên post-NAT packet. Lúc này, gói tin đã thay đổi:
   • Destination: 192.168.1.10 (không còn là 203.220.113.50)
4. Routing & Egress: Nếu ACP cho phép, gói tin được routed đến server qua interface inside.

Key insight: ACP match post-NAT IPs, không phải pre-NAT. Nếu bạn dùng IP public trong ACP Destination Networks, rule sẽ không match!

---

3. Cách Chọn Zone và Network Cho NAT Và ACP

Ở bước này tôi sẽ giả định trường hợp NAT static để expose server nội bộ ra internet.

Một phần quan trọng bị bỏ qua là cách chọn zone trong NAT và ACP. Lựa chọn sai zone có thể khiến traffic bị chặn ngay từ đầu.

Dưới đây là hướng dẫn chi tiết:

Chọn Zone và Network Trong NAT

• Source Zone: Chọn zone chứa interface của server nội bộ (ví dụ: inside).
• Destination Zone: Chọn zone chứa interface public (ví dụ: outside).
• Source Network : Chọn object network hoặc object group chứa các IP private của server
• Destination Network : Chọn object network chứa public IP của server
  
• Ví dụ: Trong NAT rule, nếu server ở interface inside (zone inside), và public IP trên interface outside (zone outside), bạn chọn:
  • Source Zone: inside
  • Destination Zone: outside
  • Source Network: IP private của server (ví dụ: 192.168.1.1)
  • Destination Network: IP Public của server ( ví dụ: 122.122.12.2)
    
• Tại sao chọn vậy?: Zone trong NAT định nghĩa luồng traffic (inside → outside), trong khi network zone đảm bảo NAT chỉ áp dụng cho các IP cụ thể, tránh conflict với routing hoặc các rule khác. Sự kết hợp này giúp NAT hoạt động chính xác và hiệu quả.

Chọn Zone Trong ACP

• Source Zone: Chọn outside (nơi traffic đến từ Internet).
• Destination Zone: Chọn inside (nơi server nội bộ nằm).
• Source Network : Chọn any hoặc object network chứa các IP nguồn bên ngoài
• Destination Network : Chọn object network hoặc object group chứa các IP private của server
• Ví dụ: Với rule ALLOW_ONLY_WWW_FROM_ANY_TO_LOCALSERVER:
  • Source Zone: outside
  • Destination Zone: inside
  • Source Network: any (cho phép mọi nguồn)
  • Destination Network: Ở đây phải là IP Private của server ( ví dụ: 192.168.1.1)
• Tại sao chọn vậy?: Zone trong ACP match luồng post-NAT (outside → inside), đảm bảo rule kiểm tra đúng interface đích sau khi dịch IP.

---

4. Cách Debug và Verify

Đừng đoán mò! Sử dụng công cụ:

• Packet-Tracer: packet-tracer input outside tcp 8.8.8.8 12345 122.122.12.2 80 detailed (trên FTD CLI). Kiểm tra NAT phase (dịch IP) và ACP phase (match rule với private IP).
• Show NAT & Show Xlate: Xem translations active.
• Logging: Bật log trong ACP rule để xem hit count.
• Test: Từ ngoài Internet, curl http://IP_Public_Server. Nếu fail, kiểm tra log.

---

5. Những lưu ý trước khi cấu hình

• Hiểu Flow: Luôn nhớ NAT trước ACP cho inbound static NAT.
• Object Groups: Dùng groups như Internal_Web_Servers để cover nhiều server trong 1 rule, giữ ACP gọn.
• Stateful Nature: Không cần rule outbound reply – FTD tự xử lý.
• Tối ưu Security: Chỉ cho phép ports cần thiết (80/443), thêm IPS/File Policy trong ACP.
• Update FMC/FTD: Version 7.4+ có giao diện tốt hơn, ít bug.
• Thực hành Lab: Sử dụng EVE-NG hoặc GNS3 để test trước production.

---

📌Kết Luận:

Lỗi này tuy nhỏ nhưng có thể khiến bạn mất hàng giờ debug, đặc biệt nếu bạn chuyển từ ASA sang FTD. Hãy nhớ: ACP match post-NAT IP – private cho inbound! Việc chọn đúng zone trong NAT (inside → outside) và ACP (outside → inside) là chìa khóa để tránh nhầm lẫn. Nếu bạn đang gặp vấn đề tương tự, thử kiểm tra ngay Source/ Destination Networks và Zone trong ACP.