Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PIX RDP

Status
Not open for further replies.

sharpy667

IS-IT--Management
Jun 10, 2005
18
GB
Looking for some advice on how to solve the following problem.

Have taken a fully working PIX and moved to new co-lo site and programmed with new public addressing. (See config below, this has been stripped and changed for security)

Problem: When I try to initiate a remote desktop connection from 86.47.29.223 to 72.25.6.111, the session doesn't connect and times out.

The following was captured on the PIX:

302013: Built inbound TCP connection 16 for outside:86.47.29.223/2929 (86.47.29.223/2929) to inside:10.18.1.1/3389 (72.25.6.111/3389)
pixfirewall# sh xlate
1 in use, 3 most used
Global 72.25.6.111 Local 10.18.1.1

ANY IDEAS WHY THIS ISN'T WORKING?


: Saved
:
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 DMZ1 security40
enable password *******************
passwd ***********************
hostname pixfirewall
domain-name ciscopix.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 ils 389
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 WEB_ACCESS permit ip any any
access-list OUT_IN permit icmp any any echo-reply
access-list OUT_IN permit tcp host 86.47.29.223 host 72.25.6.111 eq 3389
pager lines 24
logging on
logging timestamp
logging buffered debugging
logging trap debugging
mtu outside 1500
mtu inside 1500
mtu DMZ1 1500
ip address outside 72.25.6.100 255.255.255.224
ip address inside 10.10.10.1 255.255.0.0
ip address DMZ1 195.128.76.1 255.255.255.0
ip audit name idspolicy attack action alarm drop reset
ip audit name idsinfopol info action alarm
ip audit interface outside idspolicy
ip audit interface inside idsinfopol
ip audit info action alarm
ip audit attack action alarm
pdm logging debugging 100
pdm history enable
arp timeout 14400
global (outside) 1 72.25.6.103
nat (inside) 0 access-list My_Company
nat (inside) 1 10.18.0.0 255.255.0.0 0 0
static (inside,outside) 72.25.6.111 10.18.1.1 netmask 255.255.255.255 0 0
access-group OUT_IN in interface outside
access-group WEB_ACCESS in interface inside
route outside 0.0.0.0 0.0.0.0 72.25.6.99 1
route inside 10.18.0.0 255.255.0.0 10.10.0.1 1
timeout xlate 3:00: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
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
telnet timeout 5
ssh timeout 5
console timeout 0
terminal width 80
Cryptochecksum:**************************
: end
 
Did you look at the acl to see if it was taking a hit? Can you ping the 10.18.1.1 from the pix?
 
Hi,

The ACL takes a hit each time.

I have done more work and it appears that a SYN Timeout occurs after the default 2 minutes. This also happens if I try an SMTP connection.

I can ping both the source and destination from the PIX, so why doesn't the 3 way handshake take place?

Any help would be appreciated.
 
From the RDP server do a trace route toward the client. Does the traceroute travel through the PIX. Are there any other devices that could be filtering traffic in the path?

 
can you from your inside NW to RDP the Server ?

Mohamed Farid
[green]Know Me No Pain , No Me Know Pain !!![/green]
 
i would take a look at your fixups. make sure that it is not somehow causing the issue.
 
Hi Guys,

Thanks for all your input.

It turned out to be a routing issue.

Thanks

Chris
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top