NAT problems with RDP

noktisnoktis · ‎10-29-2012

Hi there,

I'm a bit new to Cisco OS, and have been trying to setup NAT through my pix 501 to my test network. I've got a basic home network, on which most of my computers sit, and I want to control my lab via RDP. To that end, I've installed the 501 between my network and test network, and have gotten basic communication working. I just can't seem to open the port back to the server in my test network.

I understand that:

static (inside,outside) tcp interface 3389 "InsideServerIP" 3389 netmask 255.255.255.255

should do what I want it to do, but... it doesn't seem to work. I can't seem to get RDP working, and when I try to telnet to the port on the external interface IP address, it fails. I'm pretty sure that I've got something wrong in my NAT configuration, but am just too green in this area to spot it. Any ideas?

Here's my wr term info:

PIX Version 6.3(3)
interface ethernet0 100full
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100

hostname pixfirewall
domain-name testpix.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list ping_acl permit icmp any any echo-reply
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 192.168.0.20 255.255.255.0
ip address inside 192.168.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 192.168.0.0 255.255.0.0 0 0
access-group ping_acl in interface outside
route outside 0.0.0.0 0.0.0.0 192.168.0.1 1
timeout xlate 0:05:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 192.168.1.0 255.255.255.0 inside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
telnet timeout 5
ssh timeout 5
console timeout 0

terminal width 80

Jouni Forss · ‎10-29-2012

Hi,

Seems you havent allowed the traffic in the ACL you have attached to the "outside" interface

If you want to use the already existing ACL issue the following command

access-list ping_acl permit tcp any interface outside eq 3389

I think you should be able to use the keyword "interface outside"

If not issue

access-list ping_acl permit tcp any host 192.168.0.20 eq 3389

EDIT: You will naturally need the static NAT configuration you mention in the start of the post in addition to the ACL statement. Just thought as you dont have the NAT statement listed in the actual configuration you posted.

- Jouni

Jouni Forss · ‎10-29-2012

Also to clarify the situation abit,

Notice that your interface security-levels are 0 and 100

By default with Cisco PIX, ASA and FWSM products if you dont have any ACLs configured traffic will be allowed from networks/hosts behind higher security-level interface to networks/hosts behind lower security-level interface.

This is why your Labs hosts can connect to rest of your network.

But when you are trying to initiate connections from lower security-level interface/networks/hosts to higher security-level interface/networks/hosts you will almost always need an ACL list. (Connections coming through VPN connections that are taken to the local firewall can bypass the ACL totally in configured with certain command)

So for every connection you initiate from local network to lab network throug the PIX, you will need an ACL rule.

- Jouni

noktisnoktis · ‎10-29-2012

Thank you! I'm going to tinker with this tonight and will let you know how things go/send the thumbs up for the resolution. The explanation is brilliant too btw, understanding the why behind it will help me in the future. Greatly appreciated!

noktisnoktis · ‎10-29-2012

It did not seem to resolve the issue. Do I need to do anything after running the static and acl insert?

I confirmed in sh static that it was there, and sh access-list that it was listed as line 2.

I also noticed my NAT scope included my external subnet, and I think I should adjust that. Tried it, didn't help.

nat (inside) 1 192.168.1.0 255.255.255.0 0 0

Jouni Forss · ‎10-30-2012

Hi,

Well you can always do "clear xlate" on the lab PIX to clear all NAT translations there and then try again.

Can you see the "hitcount" increase in the access-list rule you added for the RDP?

Have you confirmed in the lab network that you can connect using RDP even there? Is there some settings on the remote computer that might prevent these connections?

If you got the Portforward configuration on the PIX and an access-list rule allowing the RDP connections, there shouldnt be anything else regarding the PIX that could cause the problems.

If you want to configure that there is NO NAT between the Lab network and your own network, you can do the following

configure NONAT / NAT0 / NAT Exemption configuration (configuration below)
after this remove all the rest of the NAT configurations and maybe do "clear xlate"

access-list LAB-INSIDE-NONAT permit ip 192.168.1.0 255.255.255.0 192.168.0.0 255.255.255.0

nat (inside) 0 access-list LAB-INSIDE-NONAT

What the above would do is that you could connect to the Lab network using the actual IP addresses of the devices.In other words the Lab network would be "visible" to your own network with their actual IP addresses. You will have to take into consideration ofcourse that your own networks router will have to have a route for the lab network pointing towards the lab PIX interface IP address for this to work. Also you would naturally need to use different IP addressess in the ACL rules also. (The actual IP addresses of the lab network)

BUT the configuration you had should work also. So there is no actual need to change to the above configuration. Just thought I'd throw it out there incase you want to try it out.

Its a shame the PIX is running on such a old software. I'm not sure if it even has the graphical interface for management (ASDM) which would make monitoring the connection attempts much easier compared to CLI = command line interface.

- Jouni

noktisnoktis · ‎10-30-2012

So I busted out Wireshark and started looking around, and ARP was also hitting the wrong MAC. I was pinging before, so... not sure what happened there, but I'll chalk it up to D-Link not being a terribly bright router.

Anyway, one static reservation in my external firewall later, things are running like clockwork. You friend, are legendary. Not only did you fix my problem, you taught me how ACLs integrate into the process. Thank you!

Jouni Forss · ‎10-31-2012

Hi,

Glad to be of help. Thanks for the rating also Always helps keep up the motivation to hang around the forums.

Can you mark the question as answered?

Dont hesitate to post new questions if you run into some problems with the PIX.

- Jouni