NAT behavior on FTD

qsosan20 — Mon, 15 Sep 2025 21:28:31 GMT

Hello Experts ,

I have some strange behavior on FTD as below :

I have nat statement from inside to dmz1 :
nat (inside,dmz1) source static obj_10.1.1.11 obj_192.168.2.28
and with packet tracer i can confirm traffic sourced from 192.168.2.138 to 192.168.2.28 it hits the nat and translate the destination to 10.1.1.11 as below :

firepower# packet-tracer input dmz1 tcp 192.168.2.138 123 192.168.2.28 25 $

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 25590 ns
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xff6d9b6d90, priority=13, domain=capture, deny=false
hits=27620208, user_data=0xffeeeafcc0, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=dmz1, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 25590 ns
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xffb02034b0, priority=1, domain=permit, deny=false
hits=853214246, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=dmz1, output_ifc=any

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Elapsed time: 20472 ns
Config:
nat (inside,dmz1) source static obj_10.1.1.11 obj_192.168.2.28
Additional Information:
NAT divert to egress interface inside(vrfid:0)
Untranslate 192.168.2.28/25 to 10.1.1.11/25

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 14671 ns

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Elapsed time: 14671 ns
Config:
nat (inside,dmz1) source static obj_10.1.1.11 obj_192.168.2.28
Additional Information:
Static translate 192.168.2.138/123 to 192.168.2.138/123
Forward Flow based lookup yields rule:
in id=0xff94151bf0, priority=6, domain=nat, deny=false
hits=440, user_data=0xff9d183c60, cs_id=0x0, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=192.168.2.28, mask=255.255.255.255, port=0, tag=any
src nsg_id=none, dst nsg_id=none
dscp=0x0, input_ifc=dmz1(vrfid:0), output_ifc=inside(vrfid:0)

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 14671 ns
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xfff07b2310, priority=0, domain=nat-per-session, deny=false
hits=74979312, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any,
src nsg_id=none, dst nsg_id=none
dscp=0x0, input_ifc=any, output_ifc=any

.......
.......
.......
.......

Phase: 18
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Elapsed time: 4265 ns
Config:
Additional Information:
Found adjacency entry for Next-hop 10.1.1.225 on interface inside
Adjacency :Active
MAC address 0000.0c07.ace2 hits 40022292 reference 5479

Result:
input-interface: dmz1(vrfid:0)
input-status: up
input-line-status: up
output-interface: inside(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 408846 ns

however when running the packet tracer from different source on same subnet 192.168.2.38 to 192.168.2.28 , it does not hit the nat and traffic being dropped as below :

firepower# packet-tracer input dmz1 tcp 192.168.2.38 123 192.168.2.28 25 d$

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 22178 ns
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xff6d9b6d90, priority=13, domain=capture, deny=false
hits=27790330, user_data=0xffeeeafcc0, cs_id=0x0, l3_type=0x0
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0000.0000.0000
input_ifc=dmz1, output_ifc=any

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Elapsed time: 22178 ns
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0xffb02034b0, priority=1, domain=permit, deny=false
hits=853299007, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=dmz1, output_ifc=any

Phase: 3
Type: ROUTE-LOOKUP
Subtype: No ECMP load balancing
Result: ALLOW
Elapsed time: 34120 ns
Config:
Additional Information:
Destination is locally connected. No ECMP load balancing.
Found next-hop 192.168.2.28 using egress ifc dmz1(vrfid:0)

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 15567 ns

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 15567 ns
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xfff07b2310, priority=0, domain=nat-per-session, deny=false
hits=75006731, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any,
src nsg_id=none, dst nsg_id=none
dscp=0x0, input_ifc=any, output_ifc=any

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 52886 ns
Config:
Additional Information:
Reverse Flow based lookup yields rule:
in id=0xfff07b2310, priority=0, domain=nat-per-session, deny=false
hits=75006733, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any,
src nsg_id=none, dst nsg_id=none
dscp=0x0, input_ifc=any, output_ifc=any

Phase: 15
Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Resolve Preferred Egress interface
Result: ALLOW
Elapsed time: 17913 ns
Config:
Additional Information:
Found next-hop 192.168.2.28 using egress ifc dmz1(vrfid:0)

Result:
input-interface: dmz1(vrfid:0)
input-status: up
input-line-status: up
output-interface: dmz1(vrfid:0)
output-status: up
output-line-status: up
Action: drop
Time Taken: 381738 ns
Drop-reason: (no-v4-adjacency) No valid V4 adjacency. Check ARP table (show arp) has entry for nexthop., Drop-location: frame 0x000000aaace1485c flow (NA)/NA

The nat statement should accept any source from DMZ1 interface to 192.168.2.28 , so why one source works and the other does not work ??

Re: NAT behavior on FTD

MHM Cisco World — Mon, 15 Sep 2025 21:35:18 GMT

firepower# packet-tracer input dmz1 tcp 192.168.2.138 123 192.168.2.28 25 $ <<- this wrong

1- how both IP in same subnet??? 192.168.2.0/xx

2- you use 192.168.2.138 as source IP inbound to inside interface where your nat is clear show 192.168.2.28 is connect to inside interface??

MHM

Re: NAT behavior on FTD

qsosan20 — Mon, 15 Sep 2025 22:00:01 GMT

Hello MHM,

Please check the nat again :

nat (inside,dmz1) source static obj_10.1.1.11 obj_192.168.2.28

Inside subnet is 10.1.1.0/24 and dmz subnet is 192.168.2.0/24, what is wrong in such nat??

Re: NAT behavior on FTD

MHM Cisco World — Mon, 15 Sep 2025 22:07:27 GMT

10.1.1.0/24 <<- you need to use this IP then in packet tracer

Traffic inbound as 10.1.1.0/24 and NAT to 192.168.2.28 to connect to host 192.168.2.138

Run above packet tracer and check

MHM

Re: NAT behavior on FTD

qsosan20 — Tue, 16 Sep 2025 11:41:10 GMT

The idea of this nat is to forward dmz subnet clients to inside server 192.168.2.28 , so the traffic direction will be from dmz to inside ,

Can you please double check both packet-tracer and check why first one is working fine and the second does not work ?

Re: NAT behavior on FTD

MHM Cisco World — Tue, 16 Sep 2025 11:45:48 GMT

Friend I know that

Packet tracer can run in two way

From inside to dmz1

Here you need to use inside interface and use 10.1.1.0/24 IP as source and 192.168.2.138 as destiantion

From dmz1 to inside

Here you need to use dmz1 interface and select 192.168.2.138 as source and 192.168.2.28 as destiantion

Run above packet tracer and share result

MHM

topic NAT behavior on FTD in Network Security

NAT behavior on FTD

Re: NAT behavior on FTD

Re: NAT behavior on FTD

Re: NAT behavior on FTD

Re: NAT behavior on FTD

Re: NAT behavior on FTD