02-13-2009 06:14 AM - edited 03-11-2019 07:50 AM
I have this:
access-list incoming permit tcp any host 2.35.43.84 eq 3389
access-group incoming in interface outside
static (inside,outside) 2.35.43.84 192.168.1.11 netmask 255.255.255.255 0 0
192.168.1.11 is up and running and accepting RDP sessions, but when I try to RDP to the x.84 address, it times out.
Am I missing something? It seems simple...
02-13-2009 06:23 AM
Looks correct to me. Have you tried running separate captures on both the outside and inside interfaces to see if the RDP traffic is traversing the firewall? Anything interesting in the log buffer?
02-13-2009 06:29 AM
Sorry,
Still relatively new to PIX/ASA's.
Could you post a link on how to run a capture?
02-13-2009 06:47 AM
I would just do something simple like:
capture test interface inside
initiate some RDP traffic
sh capture test | grep 3389
when you're done, don't forget to do 'no capture test'
You can enable the log buffer in global config mode via:
logging buffered info
sh log | grep
no logging buffered info (when you're done"
Hope this helps.
02-13-2009 01:22 PM
P# sh capture test | grep 3389
12:51:43.416604 4.7.9.34.51878 > 192.168.1.6.3389: S 2147383931:2147383931(0) win 65535
12:51:46.342984 4.7.9.34.51878 > 192.168.1.6.3389: S 2147383931:2147383931(0) win 65535
Wow! Very helpful stuff!
Looks like the RDP traffic is still being redirected to 192.168.1.6 (it was like this previously).
And I just did:
wr mem
clear capture test
clear xl
Initiated RDP connection, then got:
P# sh capture test | grep 3389
12:55:57.439384 4.7.9.34.51904 > 192.168.1.11.3389: S 4198845700:4198845700(0) win 65535
12:56:00.394236 4.7.9.34.51904 > 192.168.1.11.3389: S 4198845700:4198845700(0) win 65535
12:56:06.412713 4.7.9.34.51904 > 192.168.1.11.3389: S 4198845700:4198845700(0) win 65535
So does this mean it's getting forwarded correctly? Because I'm still able to RDP into another server on the network, then RDP into that 192.168.1.11 server.
Thank you so much for the logging tip. MUCH appreciated!
02-13-2009 01:25 PM
Yep, looks great. You're welcome.
02-17-2009 08:56 PM
Ok,
So I'm still having the same problem. I do the logging tip as mentioned and it seems that 3389 traffic is getting through, yet I am not getting any connection. It keeps timing out.
I tried changing the LAN address to another server and the same thing happens. Both of these LAN servers *definitely* work. I am able to RDP into them via our other PIX (this current PIX is on the secondary line, different ISP) from the outside.
So the server is accepting 3389, the PIX appears to be passing traffic.
What else could it be? Are the above log lines indeed passing traffic?
02-18-2009 04:43 AM
At this point, I'm really not sure what it could be. So the RDP traffic is leaving the inside interface destined for the server, but you're not receiving a reply. I'd say it appears to be something server-side related. Does the server have any host based restrictions? Does it only accept RDP connections from a list of authorized hosts?
At this point, I'd probably put Windump on the server and validate that the RDP traffic was arriving.
02-18-2009 05:01 AM
Hi,
Is the server on the same subnet as the ASA? Are the reply packets deinitely being routed back in the right direction?
Check the routing table on the server and any hops in between.
Thanks
02-19-2009 08:25 AM
Thanks for all the replies.
This is a Windows Server 2008, so I wasn't sure about installing Windump on this as I couldn't find much about support. Didn't want to hose the machine.
While the routing table is ok, this was definitely the write direction.
So we have two PIX firewalls. I was setting up this RDP access through the PIX2 just in case PIX1 went down. When RDP traffic was initiated through PIX2, the server was apparently responding out of it's default gateway (of course) which was PIX1.
I changed the default gateway on the server to PIX2 and RDP connected fine.
Works!
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: