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

[mgallas6031]

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

[mgallas6031]

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

[Maykol Rojas]

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

[mgallas6031]

Thanks Mike,

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

[Maykol Rojas]

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

[mgallas6031]

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

[Maykol Rojas]

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

[mgallas6031]

Thanks Mike

I will look for the device and let you know.

Mike

[mgallas6031]

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

[Maykol Rojas · Accepted solution]

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