Solved

pix 501 forwarding of Remote Desktop Web Connection

Posted on 2006-10-25
34
1,330 Views
Last Modified: 2008-01-09


I have a pix 501 that I want to configure to allow
web RDP connections.  I believe that web RDP runs
over port 80.

So, I need to configure the pix to forward port 80 traffic
to an internal IP.


A friend of mine set this up originally, but has since moved so I can't
get any more free support  ;)

There are references to a 172.16.99.0 network that I don't understand.
Can someone explain that to me?

Also, Does the overall config look ok?  Anything look funky?

setup:

I'm getting a dhcp address from my ISP.  The pix is behind the cable
modem and handling DHCP.  I have an internal static IP assigned to
the server I want to connect to.  The server is running server 2003.
Server IP is 192.168.99.100/24

Thanks!!!

pix config:

PIX Version 6.3(5)
interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ***** encrypted
passwd ***** encrypted
hostname pix
domain-name *****
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 ils 389
fixup protocol pptp 1723
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 101 permit ip 192.168.99.0 255.255.255.0 172.16.99.0 255.255.255.0
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside dhcp setroute
ip address inside 192.168.99.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 172.16.99.1-172.16.99.100
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list 101
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
conduit permit icmp any any
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 192.168.99.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
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup vpn address-pool ippool
vpngroup vpn split-tunnel 101
vpngroup vpn idle-time 1800
vpngroup vpn password ********
telnet 192.168.99.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 15
console timeout 0
dhcpd address 192.168.99.2-192.168.99.33 inside
dhcpd dns 68.1.208.245 68.1.208.30
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:*****
: end
0
Comment
Question by:trarthur
  • 17
  • 11
  • 6
34 Comments
 
LVL 30

Assisted Solution

by:Gareth Gudger
Gareth Gudger earned 20 total points
ID: 17808506
Well, I am a little rusty but here goes.... more to come I promise.

The references to

"ip local pool ippool 172.16.99.1-172.16.99.100"

This is an IP scope set aside four your VPN users. Every line that begins VPNGROUP, CRYPTO and ISAKMP are lines for your VPN. The reason your VPN uses a difference subnet than your regular inside users is this is just considered best practices from Cisco.

"access-list 101 permit ip 192.168.99.0 255.255.255.0 172.16.99.0 255.255.255.0 " connects your VPN users to your regular network. The reason why you separate the networks is so you can have access-lists between them to potentially restrict VPN access to your internal network.

I'll take a look at the rest. Sorry, again a bit rusty.
0
 
LVL 30

Expert Comment

by:Gareth Gudger
ID: 17808518
I'll have to find the lines for port forwarding because I don't remember what they are for a PIX. For some reason Cisco 2600 lines keep coming to mind but the IOS uses slightly different syntax so I know its wrong.

I'll look it up for you but I am thinking that RDP over web might also use port 443 (HTTPS / SSL) HTTPS is Secure HTTP or HTTP Secure Sockets I think. So we might need to open two ports.
0
 
LVL 30

Expert Comment

by:Gareth Gudger
ID: 17808560
I found this on a website and from memory this seems right. I don't have a PIX in front of me right now.

access-list inbound permit tcp any any eq 80
access-list inbound permit tcp any any eq 443
access-group inbound in interface outside
static (inside,outside) tcp interface www 192.168.1.100 www netmask 255.255.255.255

I've modified it a little but I believe those are the lines you need.

When done do a WRITE MEM, WRITE TERM
0
 
LVL 30

Expert Comment

by:Gareth Gudger
ID: 17808567
Sorry this should have read....

static (inside,outside) tcp interface www 192.168.99.XXX www netmask 255.255.255.255

The XXX is the IP address of your server hosting the RDP.
0
 
LVL 5

Author Comment

by:trarthur
ID: 17808618
diggisaur, thanks for the quick response.  I've added the lines and will test it out tomorrow from outside
my network.  
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17808973
If you're using "RDP over the web", aka RWW (Remote Web Workplace), the TCP ports you need to open up are 443, 444,  4125, maybe 80 if you don't want to use HTTPS.  I suggest using HTTPS instead of plain old unencrypted port 80.
   Example:
access-list inbound permit tcp any interface outside eq 80  <-- not recommended
access-list inbound permit tcp any interface outside range 443 444
access-list inbound permit tcp any interface outside eq 4125
access-group inbound in interface outside

static (inside,outside) tcp interface 80 192.168.99.100 80  <-- not recommended
static (inside,outside) tcp interface 443 192.168.99.100 443
static (inside,outside) tcp interface 444 192.168.99.100 444
static (inside,outside) tcp interface 4125 192.168.99.100 4125
clear xlate    <- very important! clears the NAT table

FYI, hopefully this won't be an issue, since your server doesn't seem to be running Exchange, but see this MS KB article on possible port 4125 conflicts on SBS server:   http://support.microsoft.com/?kbid=886209

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17812321
No luck accessing the web server.  I've verified that it is up and responding
from inside my LAN.

Is there logging in the PIX to see if there is a problem with the config?
0
 
LVL 5

Author Comment

by:trarthur
ID: 17812338
@diggisaur - thanks for the explanation of the 172 network.  Makes perfect sense.
0
 
LVL 5

Author Comment

by:trarthur
ID: 17815531
Since I've already applied the settings that diggisaur suggested, how do I un-apply them and apply the settings
that calvinetter suggested?
0
 
LVL 30

Expert Comment

by:Gareth Gudger
ID: 17815773
If you want to remove my lines you just type in that line but add the word prefix "no" in front of it. "no" undoes probably 90% of the config lines on a PIX 501.

So, "no access-list inbound permit tcp any any eq 80"

will take out that one line i told you.

I think calvinetter might be correct. :D
0
 
LVL 5

Author Comment

by:trarthur
ID: 17816198
Thanks diggisaur.  :)

I'll let everyone know how it turns out.
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17816506
Good luck!  If still having problems, please post your most current "sh run" output, sanitized with *** as you've done above.

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17816762
Well heck.  No love.  I began to wonder if the problem was the windows firewall on the host and the virtual machine I'm trying to connect to.
After disabling both, still no love.

I included port 80 in the config for the time being until I get things working.

Out of curiosity, I ran a web based port scan and all of the standard ports were closed except 21, SSH.
I ran it on the server and an XP box thinking I may get different results.  Then I realized that if it's not
getting past the perimeter, none of my tests will be any different.

Also, it just occurred to me that my ISP may not allow me to host a web server.  I'm using Cox.
I'll check their site and see if they explicitly deny that type of traffic.

Here is the running config:

Result of firewall command: "sh ru"
 
: Saved
:
PIX Version 6.3(5)
interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password**** encrypted
passwd **** encrypted
hostname pix
domain-name ****
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 ils 389
fixup protocol pptp 1723
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 101 permit ip 192.168.99.0 255.255.255.0 172.16.99.0 255.255.255.0
access-list inbound permit tcp any interface outside eq www
access-list inbound permit tcp any interface outside range https 444
access-list inbound permit tcp any interface outside eq 4125
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside dhcp setroute
ip address inside 192.168.99.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 172.16.99.1-172.16.99.100
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list 101
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface www 192.168.99.100 www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https 192.168.99.100 https netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 444 192.168.99.100 444 netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 4125 192.168.99.100 4125 netmask 255.255.255.255 0 0
access-group inbound in interface outside
conduit permit icmp any any
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 192.168.99.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
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup vpn address-pool ippool
vpngroup vpn split-tunnel 101
vpngroup vpn idle-time 1800
vpngroup vpn password ********
telnet 192.168.99.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 15
console timeout 0
dhcpd address 192.168.99.2-192.168.99.33 inside
dhcpd dns 68.1.208.245 68.1.208.30
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:****
: end

0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17817040
BTW, you should never mix conduits & ACLs on the same PIX.  Run this:
no conduit permit icmp any any
access-list inbound permit icmp any any echo-reply
access-group inbound in interface outside  <- re-apply ACL for good measure

  Other than that, the config looks fine.
  Did you run "clear xlate" after adding the static NAT entries?  Can you reach the Internet from the VM (virtual machine)? ie, ping, web surf, etc?  If not, then do you have a correct gateway set on the VM - ie, pointing to the inside IP of the PIX?  Is the VM itself doing NAT, firewalling or anything unusual with network traffic?
  Is there any router by chance between the PIX & the Internet?  ie, is your cable 'modem' just a modem or is it actually a router/modem?

  Also do this:
pix(config)#clear access-list inbound counters   <- resets ACL hitcount counters to 0
pix(config)#exit
pix#clear xlate
pix#clear local

  Now re-try that web-based port-scanning to your PIX's outside IP, then verify if your ACL hitcounts are increasing for the ports you've got open:
  sh access-list
 (should show lines similar to below):
 access-list inbound line 1 permit tcp any interface outside eq www (hitcnt=8)

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17818335
Ok.  I did this:

no conduit permit icmp any any
access-list inbound permit icmp any any echo-reply
access-group inbound in interface outside

and ran clear xlate after adding the NAT entries previously.  

I can ping and surf from the VM.  No henky stuff on the VM, jsut another node on the LAN.  VM's firewall is off
during all this.

The results after clearing the counters:

access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 256)
            alert-interval 300
access-list 101; 1 elements
access-list 101 line 1 permit ip 192.168.99.0 255.255.255.0 172.16.99.0 255.255.255.0 (hitcnt=0)
access-list inbound; 4 elements
access-list inbound line 1 permit tcp any interface outside eq www (hitcnt=0)
access-list inbound line 2 permit tcp any interface outside range https 444 (hitcnt=3)
access-list inbound line 3 permit tcp any interface outside eq 4125 (hitcnt=0)
access-list inbound line 4 permit icmp any any echo-reply (hitcnt=4)


I'm running the port scan here:

http://www.whatsmyip.org/ports/

I'm running the "basic security test"

Interestingly, all show blocked except for 21 as noted earlier, but 443 shows closed.

Thanks for your patience!!
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17823719
>I'm using Cox.
  If this is a residential account, then it's due to the ISP blocking traffic to your PIX.  I've confirmed with some others who are on Cox home accounts, & they've found most of the common server ports being blocked.  Not surprising, since they don't want the "average home user" setting up a server - whether due to security or other concerns, or simply that they want you to pay more $ for a business account.

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17824515
It is a non-commercial account.  

So, what if I set it up on some odd ball port?
0
IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

 
LVL 5

Author Comment

by:trarthur
ID: 17825379
I also just remembered that Cox sold out to Suddenlink in my area.
0
 
LVL 30

Expert Comment

by:Gareth Gudger
ID: 17825390
What is your external IP address? You can go to whatismyip.com and see this.

Is it 10.x, 172.x or 192.x then I can see a potential problem. The ISP is doing their own NATing.
0
 
LVL 5

Author Comment

by:trarthur
ID: 17825704
No, it's a 70.188.x.x so I'm good there.

I went to a different site to scan my ports and after actually reading the scan results in detail,
port  80 is invisible.  443 on the other hand is open and listening, so it looks like that will work for me.

http://probe.hackerwatch.org/probe/

Secure
21 (FTP)
This port is completely invisible to the outside world.

Secure
23 (Telnet)
This port is completely invisible to the outside world.

Secure
25 (SMTP Mail Server Port)
This port is completely invisible to the outside world.

Secure
79 (Finger)
This port is completely invisible to the outside world.

Secure
80 (HTTP)
This port is completely invisible to the outside world.

Secure
110 (POP3 Mail Server Port)
This port is completely invisible to the outside world.

Secure
139 (Net BIOS)
This port is completely invisible to the outside world.

Secure
143 (IMAP)
This port is completely invisible to the outside world.

Open and Unsecure!
443 (HTTPS)

If this computer is not supposed to be acting as a web server you should not have this port open.

Now the problem I'm having is getting https to work.  The website responds just fine over port 80.
When I configure IIS for SSL, I get page could not be displayed, etc...

This happens using localhost as the address from the server.

I realize this issue is out of the scope of my original question; should I leave this one open
until I resolve my IIS issue just to make sure the PIX is now correctly configured?
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17825785
>So, what if I set it up on some odd ball port?
  You could try that.  The PIX will let you redirect 1 port to another.  Example:

access-list inbound permit tcp any interface outside eq 7853
access-list inbound permit tcp any interface outside eq 9421  <- optional, only if 443 isn't reachable
access-group inbound in interface outside

no static (inside,outside) tcp interface 80 192.168.99.100 80
static (inside,outside) tcp interface 7853 192.168.99.100 80
static (inside,outside) tcp interface 9421 192.168.99.100 443  <- optional, only if 443 isn't reachable
clear xlate
clear access-list inbound counters

   Try the external port scan again, & see if your ACL hitcounts are increasing:
sh access-list inbound
   If it looks good for either port 7853 or 9421 (for port 80 & 443 access respectively), and also seems fine for 4125, then assuming your server is all setup, have someone from the outside try to connect via either 7853 or 9421, eg:
   http://4.3.2.1:7853/directoryname/    or   https://4.3.2.1:9421/directoryname  
   ( Replace "4.3.2.1" w/ your current IP, "directoryname" replaced with the correct part of the URL for your RWW server)

  ** For the external port scan, you *must* verify if TCP port 4125 is open (reachable) - this is the port that the RWW/RDP connection is used for.

>should I leave this one open until I resolve my IIS issue just to make sure the PIX is now correctly configured?
  The PIX is correctly configured at this point which is what your original question was about.  ;)

  Any issues w/ IIS & SSL should be put into another question - your PIX is correctly forwarding port 443 to your server, & if the port scan shows the port as open, the traffic is hitting your server.  From there, it's an IIS/Windows server issue.
  Personally, I'd make sure the basics were working, before dealing with SSL/HTTPS; make sure the server side is setup for RWW via port 80, & use the port redirection outlined above, & see if you can connect via RWW.

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17834352
I figured out the IIS issue.  Helps to have a cert installed.  ;)

But I'm still not able to get in via RDP.  I get to the RDP web connection page, type in the internal IP
of the server, hit go and I get:

Remote Desktop Disconnected.

the client could not connect to the remote computer.  Remote connections might not be enable or the computer might be too busy to accept new connections.  it is also possible that network problems are preventing your connection.  Please try later....blah blah.

I can hit the web page internally, type in the IP and get to the desktop to login successfully, so I know the server is configured correctly.

The hit count for 4125 has been increasing as well.  I'm at work so I can't confirm.  It was increasing over the weekend.  Is it possible that the PIX is blocking something else that needs to get through?



0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17839958
>I figured out the IIS issue.  Helps to have a cert installed.  ;)
  LOL, yes a cert would certainly help!

>I get to the RDP web connection page, type in the internal IP...
  Hmm, sounds like you're not accessing the correct page.  Point your browser to the default directory "remote", example below has the public IP as 4.3.2.1:
  https://4.3.2.1/remote/
You should then be presented w/ the "Remote Web Workplace" login page, with username & password input boxes, with a "Log On" button.

  Once logged into RWW, you don't need to enter IPs or hostnames, you'll simply be presented w/ a list of systems to connect to.

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17841166
The /remote/ path isn't found.  I'm using https://4.3.2.1/tsweb to access RDP over the web.
It may be that RWW and the /remote path are specific to SBS.  I'm using plain old server 03.
It's called Remote Desktop Web Connection.

I misspoke earlier when I said the hit counter was increasing.  I checked it again when I got home last night and it's still
at 1.  I know I tried more than once to access.

access-list inbound; 4 elements
access-list inbound line 1 permit tcp any interface outside eq www (hitcnt=0)
access-list inbound line 2 permit tcp any interface outside range https 444 (hitcnt=27)
access-list inbound line 3 permit tcp any interface outside eq 4125 (hitcnt=1)
access-list inbound line 4 permit icmp any any echo-reply (hitcnt=0)

0
 
LVL 20

Accepted Solution

by:
calvinetter earned 480 total points
ID: 17847161
>It may be that RWW and the /remote path are specific to SBS.  
    Correct.
>I'm using plain old server 03. It's called Remote Desktop Web Connection.
   That changes everything.  My mistake - I initially assumed this was an SBS 03 server, so I assumed it was RWW that you were trying to configure (haven't dealt with Remote Desktop Web Connection, only RWW, I assumed it was RWW. D'oh, never assume!).

   Doing some quick reading on "Remote Desktop Web Connection", looks like you'll need to open up the regular RDP port (TCP 3389) to the server.  And it sounds like you've installed the necessary AciveX control on the external client web browser for the actual RDP connection?
   Let's try some corrections (& hope Cox isn't going to block inbound TCP 3389 to your PIX!!):

no access-list inbound permit tcp any interface outside range 443 444
access-list inbound permit tcp any interface outside eq 443
access-list inbound permit tcp any interface outside eq 3389
access-group inbound in interface outside
clear xlate
no static (inside,outside) tcp interface 444 192.168.99.100 444
no static (inside,outside) tcp interface 4125 192.168.99.100 4125
static (inside,outside) tcp interface 3389 192.168.99.100 3389
clear access-list inbound counters

  Now, go back to your portscan site, & scan for TCP 3389 to see if it's open.  If so, then return to:  https://4.3.2.1/tsweb  and see if you can now access something via IP (or internal hostname if you have a local DNS server that can resolve it).

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17847556
I modified the config and was able to increase the hitcount on 3389.  I'll give it a try tomorrow.

I also did a clear access-list instead of a clear access-list inbound counters.  Ugh.  So I re-applied the
lines you gave above and the only ports open are 443 and 3389.  Both increase the hitcount
when I do a scan.

I may not be able to confirm access from work.  I remembered the perimeter firewall blocks everything
over 1024.  So I'll have to enlist some external help.  ;)

Thanks for your patience!  I think we are almost there!
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17847683
Ok, let us know how it goes.
0
 
LVL 5

Author Comment

by:trarthur
ID: 17878874
Ok.  I had some others try and access with the same result.  No love.
So, I reconfigured my internal network to put the web server outside the firewall and it picked up a public
IP.  I then had the same helpers try and hit the site, including a coworker.  Everyone was able
to get to the logon screen.  I put everything back the way it was, web server inside the LAN, private IP
PIX infront of everything.  No one could get in.

Also, the firewall on the server was enabled throughout the testing.  The exceptions are HTTPS
and Remote Desktop.

I'm really stumped at this point.  The hit counters are increasing on the PIX, the firewall on the server
is only allowing SSL and RDP.  Everything works fine up until I type in the server name and hit connect.

Short of putting a sniffer in between the cable modem and the PIX, is there a way in the PIX to see what
other ports are being dropped?  I keep coming back to the PIX being the problem child since it worked with the server configured with a public IP and the PIX out of the picture during my testing.

Thanks!!!
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17886568
>Everything works fine up until I type in the server name and hit connect.
   To get to the server when behind the PIX, you have to either specify the PIX's public IP that's NAT'd to the server, or if using a dynamic DNS service, specify the FQDN (ie "full hostname", such as mikeserver.dyndns.org) that resolves to this public IP.
   After your last batch of configuration changes, either run "clear xlate" or reboot the PIX.  If still having problems, post your latest "sh run" output (sanitized).

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17900329
>>To get to the server when behind the PIX, you have to either specify the PIX's public IP that's NAT'd to the server, or if using a dynamic DNS service, specify the FQDN (ie "full hostname", such as mikeserver.dyndns.org) that resolves to this public IP.
   When I get to the point where the RDP web page prompts for a server name, I type in my internal IP of the server.
Doing it that way was successful with the PIX out of the way.
I have a DDNS service setup and running on the server.  

Here is the config.  I ran clear xlate, but no luck.

Result of firewall command: "sh ru"
 
: Saved
:
PIX Version 6.3(5)
interface ethernet0 10baset
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password **** encrypted
passwd **** encrypted
hostname pix
domain-name ****
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 ils 389
fixup protocol pptp 1723
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 inbound permit tcp any interface outside eq https
access-list inbound permit tcp any interface outside eq 3389
pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside dhcp setroute
ip address inside 192.168.99.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 172.16.99.1-172.16.99.100
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp interface www 192.168.99.100 www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https 192.168.99.100 https netmask 255.255.255.255 0 0
static (inside,outside) tcp interface 3389 192.168.99.100 3389 netmask 255.255.255.255 0 0
access-group inbound in interface outside
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 sip-disconnect 0:02:00 sip-invite 0:03:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
http server enable
http 192.168.99.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
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup vpn address-pool ippool
vpngroup vpn split-tunnel inbound
vpngroup vpn idle-time 1800
vpngroup vpn password ********
telnet 192.168.99.0 255.255.255.0 inside
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 outside
ssh timeout 15
console timeout 0
dhcpd address 192.168.99.2-192.168.99.33 inside
dhcpd dns 68.1.208.245 68.1.208.30
dhcpd lease 3600
dhcpd ping_timeout 750
dhcpd auto_config outside
dhcpd enable inside
terminal width 80
Cryptochecksum:*****
: end

0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17903955
 Your config is correctly allowing TCP 3389 through the PIX to the internal server - note that the PIX will only let you specify the *public* IP of the server, since this is what is allowed in your ACL & what is configured in the static NAT statement.  It absolutely will not allow you to connect to the internal server by pointing to the private IP.
  Have you verified that you can get to the login screen of the server, using the separate RDP client (mstsc.exe) pointing to the public hostname/public IP of the PIX? If this fails, then your ISP is blocking inbound TCP 3389 to your server.  In which case you could change your static NAT statement to forward some other port from the outside to 3389 on the inside, like in a previous example where we forwarded TCP 9421 to 443.
   If direct RDP works, then you should be able to use that same public IP (or the DDNS hostname) in the input box of the web page to connect to the server.

  See the section - "Configuring Terminal Service for Web Access"
(not that step 1 & 4 use the same exact hostname/IP to connect to, which in your case you could use the current public IP of the server):
   http://www.microsoft.com/technet/itsolutions/smbiz/mits/rc/mit_rc_3.mspx

cheers
0
 
LVL 5

Author Comment

by:trarthur
ID: 17905397
I'll try the RDP client and let you know.  Thanks!
0
 
LVL 5

Author Comment

by:trarthur
ID: 17913497
The TS client worked great.  So did using the FQDN in the web interface.

Thanks for your help!
0
 
LVL 20

Expert Comment

by:calvinetter
ID: 17921801
Hoorah! We're finally in business!

cheers
0

Featured Post

Free Trending Threat Insights Every Day

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

Join & Write a Comment

Configuring network clients can be a chore, especially if there are a large number of them or a lot of itinerant users.  DHCP dynamically manages this process, much to the relief of users and administrators alike!
Meet the world's only “Transparent Cloud™” from Superb Internet Corporation. Now, you can experience firsthand a cloud platform that consistently outperforms Amazon Web Services (AWS), IBM’s Softlayer, and Microsoft’s Azure when it comes to CPU and …
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now