Cisco ASA5525-X Ver 9.2 NAT issue (2nd range of Public IP)

[asalvador]

Anyone has the similar issue and has already solved?

I have issue with NAT to the 2nd set range of Public IP address provided to me by my ISP. This issue occurs only in Cisco ASA5525-X ver9.2. It is perfectly working fine with other ASA firewalls without sweat.

I configured static NAT by translating one private IP to one Public IP (2nd range). From the packet trace, it shows me drop at NAT. It is perfectly working with my ASA5520 but it is big headache to my ASA5520. 

object network SRV-GLOBAL

host 200.0.0.10

object network SRV-GLOBAL

nat (TEST,EXTERNAL) static 203.117.78.142 service tcp telnet telnet

access-list EXTERNAL_access_in line 12 extended permit ip any object SRV-GLOBAL

----------------------------------------

ASA5520 Ver8.4

NAT       203.117.68.76/28              All Public IP works 1st range

NAT       203.117.78.128/28            All Public IP works 2nd range

ASA5525-X ver 9.2

NAT       203.117.68.76/28              All Public IP works 1st range

NAT       203.117.78.128/28            All Public IP NOT working 2nd range

[Mohammed al Baqari]

Do you have an ACL permitting the new object-group name

[Karsten Iwen · Accepted solution]

Depending on how your ISP has configured the second subnet, you might need the command "arp permit-nonconnected". Have you configured that?

And your ASA version 9.2 is nearly EOL, you should plan to update to 9.6 or 9.8.

[asalvador]

This make sense. I have not  enabled it. Is there any impact if I enabled it?

If I upgrade to latest version 9.8, is it default disabled?

[asalvador]

Hi Karsten

Still does not work after I have enable the arp permit-connected

arp timeout 14400
arp permit-nonconnected

My ISP has allocated 2 public subnets and configured both of those networks on their gateway interface. For example the network that is link network between the ASA and the ISP gateway and an additional subnet as an "secondary" network on the gateway interface.

[Florin Barhala]

Very interesting thread!
I would like to know what debug options ASA offers in this case? To really see where things go south aka any error that would help.
All I can think is "show asp drop" - but I honestly I don't know how to use to properly debug this.

[Karsten Iwen]

The ISP-configuration as a secondary subnet is where the arp-command is needed. If it is still not working, the problem has to be somewhere else.

Do you have a maintenance window? If yes, then configure one of the secondary IPs as your interface IP and try if it works. If that also fails, the problem could be on the ISP side.

If that works, the problem is like related to your NAT/ACL config. What is the result of packet-tracer now?

[asalvador]

Hi Karsten

Actually in my old FW5520 vers 8.4, I have no problem at all.

Here is the packet trace. Seems the NAT and ACL are porperly configured configured but still cannot ping out or even access via PAT

packet-tracer input TEST icmp 10.1.1.2 3 3 203.24.27.97

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via 203.117.68.177, EXTERNAL

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group TEST_access_in in interface TEST
access-list TEST_access_in extended permit ip object A-TEST-10.1.1.2 any
Additional Information:

Phase: 3
Type: NAT
Subtype:
Result: ALLOW
Config:
object network A-TEST-10.1.1.2
nat (TEST,EXTERNAL) static 203.117.78.142
Additional Information:

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Result:
input-interface: TEST
input-status: up
input-line-status: up
output-interface: EXTERNAL
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

----------

access-list TEST_access_in; 3 elements; name hash: 0x293224b5
access-list TEST_access_in line 1 extended permit ip object A-TEST-10.1.1.2 any (hitcnt=3) 0x70760c31
access-list TEST_access_in line 1 extended permit ip host 10.1.1.2 any (hitcnt=3) 0x70760c31
access-list TEST_access_in line 2 extended permit icmp any any (hitcnt=55) 0x5a7d6807
access-list TEST_access_in line 3 extended permit ip any any log debugging interval 300 (hitcnt=0) 0x02483cb9

[asalvador]

This sounds weird but if it is really weird, I am very happy and thankful.. Somehow it works after a day since I enabled the arp permit-connect. I don't know the reason but thanks again to all you guys there specially Karsten