NAT Problems in 8.3 when untranslating NATs

Mohamed Hamid · ‎01-15-2013

Hi Guys

I have the following problem

Background: Upgrated from 8.2 Cisco ASA 5520 to 8.3.

I have drawn a diagram similar to the below that shows a similar network. I have a server that requires access on a number interfaces on the ASA, in 8.2 I have a number of NAT rules set as the following

NAT in 8.2

static (il2AHdata,dmzAHdata) 192.168.9.40 10.0.0.40 netmask 255.255.255.255

static (il2AHdata,dmzAHmgmt) 10.1.2.40 10.0.0.40 netmask 255.255.255.255

static (il2AHdata,il2AHmgmt) 10.1.1.40 10.0.0.40 netmask 255.255.255.255

static (il2AHdata,gitHubData) 10.0.2.40 10.0.0.40 netmask 255.255.255.255

static (il2AHdata,gitHubmgmt) 10.1.5.40 10.0.0.40 netmask 255.255.255.255

Since the upgrade, it seems the upgrade script has created many objects, although NATing on the interfaces seem to work, it is when inbound traffic coming back that the ASA does not seem to successully travese.

The followng is what has been created in 8.3

object network monitoringsystem-01

nat (il2AHdata,dmzAHmgmt) static 10.1.2.40

object network monitoringsystem-02

nat (il2AHdata,il2AHmgmt) static 10.1.1.40

object network monitoringsystem-03

nat (il2AHdata,gitHubmgmt) static 10.1.5.40

object network monitoringsystem-04

nat (il2AHdata,gitHubData) static 10.0.2.40

object network monitoringsystem

nat (il2AHdata,dmzAHdata) static 192.168.9.40

I see the following in my logs and it does not report any blocks on ACL, it seems to be able to NAT out but has issues for incoming

|Jan 15 2013|15:38:13|302021|10.1.4.26|0|10.0.0.40|27649|Teardown ICMP connection for faddr 10.1.4.26/0 gaddr 10.1.2.40/27649 laddr 10.0.0.40/27649

Jan 15 2013|15:38:09|302020|10.0.0.40|27649|10.1.4.26|0|Built outbound ICMP connection for faddr 10.1.4.26/0 gaddr 10.1.2.40/27649 laddr 10.0.0.40/27649

Your help and guidance is much appreciated

Kind Regards

Jouni Forss · ‎01-15-2013

Hi,

I am not quite sure what you are referring to with the Log messages?

If the IP address under every "object" configured above is the IP 10.0.0.40 the configurations should be fine.

There however be NAT rules that override the operation of these configurations but that is impossible to say without seeing more NAT configurations or output of "packet-tracer" command.

packet-tracer input tcp

- Jouni

Mohamed Hamid · ‎01-15-2013

Thank you for you reply

I tried the command in questions and it passed all phases however at the end it provide the following reason for dropping packet

Action: drop

Drop-reason: (sp-security-failed) Slowpath security checks failed

?

Jouni Forss · ‎01-15-2013

Hi,

If I'm not completely mistaken you might have used the actual IP address of 10.0.0.40 as the destination IP address and not the NAT IP address (that applies to the connection attempt you are trying to simulate)

- Jouni

Mohamed Hamid · ‎01-15-2013

The following is what I ran

10.1.2.40 is the NAT address for 10.0.0.40?

Is this correct?

asa-L# packet-tracer input il2AHdata tcp 10.0.0.40 22 10.1.2.40 22

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 10.1.2.0 255.255.255.0 dmzAHmgmt

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group il2AHdata_access_in in interface il2AHdata

access-list il2AHdata_access_in extended permit tcp host 10.0.0.40 10.1.2.0 255.255.255.0 eq ssh

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

object network monitoringsystem-01

nat (il2AHdata,dmzAHmgmt) static 10.1.2.40

Additional Information:

Static translate monitoringsystem/22 to dmgmtMonNAT/22

Result:

input-interface: il2AHdata

input-status: up

input-line-status: up

output-interface: dmzAHmgmt

output-status: up

output-line-status: up

Action: drop

Drop-reason: (sp-security-failed) Slowpath security checks failed

Mohamed Hamid · ‎01-15-2013

i did this command again this time with the actual destination of the server on our dmz rather than the NAT ip mapped to 10.0.0.40 and it worked fine howe my server still cannot communicate?

Seems a bit odd

asa-L# packet-tracer input il2AHdata tcp 10.0.0.40 22 10.1.4.26 22

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in hostileAHmgmt 255.255.255.0 dmzAHmgmt

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group il2AHdata_access_in in interface il2AHdata

access-list il2AHdata_access_in extended permit tcp host 10.0.0.40 10.1.4.0 255.255.255.0 eq ssh

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype:

Result: ALLOW

Config:

object network monitoringsystem-01

nat (il2AHdata,dmzAHmgmt) static 10.1.2.40

Additional Information:

Static translate monitoringsystem/22 to dmgmtMonNAT/22

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 5481800, packet dispatched to next module

Result:

input-interface: il2AHdata

input-status: up

input-line-status: up

output-interface: dmzAHmgmt

output-status: up

output-line-status: up

Action: allow

Jouni Forss · ‎01-15-2013

Hi,

The first "packet-tracer" doesnt make any sense.

object network monitoringsystem-01

host 10.0.0.40

nat (il2AHdata,dmzAHmgmt) static 10.1.2.40

asa-L# packet-tracer input il2AHdata tcp 10.0.0.40 22 10.1.2.40 22

You source the connection from the host you are doing Static NAT for and the destination IP address is the NAT IP address of the same source host.

The second "packet-tracer" command atleast makes sense from the par that its destination IP address is not alteast a NAT IP address listed in your configurations. (Though I havent seen all of them naturally)

asa-L# packet-tracer input il2AHdata tcp 10.0.0.40 22 10.1.4.26 22

But where is the network that contains IP address 10.1.4.26 ? dmzAHmgmt?

What do the logs say if you actually try some TCP connection between the hosts?

- Jouni

Mohamed Hamid · ‎01-15-2013

Apologies please ignore first packet trace.

But where is the network that contains IP address 10.1.4.26 ? dmzAHmgmt?

The IP address 10.1.4.26 sits on a network that sits off another firewall in our DMZ. I have run a packet trace on that firewall and it seems incoming ICMP requets from the nat 10.1.2.40 however when it tried to return the packet back to 10.1.2.40 it claims that host is unreachable.

What do the logs say if you actually try some TCP connection between the hosts?

1) When I run a telnet on port tcp/22 I see the following in the logs from the ASDM

6|Jan 15 2013|17:32:25|302016|10.1.4.26|161|monitoringsystem|53486|Teardown UDP connection 5535929 for dmzAHmgmt:10.1.4.26/161 to il2AHdata:monitoringsystem/53486 duration 0:02:06 bytes 384
6|Jan 15 2013|17:32:14|302021|10.1.4.26|0|monitoringsystem|4038|Teardown ICMP connection for faddr 10.1.4.26/0 gaddr dmgmtMonNAT/4038 laddr monitoringsystem/4038
6|Jan 15 2013|17:32:09|302020|monitoringsystem|4038|10.1.4.26|0|Built outbound ICMP connection for faddr 10.1.4.26/0 gaddr dmgmtMonNAT/4038 laddr monitoringsystem/4038
6|Jan 15 2013|17:31:50|302015|monitoringsystem|50625|10.1.4.26|161|Built outbound UDP connection 5537836 for dmzAHmgmt:10.1.4.26/161 (10.1.4.26/161) to il2AHdata:monitoringsystem/50625 (dmgmtMonNAT/50625)



6
Jan 15 2013
17:33:37
302013
monitoringsystem
51063
10.1.4.26
22
Built outbound TCP connection 5540186 for dmzAHmgmt:10.1.4.26/22 (10.1.4.26/22) to il2AHdata:monitoringsystem/51063 (dmgmtMonNAT/51063)

Jouni Forss · ‎01-15-2013

Hi,

I can see the TCP connection forming normally because of the SYN packet the firewalls sees.

I however dont see any Teardown message for the same TCP connection so I cant say if there is now actually an active TCP connection on the firewall (which would mean the remote host has replied to the SYN) or if you just didnt include the Teardown message.

If the connection doesnt go through for whatever reason there should be a Teardown message with "SYN Timeout". If on the other hand the TCP connection was formed and was tore down normally it would be a Teardown message with "TCP FINs"

- Jouni

Mohamed Hamid · ‎01-16-2013

Well I dont see any SYN timeouts.

I have just run a ping to another server at the address 10.0.2.10 and the following appears in my log

6

Jan 16 2013

09:43:48

302020

monitoringsystem

53816

ah1-git-01

0

Built outbound ICMP connection for faddr ah1-git-01/0 gaddr gitDataMon/53816 laddr monitoringsystem/53816

6

Jan 16 2013

09:43:52

302020

monitoringsystem

14552

ah1-git-01

0

Built outbound ICMP connection for faddr ah1-git-01/0 gaddr gitDataMon/14552 laddr monitoringsystem/14552

6

Jan 16 2013

09:43:56

302021

ah1-git-01

0

monitoringsystem

14552

Teardown ICMP connection for faddr ah1-git-01/0 gaddr gitDataMon/14552 laddr monitoringsystem/14552

6

Jan 16 2013

09:44:22

302020

monitoringsystem

14591

ah1-git-01

0

Built outbound ICMP connection for faddr ah1-git-01/0 gaddr gitDataMon/14591 laddr monitoringsystem/14591

6

Jan 16 2013

09:44:26

302021

ah1-git-01

0

monitoringsystem

14591

Teardown ICMP connection for faddr ah1-git-01/0 gaddr gitDataMon/14591 laddr monitoringsystem/14591

I am pretty sure its not a firewall rule on the server itself as it worked completely fine in 8.2 I have cheked the firewall logs on server. It seems the returning ping back in is lost somewhere