SSH issue at work. Seriously need help.

I'll try to explain this:

We have 2 terminal servers behind the DMZ running 2012 R2 on a 10.200.254 network. Gateway is 10.200.254.1

Outside cloud node: 10.200.155.x | Gateway 10.200.155.1

Problem is that from either of those 2 terminal servers no one can ssh to the outside node, but can to other servers internally. Also, I can reach the outside node from any other server which is internal(not behind DMZ).

When I ran a tracert it came back with 10.200.254.1 ---> 10.200.155.1 ---> then times out.

Our network and firewall team is able to ssh to the cloud node from both the dmz router and the 155.1 router. So they are blaming the terminal servers.

I've turned turning off the host firewall and everything else I can think of, but am out of ideas. The putty error is "Network Error: Software cause connection abort"

Find more posts tagged with

Comments

Phalanx

Only time I've seen that error is when the firewall is causing the issue.

What happens if you drop the server's IP into the DMZ?

Blucodex

Can you run a packet capture on the server to verify that traffic is not making it that far?

Johnjones

Unfortunately I can't do anything at this moment as I'm not at work. We don't have access/control to the node.

Haven't tried packet capture...don't think we have software. Did a netstat -a but didn't see any connections established.

NotHackingYou

Run netstat -ano and observe the status of the connection while you try it. You might see something like SYN_SENT. If it goes into that status and stays, it means you never got a SYN/ACK back and your traffic did not make it. You will need to run the command several times. It's helps if you know the process ID. You can also do netstat -ano | find "22" for just tcp/22 connections.

You can take a pcap with netsh trace, which is built in to windows. You need Microsoft Message Analyzer to view it. It would be better to just install wireshark and remove it when you are done.

Edited to add: Your firewall team should be able to tell you if they are dropping the traffic. Usually the firewall admin will provide a log of the traffic either being allowed or denied.

NotHackingYou

Here are the state codes and explanations from netstat.net. I bolded the ones I think are most appropriate for you.

State The state of the socket. Since there are no states in raw mode and usually no states used in UDP, this column may be left blank. Normally this can be one of several values:
ESTABLISHED The socket has an established connection.

SYN_SENT The socket is actively attempting to establish a connection.

SYN_RECV A connection request has been received from the network.

FIN_WAIT1 The socket is closed, and the connection is shutting down.

FIN_WAIT2 Connection is closed, and the socket is waiting for a shutdown from the remote end.

TIME_WAIT The socket is waiting after close to handle packets still in the network.

CLOSE The socket is not being used.

CLOSE_WAIT The remote end has shut down, waiting for the socket to close.

LAST_ACK The remote end has shut down, and the socket is closed. Waiting for acknowledgement.

LISTEN The socket is listening for incoming connections. Such sockets are not included in the output unless you specify the --listening (-l) or --all (-a) option.

CLOSING Both sockets are shut down but we still don't have all our data sent.

UNKNOWN The state of the socket is unknown.

Cyber_space

Johnjones wrote: »

I'll try to explain this:

We have 2 terminal servers behind the DMZ running 2012 R2 on a 10.200.254 network. Gateway is 10.200.254.1

Outside cloud node: 10.200.155.x | Gateway 10.200.155.1

Problem is that from either of those 2 terminal servers no one can ssh to the outside node, but can to other servers internally. Also, I can reach the outside node from any other server which is internal(not behind DMZ).

When I ran a tracert it came back with 10.200.254.1 ---> 10.200.155.1 ---> then times out.

Our network and firewall team is able to ssh to the cloud node from both the dmz router and the 155.1 router. So they are blaming the terminal servers.

I've turned turning off the host firewall and everything else I can think of, but am out of ideas. The putty error is "Network Error: Software cause connection abort"

Did you ever resolve this? sounds like a routing issue

[Deleted User]

Maybe it's an ACL based issue? I would run a packet capture to see if any traffic for SSH is present. Also check for 3 way handshake if it is being setup or if you get RST

Danielh22185

I would definitely be doing a packet capture on the server and again on the firewalls that segment the traffic.

Ismaeljrp

Pcaps all the way. Packets don't lie. Don't just try to get lucky, investigate the flow of traffic.

Moldygr33nb3an

Cyber_space wrote: »

Did you ever resolve this? sounds like a routing issue

Same thing I was thinking

blargoe

The traceroute might be a red herring, something upstream might be blocking icmp packets.

Are there any other services on the cloud node (http, https, whatever) to which you could try to connect? If you attempt to connect to one of the other services from the same terminal server, and you get a response of any kind, then it is not a routing issue; you likely have something blocking outgoing SSH at the firewall. I believe my security team is blocking anything outbound that isn't 80 and 443 by default and creates rules to handle other ports based on use case.