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"
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"
Comments
What happens if you drop the server's IP into the DMZ?
Server & Networking: MCSA: Windows Server 2016 | MTA: Networking Fundamentals
Data Privacy & Project/Service Management: PECB GDPR DPO/Practitioner | ITIL 2011: Foundation | CompTIA Project+
Currently Studying: Microsoft 365 Enterprise Administrator Expert
Haven't tried packet capture...don't think we have software. Did a netstat -a but didn't see any connections established.
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.
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.
Did you ever resolve this? sounds like a routing issue
My ultimate career goal: To climb to the top of the computer network industry food chain.
"Winning means you're willing to go longer, work harder, and give more than anyone else." - Vince Lombardi
Same thing I was thinking
Next: CCNP (R&S and Sec)
Follow my OSCP Thread!
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.
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...