07-31-2013 04:04 AM - edited 03-11-2019 07:19 PM
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?
07-31-2013 04:26 AM
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.
07-31-2013 05:00 AM
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
07-31-2013 05:24 AM
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
07-31-2013 05:33 AM
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
07-31-2013 05:42 AM
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
07-31-2013 05:51 AM
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
07-31-2013 05:59 AM
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
07-31-2013 06:05 AM
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.
07-31-2013 06:10 AM
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
07-31-2013 06:23 AM
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
07-31-2013 06:30 AM
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
07-31-2013 08:26 AM
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.
07-31-2013 09:05 AM
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
08-05-2013 03:24 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide