ASA 5520 8.3 Static NAT and Remote desktop

[mhobart2]

Hello,

I have just setup a new ASA 5520 with 8.3 OS.   I have it setup very basic with 3 interfaces;  outside, inside, and management.  I have it setup so any users on the inside can get to the internet on the "outside"  with Dynamic NAT.  However I am having a difficult time getting a simple static NAT to work so I can do a "Windows Remote Desktop" to a test machine on the inside.   I have the test machine setup as 10.12.37.62 and it's doing a static NAT to 208.125.74.20.   When I go to www.whatsmyip.org on that machine it shows up correctly as 208.125.74.20.  However, I can't ping or remote desktop the 208.125.74.20 from the outside.  We have a bank of five ip addresses assigned by our isp:  208.125.74.17-21 .....   208.125.74.19 is the address of the outside interface.

Any help would be greatly appreciated.  Here is the running config:

ASA Version 8.3(1)

!
interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 10.12.47.54 255.0.0.0
!
interface GigabitEthernet0/1
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/3
nameif outside
security-level 100
ip address 208.125.74.19 255.255.255.248
!
interface Management0/0
nameif management
security-level 100
ip address 172.16.160.114 255.255.240.0
management-only
!
boot system disk0:/asa831-k8.bin
ftp mode passive
same-security-traffic permit inter-interface
object network obj_any-01
subnet 0.0.0.0 0.0.0.0
object network testremote
host 10.12.37.62
object network outtest
host 208.125.74.20
object network Discipline
host 10.12.37.62
object-group protocol TCPUDP
protocol-object udp
protocol-object tcp
object-group network obj_any
access-list outside_in extended permit ip any object testremote
pager lines 24
logging asdm informational
mtu inside 1500
mtu outside 1500
mtu management 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-631.bin
no asdm history enable
arp timeout 14400
!
object network obj_any-01
nat (inside,outside) dynamic interface
object network testremote
nat (inside,outside) static outtest
access-group outside_in in interface outside
route outside 0.0.0.0 0.0.0.0 208.125.74.22 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 172.16.160.0 255.255.255.0 management
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
telnet 172.16.160.0 255.255.255.0 management
telnet timeout 5
ssh timeout 5
console timeout 0
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
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
  inspect icmp
!
service-policy global_policy global
prompt hostname context
call-home
profile CiscoTAC-1
  no active
  destination address http https://tools.cisco.com/its/service/oddce/services/DD
CEService
  destination address email callhome@cisco.com
  destination transport-method http
  subscribe-to-alert-group diagnostic
  subscribe-to-alert-group environment
  subscribe-to-alert-group inventory periodic monthly
  subscribe-to-alert-group configuration periodic monthly
  subscribe-to-alert-group telemetry periodic daily
Cryptochecksum:043abf24817b83ee0c25d5349e9312c3
: end

[mirober2 · Accepted solution]

Hi Matt,

The configuration looks correct. Can you please verify with packet-tracer that everything is being matched correctly? Try 'packet-tracer in outside 1.1.1.1 12345 208.125.74.20 3389'.

Also, I would recommend doing 'capture arp ethernet-type arp interface outside' and 'show cap arp' to look at any ARP requests that are generated when you try to connect. If you see a lot of unanswered ARP requests for 208.125.74.20, you may be running into the following bug:

CSCti38867 - ASA: May not proxy arp on certain interfaces

You might also try changing the NAT configuration to use your outside interface IP as the global address, rather than another address in that pool. If that works, it would point to an ARP or routing problem for 208.125.74.20.

Hope that helps.

-Mike

[mhobart2]

Thanks for the quick response mirober2.   Here are the results for the packet-tracer:

ciscoasa(config)# packet-tracer in outside tcp 1.1.1.1 12345 208.125.74.20 3389

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
object network testremote
nat (inside,outside) static outtest
Additional Information:
NAT divert to egress interface inside
Untranslate 208.125.74.20/3389 to 10.12.37.62/3389

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_in in interface outside
access-list outside_in extended permit ip any object testremote
Additional Information:

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

Phase: 4
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network testremote
nat (inside,outside) static outtest
Additional Information:

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

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 558, 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

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

Here are my captured results:

ciscoasa# capture arp ethernet-type arp interface outside
ciscoasa# sh cap arp

5 packets captured

   1: 13:52:36.535281 arp who-has 208.125.74.17 tell 208.125.74.22
   2: 13:52:36.540407 arp who-has 208.125.74.19 tell 208.125.74.22
   3: 13:52:36.540453 arp reply 208.125.74.19 is-at d0:d0:fd:4:22:89
   4: 13:52:36.545290 arp who-has 208.125.74.20 tell 208.125.74.22
   5: 13:52:36.545366 arp reply 208.125.74.20 is-at d0:d0:fd:4:22:89
5 packets shown

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

When I changed the NAT rule to point to the outside interface, it worked perfectly.  So the problem must be with the routing?  Any suggestions?

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

[mirober2 · Accepted solution]

I tried a traceroute to both addresses and both times I ended up at the same last hop so it would appear that routing is working. Plus the next hop device is definitely trying to send some kind of traffic (obviously we don't know if this is the 3389 traffic) to the global .20 address since we see it sending ARP requests.

Is it possible there is an ACL somewhere upstream that limits 3389 traffic to only .19 and not .20?

Try setting up some packet captures so you can get a better idea of exactly what is failing:

capture capin interface inside match tcp host 10.12.37.62 eq 3389 any

capture capout interface outside match tcp host 208.125.74.20 eq 3389 any

show capture capin

show capture capout

-Mike

[mhobart2]

Sorry for the delay.  There was another router upstream in the same subnet.  While it wasn't blocking anything, it must have been interfering with the routing.  I just had to restart that router and the ISP's modem.  Everything is working great now!  Thanks again Mike!