SSH issue at work. Seriously need help.

JohnjonesJohnjones Member Posts: 105
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"

Comments

  • PhalanxPhalanx I have many leatherbound books... United KingdomMember Posts: 331 ■■■□□□□□□□
    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?
    Client & Security: Microsoft 365 Modern Desktop Administrator Associate | MCSE: Mobility
    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
  • BlucodexBlucodex OSCP, GCIA, GCIH, GMON, CISSP, CEH, CHFI, CCNA CyberOps, Security+ Member Posts: 430 ■■■■□□□□□□
    Can you run a packet capture on the server to verify that traffic is not making it that far?
  • JohnjonesJohnjones Member Posts: 105
    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.
  • NotHackingYouNotHackingYou Member Posts: 1,460 ■■■■■■■■□□
    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.
    When you go the extra mile, there's no traffic.
  • NotHackingYouNotHackingYou Member Posts: 1,460 ■■■■■■■■□□
    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.
    When you go the extra mile, there's no traffic.
  • Cyber_spaceCyber_space Member Posts: 48 ■■□□□□□□□□
    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][Deleted User] Posts: 0 ■■□□□□□□□□
    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
  • Danielh22185Danielh22185 Member Posts: 1,195 ■■■■□□□□□□
    I would definitely be doing a packet capture on the server and again on the firewalls that segment the traffic.
    Currently Studying: IE Stuff...kinda...for now...
    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
  • IsmaeljrpIsmaeljrp Member Posts: 480 ■■■□□□□□□□
    Pcaps all the way. Packets don't lie. Don't just try to get lucky, investigate the flow of traffic.
  • Moldygr33nb3anMoldygr33nb3an Member Posts: 241
    Did you ever resolve this? sounds like a routing issue

    Same thing I was thinking
    Current: OSCP

    Next: CCNP (R&S and Sec)

    Follow my OSCP Thread!
  • blargoeblargoe Self-Described Huguenot NC, USAMember Posts: 4,174 ■■■■■■■■■□
    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.
    IT guy since 12/00

    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...
Sign In or Register to comment.