I have this:
access-list incoming permit tcp any host 18.104.22.168 eq 3389
access-group incoming in interface outside
static (inside,outside) 22.214.171.124 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...
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?
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.
P# sh capture test | grep 3389
12:51:43.416604 126.96.36.199.51878 > 192.168.1.6.3389: S 2147383931:2147383931(0) win 65535
12:51:46.342984 188.8.131.52.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:
clear capture test
Initiated RDP connection, then got:
P# sh capture test | grep 3389
12:55:57.439384 184.108.40.206.51904 > 192.168.1.11.3389: S 4198845700:4198845700(0) win 65535
12:56:00.394236 220.127.116.11.51904 > 192.168.1.11.3389: S 4198845700:4198845700(0) win 65535
12:56:06.412713 18.104.22.168.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!
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?
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.
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 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.