ASA 8.4(5) destination NAT

[MATTHIAS SCHAERER]

Hi,

I'm trying to source and destination NAT a connection over my ASA. I am using Twice NAT for this. The config looks like that:

object network OBJ_HOST1

host 172.18.45.245

object network OBJ_HOST1_MAPPED

host 172.29.1.12

object network OBJ_192.168.10.0_24

subnet 192.168.10.0 255.255.255.0

object network OBJ_192.168.67.0_24

subnet 192.168.67.0 255.255.255.0

nat (INT_ZONE0,INT_ZONE2) source static OBJ_HOST1 OBJ_HOST1_MAPPED destination static OBJ_192.168.67.0_24 OBJ_192.168.10.0_24

route INT_ZONE2 192.168.67.0 255.255.255.0 192.168.25.18 1

When sniffing a ping from 172.18.45.254 to 192.168.67.84 in ZONE2 I can see that the source address is translated into 172.29.1.12, however the destination address stays 192.168.67.84 instead of 192.168.10.84. Is there anything else I need to add to the config, or is the destination NAT simply broken (I have searched the bug tool with no success so far).

Any hint is appreciated.

Mat

[Jouni Forss]

Hi,

I did some testing on a test firewall and seem to have no problem doing this translation (ASA IOS 8.4(2))

Could you take a "packet-tracer" output of the connection attempt?

Format for command

packet-tracer input

This should tell what rules the traffic are hitting.

You should see an UN-NAT Phase first for the destination NAT and a NAT Phase later for the source.

- Jouni

[MATTHIAS SCHAERER]

Hi Jouni

I am missing the UN-NAT you mention. As for your second posting: I think I have put it the right way, 192.168.10.84 is the real IP address of the destination device, 192.168.67.84 is the address I have to ping to ghet there and should be translated by the ASA.

Here's the packet tracer output:

CHGNF02A# packet input INT_ZONE0 ra 172.18.45.245 1 192.168.67.84 de

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.67.0    255.255.255.0   INT_ZONE2

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group ACL_ANY2ANY in interface INT_ZONE0

access-list ACL_ANY2ANY extended permit ip any any

access-list ACL_ANY2ANY remark ********************************************************

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x752e78b0, priority=13, domain=permit, deny=false

        hits=14317310, user_data=0x6e6e57c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=INT_ZONE0, output_ifc=any

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x72ae53d8, priority=0, domain=inspect-ip-options, deny=true

        hits=14400395, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip/id=0.0.0.0, mask=0.0.0.0, port=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

        input_ifc=INT_ZONE0, output_ifc=any

Phase: 4

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7542cbe0, priority=70, domain=inspect-icmp, deny=false

        hits=363997, user_data=0x73f8fa78, cs_id=0x0, use_real_addr, flags=0x0, protocol=1

        src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, dscp=0x0

        input_ifc=INT_ZONE0, output_ifc=any

Phase: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x72ae5718, priority=66, domain=inspect-icmp-error, deny=false

        hits=369058, user_data=0x728e8d68, cs_id=0x0, use_real_addr, flags=0x0, protocol=1

        src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0

        dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, dscp=0x0

        input_ifc=INT_ZONE0, output_ifc=any

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (INT_ZONE0,INT_ZONE2) source static OBJ_HOST1 OBJ_HOST1_MAPPED destination static OBJ_192.168.67.0_24 OBJ_192.168.10.0_24

Additional Information:

Static translate NAME_HOST1/0 to 172.29.1.12/0

Forward Flow based lookup yields rule:

in  id=0x7540deb0, priority=6, domain=nat, deny=false

        hits=41, user_data=0x720a8c38, cs_id=0x0, flags=0x0, protocol=0

        src ip/id=NAME_HOST1, mask=255.255.255.255, port=0

        dst ip/id=192.168.67.0, mask=255.255.255.0, port=0, dscp=0x0

        input_ifc=INT_ZONE0, output_ifc=INT_ZONE2

Phase: 7

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 50591931, packet dispatched to next module

Module information for forward flow ...

snp_fp_tracer_drop

snp_fp_inspect_ip_options

snp_fp_inspect_icmp

snp_fp_translate

snp_fp_adjacency

snp_fp_fragment

snp_ifc_stat

Module information for reverse flow ...

Result:

input-interface: INT_ZONE0

input-status: up

input-line-status: up

output-interface: INT_ZONE2

output-status: up

output-line-status: up

Action: allow

[MATTHIAS SCHAERER]

Shit, I hit the wrong button.... meant to answer but got the "right answer" button.

Just for completeness: I reversed the destination as you proposed and in the Wireshark trace no ping packets appeared anymore. So I assume that my first way of configuring it was the right way.

[Jouni Forss]

Hi,

I'll remove my answer and post it again after this post so the rating and answered marking dissapear

Heres my test configuration

object network HOST1

host 10.10.10.167

object network HOST1-MAP

host 20.20.20.20

object network DESTINATION

subnet 192.168.10.0 255.255.255.0

object network DESTINATION-MAP

subnet 192.168.67.0 255.255.255.0

nat (source,destination) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

ASA(config)# packet-tracer input source tcp 10.10.10.167 1025 192.168.67.100 80

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (source,destination) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

NAT divert to egress interface destination

Untranslate 192.168.67.100/80 to 192.168.10.100/80

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group SOURCE-IN in interface inside

access-list SOURCE-IN extended permit ip any any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (source,destination) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

Static translate 10.10.10.167/1025 to 20.20.20.20/1025

Phase: 6

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (source,destination) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 299666704, packet dispatched to next module

Result:

input-interface: source

input-status: up

input-line-status: up

output-interface: destination

output-status: up

output-line-status: up

Action: allow

- Jouni

[Jouni Forss]

Hi this is the readded answer after I first removed the original one that was accidentaly marked as correct answer

Hi,

Try to switch the place of the last 2 objects in the NAT command and try again.

nat (INT_ZONE0,INT_ZONE2) source static OBJ_HOST1 OBJ_HOST1_MAPPED destination static OBJ_192.168.67.0_24 OBJ_192.168.10.0_24

TO

nat (INT_ZONE0,INT_ZONE2) source static OBJ_HOST1 OBJ_HOST1_MAPPED destination static OBJ_192.168.10.0_24 OBJ_192.168.67.0_24

First object should be the mapped/NAT network and the second the real network

Or did I understand you correctly?

- Jouni

[Jouni Forss]

Hi,

What if you remove the added "route" command for the destination network (mapped) and reconfigure the NAT configuration with "no route-lookup" parameter at the very end?

- Jouni

[MATTHIAS SCHAERER]

Hi Jouni,

i tried but what I got was

CHGNF02A(config)# nat (INT_ZONE0,INT_ZONE2) source static OBJ_HOST1$

ERROR: Option route-lookup is only allowed for static identity case

CHGNF02A(config)# $ic OBJ_192.168.67.0_24 OBJ_192.168.10.0_24 no route-lookup

I ask myself how the ASA would find the destination interface without the route anyway.

But thanks for your answers so far. Am I right that the ASA selects the NAT entry based on source and destination address and that it only selects one Twice-NAT statement? I still think that there might be another NAT statement that interferes with the one you see in my packet tracer output. Your packet tracer looks pretty similar to mine except that it seems to work in your case.

Thanks

Mat

[Jouni Forss]

Hi,

I booted one of my test ASA5510 to software 8.4(5) and configured the same setup there.

The output of the "packet-tracer" is still the same.

To my understanding the NAT configuration in question would do the following

• NAT the first source objects IP address to seconds source objects IP
• UNNAT the destination IP from 192.168.67.x to 192.168.10.x

The NAT would naturally apply to the other direction too. If host 192.168.10.x would be connecting to the mapped NAT IP HOST1 it would be visible to that network with the IP 192.168.67.x

Both of my test show that the same is happening

- Jouni

[MATTHIAS SCHAERER]

I completely agree with your interpretation, it's the way I think it should work. When looking into my xlates for Zone2 everything seems to be correct as well.

ASA01(config)# sh xlate interface INT_ZONE2

3356 in use, 6334 most used

Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice

       e - extended

NAT from INT_ZONE9:NAME_HOST5 to INT_ZONE2:172.29.1.11

    flags sT idle 1:37:14 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE9:192.168.67.0/24

    flags sT idle 44:49:51 timeout 0:00:00

NAT from INT_ZONE7:NAME_HOST2 to INT_ZONE2:172.29.1.1

    flags sT idle 44:45:21 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE7:192.168.67.0/24

    flags sT idle 44:45:21 timeout 0:00:00

NAT from INT_ZONE7:NAME_HOST3 to INT_ZONE2:172.29.1.2

    flags sT idle 44:44:33 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE7:192.168.67.0/24

    flags sT idle 44:44:33 timeout 0:00:00

NAT from INT_ZONE7:NAME_HOST4 to INT_ZONE2:172.29.1.3

    flags sT idle 44:44:13 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE7:192.168.67.0/24

    flags sT idle 44:44:13 timeout 0:00:00

NAT from INT_ZONE0:NAME_HOST1 to INT_ZONE2:172.29.1.12

    flags sT idle 0:03:02 timeout 0:00:00

NAT from INT_ZONE2:192.168.25.18 to INT_ZONE0:192.168.25.18

    flags sIT idle 3:20:40 timeout 0:00:00

NAT from INT_ZONE0:NAME_HOST1 to INT_ZONE2:172.29.1.12

    flags sT idle 0:02:37 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE0:192.168.67.0/24

    flags sT idle 1:15:02 timeout 0:00:00

ASA01(config)#

But there must be something that prevents the statements to be executed for the destination address. I search all my other nat statements, maybe there is one that kicks in before this one is looked at.

Thanks

Mat

[Jouni Forss]

Hi,

Went as far as connecting the ASA to a C3750 and configured 2 ports for it

• Port 1 = 10.10.10.100 (global routing)
  • connected to "inside"
• Port 2 = 20.20.20.2 (vrf TEST)
  • connected to "outside"

I only configured the following configurations on the ASA

interface Ethernet0/0

nameif outside

security-level 0

ip address 20.20.20.1 255.255.255.0

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 10.10.10.1 255.255.255.0

!

object network HOST1

host 10.10.10.100

object network HOST1-MAP

host 30.30.30.1

object network DESTINATION

host 20.20.20.2

object network DESTINATION-MAP

host 30.30.30.2

nat (inside,outside) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

policy-map global_policy

class inspection_default

   inspect icmp

PACKET-TRACER

ciscoasa# packet-tracer input inside tcp 10.10.10.100 1025 30.30.30.2 80

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

nat (inside,outside) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

NAT divert to egress interface outside

Untranslate 30.30.30.2/80 to 20.20.20.2/80

Phase: 2

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 3

Type: NAT

Subtype:

Result: ALLOW

Config:

nat (inside,outside) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

Static translate 10.10.10.100/1025 to 30.30.30.1/1025

Phase: 4

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside,outside) source static HOST1 HOST1-MAP destination static DESTINATION-MAP DESTINATION

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 33, packet dispatched to next module

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

ICMP from L3 Switch

L3Switch# ping 30.30.30.2 source FastEthernet2/0/1

Sending 5, 100-byte ICMP Echos to 30.30.30.2, timeout is 2 seconds:

Packet sent with a source address of 10.10.10.100

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/9 ms

ASA log

ICMP inside -> outside

%ASA-6-302020: Built outbound ICMP connection for faddr 20.20.20.2/0 gaddr 30.30.30.1/6 laddr 10.10.10.100/6

%ASA-6-302021: Teardown ICMP connection for faddr 20.20.20.2/0 gaddr 30.30.30.1/6 laddr 10.10.10.100/6

TELNET inside -> outside

%ASA-6-302013: Built outbound TCP connection 35 for outside:20.20.20.2/23 (30.30.30.2/23) to inside:10.10.10.100/11000 (30.30.30.1/11000)

%ASA-6-302014: Teardown TCP connection 35 for outside:20.20.20.2/23 to inside:10.10.10.100/11000 duration 0:00:02 bytes 78 TCP FINs

- Jouni

[Jouni Forss · Accepted solution]

Hi,

If I'm not completely wrong the below lines from your copy/pasted output are related to your NAT configuration

NAT from INT_ZONE0:NAME_HOST1 to INT_ZONE2:172.29.1.12

    flags sT idle 0:02:37 timeout 0:00:00

NAT from INT_ZONE2:192.168.10.0/24 to INT_ZONE0:192.168.67.0/24

    flags sT idle 1:15:02 timeout 0:00:00

I think it also shows the same information above them. I dont know why.

Do notice that if you want to move this NAT configuration to the very top of the NAT configuration.

You can configure it with the command

nat (INT_ZONE0,INT_ZONE2) 1 source static OBJ_HOST1 OBJ_HOST1_MAPPED destination static OBJ_192.168.67.0_24 OBJ_192.168.10.0_24

The number 1 right after the configured interfaces tells the firewall to add the new NAT configuration to the very top. This should also move all the other existing rules one line down. Just like adding a ACL rule with the "line x" parameter.

Really want to know what is causing this problem I know that all through out the 8.4(x) series of the software there has been changes and addiotions to the operation of the NAT. Though I tested the configuration with both 8.4(2) and 8.4(5) and didnt see anything different in the output.

- Jouni

[MATTHIAS SCHAERER]

Hi Jouni,

Finally it works with moving the statement to the top. It was not so easy to do that though.

I first tried to move the statement to position 1 by overwriting it. A show nat afterwards listed the statement still on position 198 (show nat). Then I removed and newly added the statement but still no change. The last try was to remove it, then do a clear xlate and then add it again. This was the solution.

Thanks for all your help, I will have to remove all unnecessary nat statements afterwards (the config was automatically migrated from 8.2, so all the nat 0 translated into identity nat for a big number of interfaces).

Happy new year and thanks again

Mat

[Jouni Forss]

Great that its working now

I guess the reason for the problem either was that there was some old xlate "hanging" on the firewall or there was some NAT configuration preceding the one you configured.

Though in the case of having the NAT rule in the wrong place I would imagine that the "packet-tracer" should have stated that the traffic was hitting some other rule. I'm not 100% sure if it will clearly show all type of conflicting NAT configuratins but usually it gives a pretty good picture whats happening. Though sometimes it doesnt give any information whatsoever.

I don't know would the ASDM real time log monitoring perhaps given a hint while testing connections to what was causing the problem.

I personally have never let the firewall migrate NAT commands to new format ever. I first trained "every" type of NAT on the separate device and then started writing the NAT rules myself. This was a great way to learn them and built the NAT configuration to only include the NAT configurations needed (so that they were as specific as possible to avoid any overlapping later). It also helps later management of the firewall environment when you have specific knowledge whats configured on the device.

Happy new year to you too Matthias

- Jouni

[MATTHIAS SCHAERER]

Well, personally I prefer your method of testing offline but as I had no test environment (I just read over this issue that GNS3 supports ASA) I had to go the way of automatically migrating the config. I ended in about 1700+ lines of additional code from which I already cleared 1500 that really were unnecessary.

What I have learned from the issue is that I definitely have to have my GNS3 up to date and that a clear command once in a while helps the ASA understand what you want. And the sorting of the lines can make a big difference.

Thanks again and greetings to Finland

Mat