topic Re: Quick ACL question: in Network Security

Quick ACL question:

scott.bridges — Mon, 11 Mar 2019 14:50:09 GMT

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...

Re: Quick ACL question:

eddie.mitchell — Fri, 13 Feb 2009 14:23:10 GMT

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?

Re: Quick ACL question:

scott.bridges — Fri, 13 Feb 2009 14:29:55 GMT

Sorry,

Still relatively new to PIX/ASA's.

Could you post a link on how to run a capture?

Re: Quick ACL question:

eddie.mitchell — Fri, 13 Feb 2009 14:47:08 GMT

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.

Re: Quick ACL question:

scott.bridges — Fri, 13 Feb 2009 21:22:38 GMT

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!

Re: Quick ACL question:

eddie.mitchell — Fri, 13 Feb 2009 21:25:28 GMT

Yep, looks great. You're welcome.

Re: Quick ACL question:

scott.bridges — Wed, 18 Feb 2009 04:56:57 GMT

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?

Re: Quick ACL question:

eddie.mitchell — Wed, 18 Feb 2009 12:43:29 GMT

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.

Re: Quick ACL question:

JamesLuther — Wed, 18 Feb 2009 13:01:49 GMT

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

Re: Quick ACL question:

scott.bridges — Thu, 19 Feb 2009 16:25:08 GMT

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!