ASA 9.4 NAT Issue

[richdodson]

I was converting a client today from 8.2 to 9.4, which involved a lot of NAT changes.  I didn't think this would be all that big of a deal, but I ran into a road block I didn't know how to get past.

They have an internal Exchange server that accepts outside connections to ports 25, 80 & 443 on the external interface.  The previous NAT statements are as follows:

192.168.1.55 = Exchange Server

static (inside,outside) tcp interface www 192.168.1.55 www netmask 255.255.255.255
static (inside,outside) tcp interface https 192.168.1.55 https netmask 255.255.255.255
static (inside,outside) tcp interface smtp 192.168.1.55 smtp netmask 255.255.255.255

I replaced those statements with the following:

object network ExchangeServer
 host 192.168.1.55
object service ExchangeSMTP
 service tcp destination eq smtp
object service ExchangeWWW
 service tcp destination eq www
object service ExchangeHTTPS
 service tcp destination eq https

nat (inside,outside) source static ExchangeServer interface service ExchangeSMTP ExchangeSMTP
nat (inside,outside) source static ExchangeServer interface service ExchangeWWW ExchangeWWW
nat (inside,outside) source static ExchangeServer interface service ExchangeHTTPS ExchangeHTTPS

My connections were not accepted, however.  When I ran packet tracer, it seemed as if the NAT statement was not having any effect:

100.100.100.100 is the sanitized outside interface IP address

asa# packet-tracer input outside tcp 4.4.4.4 5555 100.100.100.100 443 detail

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 100.100.100.100 using egress ifc  identity

Phase: 2
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffdd8dcbf0, priority=1, domain=nat-per-session, deny=true
        hits=14891, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=any, output_ifc=any

Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffddb402d0, priority=0, domain=permit, deny=true
        hits=5066, user_data=0xa, cs_id=0x0, use_real_addr, flags=0x1000, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
        input_ifc=outside, output_ifc=any

Result:
input-interface: outside
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

asa#

I can provide any more information that might be necessary.  Would be very grateful for any clues in the right direction.

Thanks!

-Richard

[mvsheik123]

Hi,

Do you have access-list rule to allow outside connections on those ports to Inside? If existing, ACL applied to outside interface? Based on the packet tracer result, looks like ACL is the issue.

hth

MS

[richdodson]

Yes, I have an access-list line that's permitting any traffic to both the internal and the external IP addresses on those services.  My understanding is that I'll only need the internal IP address rule, but I have both to be sure for now.

[johnlloyd_13]

hi,

the command access-list is different from access-group.

could you do a show run access-group and post it here?

[richdodson]

asa# show run access-group
access-group 100 in interface outside
access-group 101 in interface inside
access-group dmz_access_in in interface DMZ
access-group GuestWifi_access_in in interface GuestWifi
asa#

[johnlloyd_13]

yes, i agree with MS.

did you apply the ACL with the access-group <ACL NAME> outside in command?

[richdodson]

Yes, I have.  The access-list is working for other nat rules that are in the following format:

object network TSInside
 nat (DMZ,outside) static TSOutside dns

[johnlloyd_13]

hi,

you're packet tracer output says it dropped the connection due to ACL.

did you allow outside IP and TCP ports 25, 80 and 443 to real/local IP 192.168.1.55.

[richdodson]

Yes, these are the lines in place:

access-list 100 extended permit tcp any host 192.168.1.55 eq www
access-list 100 extended permit tcp any host 192.168.1.55 eq https
access-list 100 extended permit tcp any host 192.168.1.55 eq smtp

access-list 100 extended permit tcp any host 100.100.100.100 eq www
access-list 100 extended permit tcp any host 100.100.100.100 eq https
access-list 100 extended permit tcp any host 100.100.100.100 eq smtp

[richdodson]

A big thank you to Juan Grajales at Cisco TAC for helping me solve this issue.  I would also like to thank johnlloyd_13 and mvsheik123 for their input. 

There were two problems working against me, one was the service entries:

object service ExchangeSMTP
 service tcp destination eq smtp
object service ExchangeWWW
 service tcp destination eq www
object service ExchangeHTTPS
 service tcp destination eq https

all need to be changed to the following:

object service ExchangeSMTP
 service tcp source eq smtp
object service ExchangeWWW
 service tcp source eq www
object service ExchangeHTTPS
 service tcp source eq https

The other issue working against me was the order of the NAT entries.  These lines:

static (inside,outside) tcp interface www 192.168.1.55 www netmask 255.255.255.255
static (inside,outside) tcp interface https 192.168.1.55 https netmask 255.255.255.255
static (inside,outside) tcp interface smtp 192.168.1.55 smtp netmask 255.255.255.255

Need to be above these lines:

nat (inside,outside) source dynamic InsideNetworks interface
nat (DMZ,outside) source dynamic DMZNetworks interface

I realize this problem couldn't have been seen based off of my original post, but I wanted to make sure I included this in the answer.  Static interface nat entries need to be placed above dynamic interface nat entries, otherwise the dynamic entries take precedence.  I hope this helps anyone else who has experienced this issue or may experience this in the future.