ASA 5510 8.4.6 Outside interface NAT issue

epasqualotto · ‎07-31-2013

Hi all, I've just upgraded my ASA 5510 to 8.4.x and I can't NAT on outside interface anymore.

I can't understand when Packet-tracer say me "implicit rule".

This is an example of my config:

object network Zabbix

nat (Lan,Esterna) static interface service tcp www 8080

(maybe one is ok but I tried both ports)

access-list Esterna_access_in extended permit tcp any object Zabbix eq www

access-list Esterna_access_in extended permit tcp any object Zabbix eq 8080

nat (Lan,Esterna) source dynamic Server interface

Result of the command: "packet-tracer input Esterna tcp 8.8.8.8 12345 MY_PUBLIC_IP 8080"

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in MY_PUBLIC_IP 255.255.255.255 identity

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Esterna

input-status: up

input-line-status: up

output-interface: NP Identity Ifc

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Anyone have suggestion?

cadet alain · ‎07-31-2013

Hi,

in newer code > 8.2, the ACL must specify the internal IP and not the translated IP so replace this ACL:

access-list Esterna_access_in extended permit tcp any object Zabbix eq www

access-list Esterna_access_in extended permit tcp any object Zabbix eq 8080

by

access-list Esterna_access_in extended permit tcp any x.x.x.x eq www

access-list Esterna_access_in extended permit tcp any x.x.x.x eq 8080

where x.x.x.x is the internal IP you are forwarding, don't forget to apply the ACL inbound on Esterna interface with access-group command.

Also I suppose there is only one host you are port forwarding for ? so you must change the object network clause by specifying this host like this: http://networkology.net/2012/04/08/static-pat-port-forwarding-asa-83-84/

Then redo your packet-tracer with the internal IP as destination

Regards

Alain

Don't forget to rate helpful posts.

epasqualotto · ‎07-31-2013

Hi Alain, thanks for the answer.

Zabbix obj is already the internal address:

object network Zabbix

host 192.168.1.110

description Created during name migration

Anyway I tried also with:

access-list Esterna_access_in extended permit tcp any host 192.168.1.110 eq www

access-list Esterna_access_in extended permit tcp any host 192.168.1.110 eq 8080

But nothing.

If I do the packet-tracer with the internal IP I got (I don't know whitch port is used):

Result of the command: "packet-tracer input Esterna tcp 8.8.8.8 12345 192.168.1.110 8080"

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.1.0 255.255.255.0 Lan

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Esterna_access_in in interface Esterna

access-list Esterna_access_in extended permit tcp any host 192.168.1.110 eq 8080

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: INSPECT

Subtype: inspect-ftp

Result: ALLOW

Config:

class-map global-class

match any

policy-map global_policy

class global-class

inspect ftp

service-policy global_policy global

Additional Information:

Phase: 5

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

nat (Lan,Esterna) after-auto source dynamic Server interface

Additional Information:

Result:

input-interface: Esterna

input-status: up

input-line-status: up

output-interface: Lan

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

AND

Result of the command: "packet-tracer input Esterna tcp 8.8.8.8 12345 192.168.1.110 80"

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.1.0 255.255.255.0 Lan

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Esterna_access_in in interface Esterna

access-list Esterna_access_in extended permit tcp any host 192.168.1.110 eq www

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: INSPECT

Subtype: inspect-ftp

Result: ALLOW

Config:

class-map global-class

match any

policy-map global_policy

class global-class

inspect ftp

service-policy global_policy global

Additional Information:

Phase: 5

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

object network Zabbix

nat (Lan,Esterna) static interface service tcp www 8080

Additional Information:

Result:

input-interface: Esterna

input-status: up

input-line-status: up

output-interface: Lan

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Thanks

Jouni Forss · ‎07-31-2013

Hi,

The target of the "packet-tracer" needs to be the public IP address/NAT IP address rather than the real IP address.

That is why you are seeing that the initial Phases go through but it DROPs the packet in the RPF Check of the NAT rule. In other words it has matched no NAT rule in the way in but on the reverse direction it matches a NAT rule and is dropped.

I would imagine that your problem is overriding NAT rule that prevents the Static PAT from working.

You might have something likes this for example

nat (Lan,Esterna) source dynamic any interface

This would already prevent the Static PAT from working.

If you have the said configuration you should remove it and replace it as

nat (Lan,Esterna) after-auto source dynamic any interface

Adding the "after-auto" will move the Dynamic PAT rule (or whatever you might have, if you have it) to a lowest section of the NAT rules and therefore the Static PAT would now be on higher priority and would work.

- Jouni

epasqualotto · ‎07-31-2013

Jouni, I got this nat rule:

nat (Lan,Esterna) after-auto source dynamic Server interface

Where into "server" there's also my internal IP that I want to be natted.

Anyway the packet-tracer results are always

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in MY_PUBLIC_IP 255.255.255.255 identity

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Esterna

input-status: up

input-line-status: up

output-interface: NP Identity Ifc

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Jouni Forss · ‎07-31-2013

Hi,

It should be matching to a NAT rule before any ACL related drop could occur.

Can you share your NAT configuration.

Is that the output of a "packet-tracer" command that targets the mapped port of TCP/8080?

- Jouni

epasqualotto · ‎07-31-2013

Yes is the output of:

packet-tracer input Esterna tcp 8.8.8.8 12345 MY_PUBLIC_IP 8080

My all NAT config is too long and I must clean IP/name ecc, but this internal IP is matched also by the group Server and this is the only nat rule:

nat (Lan,Esterna) after-auto source dynamic Server interface

Do you think the inactive nat rule can be a problem or are all skipped?

Another info, the other NAT on other pubblic IP is working well.

Thanks

Jouni Forss · ‎07-31-2013

Hi,

The most common reason I have seen for a Static PAT to fail is a Dynamic PAT using the same external interface IP that is too high in the priority of the NAT configurations.

At the moment it should be matching to some NAT rule before it could be dropped by an ACL as the UN-NAT Phase should be among the first Phases and if that went through then an interface ACL might cause a drop.

Maybe we could check another type of "packet-tracer" test unless its stopped by some interface ACL

packet-tracer input Lan tcp 192.168.1.110 80 8.8.8.8 12345

Lets see to which NAT rule this kind of packet coming from the LAN should match to. To my understanding it should match the Static PAT rule you have configured if its working correctly. Or it might match some wrong rule.

- Jouni

epasqualotto · ‎07-31-2013

Result of the command: "packet-tracer input Lan tcp 192.168.1.110 80 8.8.8.8 12345"

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 Esterna

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: Lan

input-status: up

input-line-status: up

output-interface: Esterna

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Is dropped by ACL and no NAT rule.

Jouni Forss · ‎07-31-2013

Hi,

Well in this case it would seem to me that ACL is blocking this packet.

The ACL is checked first for the source and then the NAT for the source.

This works fine for my home ASA when I test with the same logic one of my Static PAT rules.

Since there is no NAT for destination in this case we wont be expecting any NAT rule before the ACL check.

CAn you for example make an ACL rule to the top of the interface ACL that allows this traffic of the "packet-tracer" and then try again.

If that doesnt go through then there either has to some global setting that prevents the connections or something going on that I can't really point out.

- Jouni

epasqualotto · ‎07-31-2013

This is the output after insert the ACL that permit all traffic from 192.168.1.110

(I have change the NAT config by mapping 80 to 80 and not 8080 to 80)

Result of the command: "packet-tracer input Lan tcp 192.168.1.110 80 8.8.8.8 12345"

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 Esterna

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Lan_access_in in interface Lan

access-list Lan_access_in extended permit ip object Zabbix any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: INSPECT

Subtype: inspect-ftp

Result: ALLOW

Config:

class-map global-class

match any

policy-map global_policy

class global-class

inspect ftp

service-policy global_policy global

Additional Information:

Phase: 6

Type: FOVER

Subtype: standby-update

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype:

Result: ALLOW

Config:

object network Zabbix

nat (Lan,Esterna) static interface service tcp www www

Additional Information:

Static translate Zabbix/80 to PUBLIC_IP/80

Phase: 8

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (Lan,Esterna) after-auto source dynamic Server interface

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: Lan

input-status: up

input-line-status: up

output-interface: Esterna

output-status: up

output-line-status: up

Action: allow

Jouni Forss · ‎07-31-2013

Hi,

That seems go through just fine.

But is the situation the same for the direction from External to Internal?

One thing that is very odd in your above output is the fact that this traffic is matching some FTP inspection rule which it really shouldnt.

Don't know if it has anything to do with this situation.

If we presume that all the related ACLs and NAT are configured correctly then I can't really see the problem. It wouldnt be the first time where a reboot solved this kind of problem. I just have not personally expirienced this kind of problem with Static PAT.

- Jouni

epasqualotto · ‎07-31-2013

I've excluded also the inspection without luck. Tomorrow I'll try to reboot both firewall (HA setup) and hope solve the issue (I don't think).

This is a migration from version 8.0, maybe the auto migration of rules introduce some unexpected config.

Thanks

Enrico.

Jouni Forss · ‎07-31-2013

Hi,

It is possible that the automatic migration of the NAT rules during bootup has created rules that that cause this not to work.

I have personally always done the migration manually be converting the configurations myself. Naturally this causes some outage to network connections but I think its a better solution than getting a very messy/vague NAT configuration that you dont personally know.

From what I have read here on the forum discussion, it seems the ASA might create large amount of NAT configurations that might be useless in the new configuration format. And naturally how specific the NAT configuration was in the old software probably plays a role in how the configuration converts.

One question would be. Do you have any other Static PAT rules that use the "interface" IP address of the ASA "Esterna" ? You said that you have other NAT rules that are working. Are these perhaps using separate public IP address?

I would look for any NAT configurations in the existing configuration that use the parameter "any" at either the interface or the source network/host configuration section.

These might sometimes cause big problems for traffic forwarding.

- Jouni

epasqualotto · ‎08-05-2013

Finally I got it working.

I delete all the "name object" in my config, do a clear xlate, and renamed the network-object used in NAT command and all is working.

I thought some name/network object during migration had some issue and conflict with nat.

So I confirm that it's better when migrating from 8.2/3 to 8.4 to start the config from scratch.