Cisco ASA 8.4 port forwarding

Question

I am having trouble port-forwarding on an Cisco ASA from a host on the internet to a host on the internal network. The outside interface of the ASA is assigned via DHCP. Is there something else that has to be done in order to make this work correctly?

update to problem

(outside) to (outside) source dynamic VPN_NETWORK interface

per:

https://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/nat_rules.html

(outside) to (outside) after-auto source dynamic VPN_NETWORK interface

packet-tracer:

# packet-tracer input outside tcp 74.x.x.x 1025 71.x.x.x 555

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   71.x.x.x    255.255.255.255 identity

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

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

running-config

ASA Version 8.4(2) 
!
hostname asa
enable password ***** encrypted
passwd ***** encrypted
names
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
!
interface Ethernet0/4
!
interface Ethernet0/5
!
interface Ethernet0/6
!
interface Ethernet0/7
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 172.16.1.1 255.255.255.0 
!
interface Vlan2
 nameif outside
 security-level 0
 ip address dhcp setroute 
!
boot system disk0:/asa842-k8.bin
ftp mode passive
same-security-traffic permit intra-interface
object network obj_any
 subnet 0.0.0.0 0.0.0.0
object network VPN_NETWORK
 subnet 192.168.1.0 255.255.255.192
object network VM
 host 172.16.1.100
access-list dynamic-filter_acl extended permit ip any any 
access-list VM-IN extended permit tcp any host 172.16.1.100 eq 555 
pager lines 24
logging enable
logging asdm informational
mtu inside 1500
mtu outside 1500
ip local pool VPN-DHCP-POOL 192.168.1.10-192.168.1.50
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-645-206.bin
no asdm history enable
arp timeout 14400
nat (inside,outside) source static any any destination static VPN_NETWORK VPN_NETWORK no-proxy-arp route-lookup
nat (outside,outside) source dynamic VPN_NETWORK interface
!
object network obj_any
 nat (inside,outside) dynamic interface
object network VM
 nat (inside,outside) static interface service tcp 555 555 
access-group VM-IN in interface outside
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
aaa authentication http console LOCAL 
aaa authentication ssh console LOCAL 
http server enable
http 172.16.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec ikev1 transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac 
crypto ipsec ikev1 transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac 
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto map inside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map inside_map interface inside
crypto ikev1 enable inside
crypto ikev1 enable outside
crypto ikev1 policy 10
 authentication crack
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
crypto ikev1 policy 20
 authentication rsa-sig
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
crypto ikev1 policy 30
 authentication pre-share
 encryption aes-256
 hash sha
 group 2
 lifetime 86400
telnet timeout 5
ssh 172.16.1.0 255.255.255.0 inside
ssh timeout 5
ssh version 2
console timeout 0

dhcp-client client-id interface outside
dhcpd auto_config outside
!
dhcpd address 172.16.1.100-172.16.1.200 inside
dhcpd dns 8.8.8.8 8.8.4.4 interface inside
dhcpd option 3 ip 172.16.1.1 interface inside
dhcpd enable inside
!
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
dynamic-filter enable interface outside classify-list dynamic-filter_acl
dynamic-filter drop blacklist interface outside 
ssl encryption des-sha1
webvpn
group-policy EdgeAccess internal
group-policy EdgeAccess attributes
 dns-server value 8.8.8.8 8.8.4.4
 vpn-tunnel-protocol ikev1 
username user password ***** encrypted
tunnel-group EdgeAccess type remote-access
tunnel-group EdgeAccess general-attributes
 address-pool VPN-DHCP-POOL
 default-group-policy EdgeAccess
tunnel-group EdgeAccess ipsec-attributes
 ikev1 pre-shared-key *****
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect ip-options 
!
service-policy global_policy global
privilege show level 0 mode configure command filter
privilege cmd level 0 mode configure command filter
privilege cmd level 0 mode config-group-webvpn command filter
privilege cmd level 0 mode config-username-webvpn command filter
prompt hostname context 
no call-home reporting anonymous
: end

Solution

As of version 8.3, access lists applied with an access-group statement always use the real IP address, even if the incoming packet is directed at a NAT'd IP; see the ASA Version 8.3 Migration Guide for details.

Your access list should instead look like this:

access-list VM_IN extended permit tcp any host 172.16.1.125 eq 777

Or, even better, use the object so you only have to update it in one place in the future:

access-list VM_IN extended permit tcp any object VM eq 777

EDIT (reflecting clarification from Astron):

To do inbound port forwarding to an internal host 192.168.1.125 on an interface that has a dynamically-assigned address (e.g. DHCP):

object network VM
 host 192.168.1.125
!
object network VM
 nat (inside,outside) static interface service tcp 777 777
!
access-list VM_IN extended permit tcp any object VM eq 777
!
access-group VM_IN in interface outside

The key is the static interface part in the nat statement. It will replace interface with whatever the IP of the outside interface happens to be at the time a packet arrives for translation.

Comments

[James Sneeringer]

Sorry, my answer made more sense before your edit. Your configuration now has you NAT'ing an IP to itself. This made sense on pre-8.3 systems as a static NAT exemption, but not on 8.4. Can you explain what you're trying to do?

[Astron]

Yes, if a request for TCP port 777 arrives at the outside interface, it is forwarded to host .125 on the internal network.

[James Sneeringer]

The VM object should be the internal IP, and the IP shown in the nat statement should be the external IP. In the current form form of your question, both are the same. If we talk about your unedited question, with 172.16.1.125 as the real/inside and 192.168.1.125 as the NAT/outside, all you need to do is change your access-list to refer to 172.16.1.125 instead of 192.168.1.125.

[Astron]

That was just a mistake, is there not a way to port forward without specifying an external IP address? The outside interface is DHCP and it would be tedious to change the rules every time the external address changes. Dis-regard the class-B network references.

[James Sneeringer]

My answer has been updated accordingly.

[James Sneeringer]

Output from packet-tracer indicates asymmetric NAT, which means your packet is matching different NAT statements in the inbound and outbound directions. What does the rest of your NAT configuration look like? Anything else that matches 192.168.1.125?

[James Sneeringer]

In your latest update, the drop is due to an implicit rule, which means some default condition not explicitly stated in your configuration caused it. This may be because the ASA is already using port 22 on its outside interface, and you lack an ssh statement permitting the connection. If this is the case, you will need to modify the outside mapped port to something the ASA doesn't use.

[Astron]

The device does use SSH though on the inside interface, regardless I changed everything to 555 and still have the same result. Any other ideas?

[James Sneeringer]

I duplicated the config I posted below on an otherwise bare 5520 running 8.4(2)8, using port 22 for everything, and it works fine for me (so my previous comment about port 22 and ssh is invalid). Can you post your complete (sanitized) config somewhere for us to see? And please verify the exact version you're using, since it's possible (though unlikely) that you're tripping over a bug. Also, when you run packet-tracer, make sure you specify the NAT/interface IP as the destination; using the real inside IP seem to be what triggers the drop due to rpf-check.

[Astron]

@JamesSneeringer I changed to port 555 in order to avoid conflict with the ASA service running on the ASA. 8.4(2) is the current version running on the device. Packet-trace has been updated as the internal interface was tripping the rpf-check.

[Astron]

@JamesSneeringer Update to 8.4(3) does not seem to of made a difference.

[Astron]

How is this any different than what I have in the original question?

[James Sneeringer]

Edited so the IP reflects your original question. I copied the wrong one into my answer.

[Astron]

Made the change and provided output from packet-tracer. Would the VPN config have anything to do with the denial?

[gravyface]

shudder no idea why Cisco went this route with their syntax.

[Weaver]

@gravyface Because once you cross the 100+ (in some configs 1000+) configuration objectives (be they NAT, ACL/ACE's, tunnels, etc) on an ASA using traditional ASA/PIX 7.x (through ASA 8.2) the weaknesses become apparent from a management standpoint. The 8.3+ forced objects, object-based NAT, real-ip in interface ACL's, and a lot of other 8.3+ features -- in the hands of a network engineer that plans configurations -- are very powerful. IMHO of course. :)

[gravyface]

Humble indeed. :/

[Astron]

@JamesSneeringer Problem was the hairpin NAT statement I have for the VPN. This was causing an issue with the correct port-forwarding rules you provided.

[James Sneeringer]

Nice catch! We don't have this kind of setup, so I was unfamiliar with after-auto.