Back
Lesson 5 of 7

FTD Interface Configuration

Objective

In this lesson you will configure routed interfaces, security zones, and interface groups on a Cisco Secure Firewall (FTD) device. You will build an Inside/Outside/DMZ interface layout, create a public-to-private NAT mapping for a web application (port 20000 -> HTTPS), and apply an access control to permit the mapped traffic. This matters in production because correct interface and zone configuration enforces trust boundaries, allows precise NAT and policy application, and prevents accidental exposure of internal services. Real-world scenario: publishing an internally hosted HTTPS application (lab.nhprep.com) to the Internet while keeping the server on a private subnet behind the firewall.

Quick Recap

Reference topology (from Lesson 1) is being extended. The only new IPs in this lesson are the inside and DMZ interfaces and the internal web server IP required for NAT. The Outside interface IP from the reference is used exactly as provided.

ASCII Topology (interfaces and IPs shown exactly):

Internet
   |
   | 203.0.113.2/24 (Outside)
   |
[FTD1]
   | Outside (nameif outside) 203.0.113.2/24
   | Inside  (nameif inside)  192.168.1.1/24
   | DMZ     (nameif dmz)     10.0.0.1/24
   |
   +-- 192.168.1.10 (Web server: lab.nhprep.com)

Device Table

DeviceRoleInterface / HostnameIP Address
FTD1Firewalloutside203.0.113.2/24
FTD1Firewallinside192.168.1.1/24
FTD1Firewalldmz10.0.0.1/24
WebSrvApplication Servereth0192.168.1.10/32 (lab.nhprep.com)

Important: The external/public IP used by the firewall is exactly 203.0.113.2 as shown in the reference material. The internal server is 192.168.1.10 and will be the NAT target.

Key Concepts (theory + what happens on the wire)

  • Routed Interfaces & Nameif: Each FTD interface is configured as a routed interface with a name (e.g., outside, inside). The interface IP is the firewall's L3 address for that segment. Packets are forwarded between interfaces only when security policies and NAT permit.
    • Protocol behavior: when an inbound TCP SYN arrives on the outside interface, the firewall performs NAT and then evaluates the access policy and zone rules to decide whether to permit or drop the flow.
  • Zones / Security Boundaries: Zones (zone security) group interfaces into trust domains. Policies and inspections are applied at the zone or inter-zone level — useful for simple access rules and for enabling zone-based inspection features.
    • Production note: zones let security teams define coarse-grained trust relationships (e.g., outside -> dmz allowed, outside -> inside denied by default).
  • Static Destination NAT with Port Translation: We publish a private service by mapping an outside IP and port to an internal host and port (e.g., 203.0.113.2:20000 -> 192.168.1.10:443). The firewall rewrites packet headers—destination IP/port for inbound, source for outbound return traffic—ensuring symmetric flow handling.
    • Packet flow detail: an inbound packet to 203.0.113.2:20000 is matched against NAT rules, translated to 192.168.1.10:443, then policy (ACL/zone) is evaluated; the reverse mapping applies to replies.
  • Access Control Lists (ACLs): Even with NAT in place, you must permit traffic via an interface ACL (access-group) on the outside interface to allow the initial packets. Without the ACL, the packets will be dropped even if NAT exists.
    • Real-world: NAT alone does not imply permission. Always pair NAT with a policy or ACL to explicitly authorize the published service.

Step-by-step configuration

Step 1: Configure routed interfaces (outside, inside, dmz)

What we are doing: Assign IP addresses and names to the FTD interfaces so the firewall can route and apply policies between the Internet (outside), internal LAN (inside), and DMZ. Names and IPs are required for NAT, ACLs, and zone membership.

configure terminal
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.0
 no shutdown
exit

interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
 no shutdown
exit

interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 10.0.0.1 255.255.255.0
 no shutdown
exit
write memory
exit

What just happened: Each interface was placed into routed mode with a name (nameif) and security-level. The outside interface receives the public IP 203.0.113.2/24 from the reference. Inside and DMZ interfaces have private IPs (192.168.1.1/24 and 10.0.0.1/24). The security-level influences default ASA-like behavior (higher security-level can initiate to lower without ACL). Interfaces must be up (no shutdown) to handle traffic.

Real-world note: In production, ensure the outside IP is the exact public-facing address assigned by your ISP (here 203.0.113.2). Using the wrong mask or nameif will break NAT and policy mapping.

Verify:

show ip interface brief
Interface                      IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0             203.0.113.2     YES manual up                    up
GigabitEthernet0/1             192.168.1.1     YES manual up                    up
GigabitEthernet0/2             10.0.0.1        YES manual up                    up

Step 2: Create security zones and map interfaces to zones

What we are doing: Define zones for Outside, Inside, and DMZ, and assign the configured interfaces to those zones so policies can be written by zone boundaries rather than per-interface. Zones make policy management scalable.

configure terminal
zone security OUTSIDE
 zone-member interface outside
exit

zone security INSIDE
 zone-member interface inside
exit

zone security DMZ
 zone-member interface dmz
exit
write memory
exit

What just happened: Three security zones were created and each interface was bound to its corresponding zone. Now, when you write access rules or inspection policies, you can reference traffic moving between zones (e.g., from OUTSIDE to DMZ) which simplifies rule logic and helps auditing.

Real-world note: Grouping interfaces into zones is common in environments with multiple DMZs or service tiers; you can treat a group of interfaces as one logical trust domain.

Verify:

show zone
Zone name: OUTSIDE
  Interfaces:
    outside
Zone name: INSIDE
  Interfaces:
    inside
Zone name: DMZ
  Interfaces:
    dmz

Step 3: Configure static destination NAT (public port 20000 -> internal HTTPS)

What we are doing: Publish the internal application server 192.168.1.10 (lab.nhprep.com) by mapping external IP 203.0.113.2 port 20000 to internal port 443 so external users can reach the web app securely.

configure terminal
object network WEB-SRV
 host 192.168.1.10
 nat (inside,outside) static 203.0.113.2 service tcp 443 20000
exit
write memory
exit

What just happened: We created a network object representing the internal web server and defined a static NAT translation that maps the internal host's TCP port 443 to the firewall's public IP on TCP port 20000. When an incoming packet hits 203.0.113.2:20000, the firewall will translate destination IP to 192.168.1.10 and destination port to 443 before policy evaluation. Reply traffic is translated back to the public IP/port.

Real-world note: Port translation allows hosting multiple services on a single public IP or remapping non-standard external ports to standard internal ports for application compatibility.

Verify:

show nat
nat (inside,outside) source static WEB-SRV WEB-SRV destination static WEB-SRV WEB-SRV service tcp 443 20000
Object: WEB-SRV
  host 192.168.1.10
  mapped to 203.0.113.2 service tcp 20000

Step 4: Permit inbound traffic to the mapped port (ACL and access-group)

What we are doing: Create an access-list to permit TCP traffic destined to the firewall’s public IP on port 20000 and apply it inbound on the outside interface. NAT alone will not allow packets — an access policy must allow them.

configure terminal
access-list outside_access_in extended permit tcp any host 203.0.113.2 eq 20000
access-group outside_access_in in interface outside
exit
write memory
exit

What just happened: The ACL entry explicitly permits inbound TCP flows to 203.0.113.2:20000. Applying the ACL to the outside interface makes the firewall check and allow the initial SYN packet; after NAT and ACL evaluation, the traffic can reach the internal server. Without this step, the NAT would exist but traffic would be dropped.

Real-world note: Use precise ACLs — restrict source ranges where possible (e.g., known proxies or partner ASNs) to reduce attack surface.

Verify:

show access-list outside_access_in
Extended IP access list outside_access_in
    10 permit tcp any host 203.0.113.2 eq 20000
show running-config access-group
access-group outside_access_in in interface outside

Step 5: Verify end-to-end connectivity (NAT, zones, interface reachability)

What we are doing: Confirm that interfaces are up, NAT is in place, the ACL is active, and that a synthetic TCP connection would match the NAT and ACL rules. This step ensures the configuration is functionally complete.

show ip interface brief
show nat
show access-list outside_access_in
show zone
show running-config

What just happened: The collected output shows interface states, NAT entries, ACLs, and zone membership. From these outputs an operator can confirm the firewall will accept TCP traffic to 203.0.113.2:20000, translate it to 192.168.1.10:443, and forward it into the inside network.

Real-world note: After these checks, perform a real functional test (e.g., external curl to https://lab.nhprep.com:20000/) and check connection logs/packets in the firewall management to ensure TLS negotiation succeeds through any TLS-inspection policies you may have.

Verify (example expected outputs):

show ip interface brief
Interface                      IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0             203.0.113.2     YES manual up                    up
GigabitEthernet0/1             192.168.1.1     YES manual up                    up
GigabitEthernet0/2             10.0.0.1        YES manual up                    up

show nat
nat (inside,outside) source static WEB-SRV WEB-SRV destination static WEB-SRV WEB-SRV service tcp 443 20000
Object: WEB-SRV
  host 192.168.1.10
  mapped to 203.0.113.2 service tcp 20000

show access-list outside_access_in
Extended IP access list outside_access_in
    10 permit tcp any host 203.0.113.2 eq 20000

show zone
Zone name: OUTSIDE
  Interfaces:
    outside
Zone name: INSIDE
  Interfaces:
    inside
Zone name: DMZ
  Interfaces:
    dmz

show running-config
! (truncated to relevant sections)
interface GigabitEthernet0/0
 nameif outside
 security-level 0
 ip address 203.0.113.2 255.255.255.0
!
interface GigabitEthernet0/1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet0/2
 nameif dmz
 security-level 50
 ip address 10.0.0.1 255.255.255.0
!
object network WEB-SRV
 host 192.168.1.10
 nat (inside,outside) static 203.0.113.2 service tcp 443 20000
!
access-list outside_access_in extended permit tcp any host 203.0.113.2 eq 20000
access-group outside_access_in in interface outside
!
zone security OUTSIDE
 zone-member interface outside
zone security INSIDE
 zone-member interface inside
zone security DMZ
 zone-member interface dmz

Verification Checklist

  • Check 1: Interfaces are up with correct IPs — verify with show ip interface brief.
  • Check 2: NAT translation exists mapping 203.0.113.2:20000 -> 192.168.1.10:443 — verify with show nat.
  • Check 3: ACL permitting inbound traffic applied on outside interface — verify with show access-list outside_access_in and show running-config.
  • Check 4: Zones contain the intended interfaces — verify with show zone.

Common Mistakes

SymptomCauseFix
External clients cannot reach the application (timeout)Missing or incorrect access-list on outside interface.Add an ACL permitting TCP to 203.0.113.2 eq 20000 and apply it: access-list ... / access-group ...
NAT exists but traffic goes to wrong internal hostNAT object host IP typo (e.g., 192.168.1.100 instead of 192.168.1.10).Correct the object network host IP and reapply NAT.
Packet arrives but TLS negotiation failsTLS inspection, certificate or policy mismatch (inspection applied to this flow)Check inspection policies, TLS decrypt settings and ensure server cert chain is valid or bypass inspection for this app if required.
Interfaces show downPhysical link or interface name mismatchVerify physical cabling and ensure no shutdown was applied on the correct interface. Confirm actual interface numbering matches the device.

Key Takeaways

  • Always pair NAT with an explicit access policy: NAT translates addresses/ports but does not implicitly permit traffic.
  • Nameif, IP, and security-level on interfaces are foundational — many subsequent features (NAT, ACL, zones) depend on these being correct.
  • Zones let you manage trust relationships at a higher level than individual interfaces, improving policy clarity in large deployments.
  • In production, use precise ACLs and consider TLS inspection and IPS policies when publishing applications; these affect user experience and security posture.

Tip: After configuration, perform an external functional test (for example, curl or browser to https://lab.nhprep.com:20000/) and correlate with firewall logs to validate the entire flow, including NAT and any content inspection.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security