Cisco ASA 5505 Port Forwarding

PAT configuration:

hostname(config)# static (inside,outside) tcp <outside IP address> <outside port> <inside IP address> <inside port> netmask 255.255.255.255

ACL Configuration:

access list should be extended implemented in IN direction on OUTSIDE interface where destination address is the original (private) address since NAT on ASA is done before ACL lookup.

A couple of things:

I am not well versed in the CLI - so I generally use the ASDM GUI instead.

Also, it makes perfect sense to me that the access rule should specify the private address of the host as a destination, but when I looked at another ASA I had configured a few years back (which is still working properly with port forwarding), I noticed that its access rule was setup as described in my original post above.

Scratching my head.  

???

Hi Chris,

Kindly share the rule configured.

Refer the below links if it helps:

i)
https://blog.beezwax.net/2011/02/04/port-forward-for-a-cisco-asa-using-asdm/
ii)
https://blog.lan-tech.ca/2012/01/22/configure-cisco-asa-for-sbs-20082011-network/ (port forwarding section)
Check if you are able to share the CLI config of the same.

Mr. Curic is mistaken when stating that NAT is done before ACL in your case. This is true for ASA software 8.3 and higher, but on the one you are using, the reverse is true.
I'm terrible at ASDM, but here a a few examples on doing PAT using CLI. If you can get a single one working, you can see how it looks in ASDM and replicate more from that. I'm using an access-list on the outside interface called "outside-in", but please replace with whatever yours is called.

Using the firewall's own outside ip address to forward port 8000 to inside host 192.168.1.100 from any internet address:

static (inside,outside) tcp interface 8000 192.168.1.100 8000 netmask 255.255.255.255
access-list outside-in extended permit tcp any interface outside eq 8000

Same example, but using a separate public ip address (1.2.3.4):

static (inside,outside) tcp 1.2.3.4 8000 192.168.1.100 8000 netmask 255.255.255.255
access-list outside-in extended permit tcp any host 1.2.3.4 eq 8000

Regarding the software version you are running, I feel obliged to point to this article:
Buffer overflow vulnerability

It is a highly critical issue, and even if you don't have a valid service contract for the firewall, you can request the fixed version mentioned in the article.

Kellemann -

As usual, thank you for the succinct and useful comment.  However, there is one thing I am unsure of: you mention an "access list". I'm afraid I don't know what you're referring to.  Where would I find such an access list?  Do I have to create it from scratch?  if so, what items should it include?

Any guidance would be greatly appreciated.

Thx.

Access-lists are, among other things, the rules which govern access between zones. I fired the ASDM up on my own firewall to see where the name of the access-list was stated. Turns out: it isn't. You have to right-click on the outside interface when in the Configuration -> Access Rules menu, and select "Rename ACL". That gives you the current name of the list.
In the CLI you can type "show run access-group" to get the information. In my case that gives you:

access-group outside-in in interface outside

Ok, thanks as always. You are really very helpful and you explain things clearly. I will give your suggestions a try in a little while and report back my results.

Thx.

Okay, I checked and found out that my outside interface ACL was named "outside_access_in". I then issued the commands you suggested from the CLI and saved the running configuration to flash afterward. Still couldn't connect.

Then I decided to take a look in the ASDM to see the results of those commands.  I found a static NAT rule that looked exactly as I would have suspected. But there was no new access rule.  So, I renamed the outside interface ACL to "outside-in" just as in your example, then copied and pasted your command, changing only the port number to 3389 for RDP access. Still no good and I still couldn't see the new access rule listed in ASDM.  

Then, I decided to create that access rule directly in the ASDM and save the running configuration to flash. Afterward, I could see my new rule but I still couldn't connect.  Interestingly the attempted RDP connection failed instantly this way - whereas with the other attempts it just finally timed out.

Any ideas?  This is getting quite frustrating.

Your input would be greatly appreciated.

Thx.

Also, as per the request of Ian Arakel, here are the results of a sh config command from the CLI:

Result of the command: "sh config"

: Saved
: Written by enable_15 at 19:11:40.974 UTC Wed Mar 9 2016
!
ASA Version 8.2(1)
!
hostname ciscoasa
enable password /rRr7L4Re9LA80Jz encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
name 192.168.1.0 dmz_outside
!
interface Vlan1
 nameif inside
 security-level 100
 ip address 10.0.0.1 255.0.0.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 108.58.161.138 255.255.255.252
!
interface Vlan3
 no forward interface Vlan1
 nameif dmz
 security-level 50
 ip address 192.168.1.254 255.255.255.0
!
interface Ethernet0/0
 switchport access vlan 2
!
interface Ethernet0/1
!
interface Ethernet0/2
!
interface Ethernet0/3
 switchport access vlan 3
!
interface Ethernet0/4
 switchport access vlan 3
!
interface Ethernet0/5
 switchport access vlan 3
!
interface Ethernet0/6
!
interface Ethernet0/7
!
boot system disk0:/asa825-k8.bin
boot system disk0:/asa821-k8.bin
ftp mode passive
object-group network obj_any
object-group protocol TCPUDP
 protocol-object udp
 protocol-object tcp
object-group service TCP-RDP tcp
 description For Remote Desktop
 port-object eq 3389
access-list outside_access_in extended permit tcp any interface outside eq 3389
access-list outside-in extended permit tcp any interface outside eq 3389
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
mtu dmz 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 101 interface
nat (inside) 101 0.0.0.0 0.0.0.0
nat (dmz) 101 0.0.0.0 0.0.0.0
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
route outside 0.0.0.0 0.0.0.0 108.58.161.137 1
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
dynamic-access-policy-record DfltAccessPolicy
http server enable
http dmz_outside 255.255.255.0 inside
http 10.0.0.0 255.0.0.0 inside
no snmp-server location
no snmp-server contact
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd auto_config outside
!
dhcpd address 10.0.0.100-10.0.0.200 inside
dhcpd dns 167.206.112.138 167.206.7.4 interface inside
dhcpd lease 86400 interface inside
dhcpd enable inside
!
dhcpd address 192.168.1.25-192.168.1.125 dmz
dhcpd dns 167.206.112.138 167.206.7.4 interface dmz
dhcpd lease 86400 interface dmz
dhcpd enable dmz
!

threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
  message-length maximum client auto
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
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:817f1ca7f520366094d3f3c9352ad877

One other interesting tidbit:  I thought it might be good to upgrade the ASA and ASDM to somewhat more current versions.  But when I tried, I got an error that disk0: didn't have enough space.  So then I did a dir disk0: and found a couple of bin files of newer ASA and ASDM versions that were not in use. So I tried to use the boot system and asdm image commands to take advantage of them. But afterwards the unit wouldn't start up properly and I couldn't gain any access to the ASDM at all - so I had to revert back. Then I tried deleting those bin files so I could replace them with even newer versions which I have on my local computer.  However, the delete commands failed indicating that no such filenames existed.  I double and triple checked and the filenames were right.

I am so confused and frustrated!

Mr. Arakel is right about the missing "access-group" command.

Regarding the software versions you found on the flashdisk. Be careful which version you upgrade to. Everything from version 8.2 and lower use the same command syntax in general. If you try and upgrade to 8.3 or higher, it will automatically convert the configuration to a new syntax for especially NAT and things might not work as expected.

8.3 and higher also require more RAM on the firewall. Early models of 5505 had only 256 MB. Later revisions were born with 512MB which is the minimum required for 8.3 and higher.

Because of the RAM limit the old 8.2 version is still being updated with security fixes like in the link I sent earlier. It is just feature-frozen, nothing new is added.

Thank you, both. You are obviously very knowledgeable.  Of course, it seems that each question you answer raises two more, LOL!  Sorry, but I am just such a novice at this.

In any case, how do I delete the access list called "outside-in"? (recall that I cannot see it in ASDM for some reason) Will I have to issue a delete command of some sort in the CLI?  Or would I actually just be renaming it back to "outside_access_in" - - - which can be done by a right-click on the outside interface in Configuration>Firewall>Access Rules in ASDM as pointed out by Kellemann? I just want to make sure I don't delete something by mistake.

Also, if I were doing this again from scratch (i.e. if I hadn't already created the NAT rule), would I issue the following three commands?

static (inside,outside) tcp interface 3389 10.0.0.201 3389 netmask 255.255.255.255
access-list outside_access_in extended permit tcp any interface outside eq 3389
access-group outside_access_in in interface outside

. . . or does the access-group command replace the access-list command entirely?

As to the potential upgrade of the device: it actually does have 512 MB of RAM already.  I think I assumed that new versions of the ASA and ASDM might be less temperamental and more secure as well. Any ideas why they wouldn't work properly when I tried them and why they couldn't be found when I tried to delete them (even though they are clearly listed in the output of a dir disk0: command)?

Also, I noticed in the output of sh config that there are two instances of the boot system entry, each specifying a different ASA version.  Like this:

boot system disk0:/asa825-k8.bin
boot system disk0:/asa821-k8.bin

Isn't that odd? Shouldn't there be only one?

Anyway, as always, thanks for all the great information!

Interesting stuff.  So, here's what I've done:

Eliminated the access list entry called "outside-in" by issuing this command:

no access-list outside-in extended permit tcp any interface outside eq 3389

Then I checked to make sure the ACL on my outside interface was still called "outside_access_in".  It was.  Good so far.

Then, having kept my original Static NAT rule, I issued these two commands, one after the other:

access-list outside_access_in extended permit tcp any interface outside eq 3389
access-group outside_access_in in interface outside

Sadly, my RDP connection from a host outside to the specified host inside still isn't working. So, as per your suggestion, I ran the tracer.  here is its output:

Result of the command: "packet in outside tcp 10.0.0.250 3389 108.58.161.138 3389"

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
  match tcp inside host 10.0.0.250 eq 3389 outside any
    static translation to 108.58.161.138/3389
    translate_hits = 0, untranslate_hits = 74
Additional Information:
NAT divert to egress interface inside
Untranslate 108.58.161.138/3389 to 10.0.0.250/3389 using netmask 255.255.255.255

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any interface outside eq 3389
Additional Information:

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

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
  match tcp inside host 10.0.0.250 eq 3389 outside any
    static translation to 108.58.161.138/3389
    translate_hits = 0, untranslate_hits = 74
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (sp-security-failed) Slowpath security checks failed

I have no idea what "Slow Path" security is. Any thoughts?

Thanks so much. You have been giving me quite a thorough education.

The slowpath security happens because you put in the internal ip address of the RDP server as the source. That means you are simulating the internal server trying to access the outside ip and then reaching itself on the inside again. So you kinda went a little "Inception" on the firewall there :-)
Just put it any random public ip address (like 1.2.3.4) and try again.

Kellemann -

Here is the output of the tracer with the 1.2.3.4 source address:

Result of the command: "packet in outside tcp 1.2.3.4 5555 108.58.161.138 3389"

Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
  match tcp inside host 10.0.0.250 eq 3389 outside any
    static translation to 108.58.161.138/3389
    translate_hits = 0, untranslate_hits = 136
Additional Information:
NAT divert to egress interface inside
Untranslate 108.58.161.138/3389 to 10.0.0.250/3389 using netmask 255.255.255.255

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit tcp any interface outside eq 3389
Additional Information:

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

Phase: 5
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
  match tcp inside host 10.0.0.250 eq 3389 outside any
    static translation to 108.58.161.138/3389
    translate_hits = 0, untranslate_hits = 136
Additional Information:

Phase: 6
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
static (inside,outside) tcp interface 3389 10.0.0.250 3389 netmask 255.255.255.255
  match tcp inside host 10.0.0.250 eq 3389 outside any
    static translation to 108.58.161.138/3389
    translate_hits = 0, untranslate_hits = 136
Additional Information:

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

Phase: 8
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 83206, packet dispatched to next module

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

Is there anything telling here?

Thanks much!

Yep, it says you did everything right, the firewall will allow the traffic and address translate to the correct address.
I think the last missing bit might be on the server itself. If the Windows firewall is enabled, and it usually is by default, it might allow other internal clients to access it via RDP, but addresses that are foreign are not allowed. Try disabling the firewall. If that does the trick, re-enable it if needed and make an exception for RDP from foreign subnets.

Hmmm... actually already did that, quite a while back in the history of this thread.

Scratching my head now.

:-(

Oops.  I realize now that I inadvertently left the 5555 in the tracer command from your example. Should that have been 3389?

C-

Sorry no, that should be a random port.

Well, I am at a loss.  I just now double checked and my Windows firewall is off for all networks public and private. Remote access is enabled and the specified user account has permissions.

When I try to RDP, the connection attempt times out.  It doesn't fail instantly anymore (like it was doing before I had the NAT and Access Rules configured properly).

Maybe I should refocus my energies on the version of ASA - and try the security-fix version that was suggested earlier.

???

Hi Chris,

Thanks for your acknowledgements to our posts.
Kindly confirm the below:

i)
Are you able to RDP to the server from within a machine the network?

ii)
The packet tracer logs indicate that the firewall is allowing the traffic.
Kindly test the RDP from outside and check the real time firewall logs to identify if the same is getting blocked on the firewall.
The below tool could be used for external RDP verification:
http://ping.eu/port-chk/

iii)
Check the above point by temporarily allowing the below access list and then deleting it immediately once the testing is done.

access-list outside_access_in extended permit ip any any.

I swear I will leave you guys alone soon.  I'm sure you must be sick of me at this point.

Okay, so after testing RDP from inside the LAN (and having it work perfectly) I really went deeper into troubleshooting and realized that the "server" I was trying to connect to had a non-standard RDP listening port.  Since I always tested it inside the LAN from a pre-existing desktop shortcut, I simply never noticed.

*bangs head against wall*

So, then I thought I could use everything you've both taught me and modify my NAT and access rules accordingly.

SUCCESS!!

Thank you, thank you, thank you to both of you!

Now wish me luck as I attempt to create the other rules I need for access to other resources here on my inside VLAN.

I hope I can figure out how to award points to both of you as you've both been an immense help to me.  :-)

Best,
Chris

Terrific input from two very helpful members of the Experts-Exchange community. Thank you!