Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

I am unable to Telnet/SSH/RDP from my inside network to my DMZ. I am not sure where the problem lies, I am able to use VNC from the inside to the DMZ (ports 5800, 5900), and also establish connection on Ports (26700-26899).

I have a computer connected directly to the DMZ and those services work to all networks on the DMZ.

I have attached Logs of successful VNC connections, unsuccessful RDP and Telnet sessions, and the running config.

Thank you

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Glad to hear that.

To summarize our troubleshooting. We took captures on both interfaces of the firewall and the host that is initiating the connection. Then, we look at the captures (on pcap format using wireshark) and we saw that there were RST packets that were not generated on the host. We looked at the mac-addresses an we found out that for the packets of the connection, the mac-addresses were showing the PC mac-address but for the RST flag on the tcp packets, they were coming from another mac-address which turned out to be a Webesense server.

I am glad that we were able to narrow down the problem, in case you need further assistance, do not hesitate to reply to this post, also if you consider that this post helped you out to find the solution, mark it as solved, so other people can follow the same line of troubleshooting.

Thanks!

Mike

Mike
23 REPLIES

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hello Michael,

If you can do VNC to the DMZ host that let us know the communication between both areas is allowed, now I would like to do some packet tracers and if that does not help perform some captures.

Packet-tracer input inside tcp x.x.x.x.x(inside_host_ip) 1025 y.y.y.y(DMZ_HOST_IP) 3389

Packet-tracer input inside tcp x.x.x.x.x(inside_host_ip) 1025 y.y.y.y(DMZ_HOST_IP) 23

Please give us the output of both packet tracers

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Gold

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hi

First of all remove that config and sanitize it and change all the passwords and preferably the usernames also.

and do that immediately !

This is a openforum that anyone can access, you do not know who is watching or what they might use the information for.

and YES the passwords can be decoded.

ok.

you can access the server through some ports but not others.

Have you checked that it is not the windows firewall on the server that you are trying to access that is the problem ?

Good luck

HTH

New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Thanks Hobbe,

I did not even think about the passwords in the configs.

I checked the windows firewalls that is not the issue, I am having the same issue when telneting to switches and routers on the other side as well.

Thanks again

New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Thanks Julio,

I attached the packet Tracers and captures were included previously.

Thanks,

Mike

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Can you download the captures via pcap?

Regards,

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Pcaps added

Thanks,

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hello Michael,

After checking these captures I can tell you that the problem is not with the firewall, the problem is with the PC 192.168.2.41 because it sends a reset packet after the TCP connection gets established with the 3 way handshake.

You can take a look at the captures using wireshark and you are going to see the RST packet.

I hope this help you,

Have a great day.

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Thanks Julio,

That is what I was seeing as well, just wanted a second set of eyes.  Wated to make sure I was not missing anything. 

Thanks again,

Mike

New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Julio,

I just ran a capture on the local machine 192.168.2.41 and that is showing a rst packet being sent by equipment on the other side of the dmz

Thanks,

Mike

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hello Michael,

Really that is an extrange behavior, can you run a capture on the other machine as well just to confirm.

Have a good day,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

I dropped the capture - pc_capture.pcap.zip

Thanks,

Mike

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hello Michael,

And what happen if you try to access another PC on the same port on that network??

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Julio,

I am getting the same issue from all PC on the inside to all equipment in the DMZ

Thanks,

Mike

Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

We cannot dicard or give as a fact that the problem is/isnt the firewall. From what you can see, there is a RST packet coming from the Host on the DMZ, however, we dont know for sure that the host is in fact sending the packet, it could be something in between or even the firewall.

Windows firewall is indeed not the problem, if it was, it would not complete the handshake.

The only way to rule out the firewall would be one of two things,

Either place a capture like you did but on the receiving host or

Apply captures on the ASA Firewall on the Inside as well on the DMZ, download them with wireshark and check who is the one sending the RST packet.

Here is how you can take captures:

https://supportforums.cisco.com/docs/DOC-1222

Gather them, once you have it post them here.

Mike

Mike
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Hi Mike,

I just completed the captures and add attached them above.

Captures are from

Inside PC 192.168.2.41 (NAT on DMZ Side 38.109.106.11)

firewall on inside

firewall in DMZ

DMZ PC 38.109.106.25

Thanks,

Mike

Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Michael,

There seems to be an issue, you say that host 192.168.2.41 is translated to 38.109.106.11, well that aint happening. The capture on the DMZ side should reflect IP address 38.109.106.11 as the source, however, is still showing the 192.168.2.41 address. Another interesting fact is that on the capture of the DMZ, I should see a mac address that start with the Cisco mac identifier, however, I am seeing an HP mac-address.

Di you took the capture of the DMZ side on the DMZ interface? My guess is that something went wrong while doing the capture and you took both on on the inside interface.

Mike

Mike
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Thanks Mike,

There was an error ont he DMZ capture, I updated the files thanks.

Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Michael,

For future captures you take, try making them simultaneous, both at the same time so we can see which packets passed across fine and which ones didnt.

Now doing reference to the capture, I can see a packet that states connection request from 38.109.106.11 towards the server on the DMZ, but inmediatly I see a RST packet. Now, since the captures were not taken at the same time it is unknown if the RST was send by the ASA or the client. After that, everything is normal, since the connection was closed  on the ASA, the server (Dont know why) sent a connection confirm, and it keeps retransmitting the packet until he reaches the timeout of not hearing an acknowledgement.

Very sensitive problem here. I need you to do a couple of things for me, try running this simultaneously:

Gather another set of captures (Inside and DMZ) and put the keyword trace at the end of them.

Gather a capture of type asp drop you can do that by doing the following:

  capture ASP type asp-drop all

Gather the logs while doing the connection.

Now once you see the connection fail, go ahead and do a "show cap ASP" and then download the 3 captures on pcap format, after you upload the captures, I will take a look at them and ask you to run one more command with the captures, that is why it is vital for you to not erase them.

Dont worry, the captures have a buffer set and they wont cause any performance problems on the ASA.

Let me know if it is possible.

Mike

Mike
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Mike,

Thanks for all the help.  I have attached the new logs as you requested.

This is a strange issue and I can not figure out what is going on.

Thanks again,

Mike

Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Gotcha!

There is device in between closing the connection for you on the inside Segment of the network. It has the mac-address 0021.5e53.478a. He is impersonating the connection and closing it. It may be a packet shaper, proxy etc. Can you check what is that device?

Mike

Mike
New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Thanks Mike

I will look for the device and let you know.

Mike

New Member

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Mike,

Problem found, it was in our web filtering appliance (Websense).  We had locked down additional services on the outside interface and did not realize that it was effecting the DMZ as well.

Thanks again for the help.

Mike

Cisco Employee

Unable to Telnet/SSH/RDP from inside ---> DMZ, ASA 5505

Glad to hear that.

To summarize our troubleshooting. We took captures on both interfaces of the firewall and the host that is initiating the connection. Then, we look at the captures (on pcap format using wireshark) and we saw that there were RST packets that were not generated on the host. We looked at the mac-addresses an we found out that for the packets of the connection, the mac-addresses were showing the PC mac-address but for the RST flag on the tcp packets, they were coming from another mac-address which turned out to be a Webesense server.

I am glad that we were able to narrow down the problem, in case you need further assistance, do not hesitate to reply to this post, also if you consider that this post helped you out to find the solution, mark it as solved, so other people can follow the same line of troubleshooting.

Thanks!

Mike

Mike
2356
Views
0
Helpful
23
Replies
CreatePlease login to create content