Work Around for suspected SSH traffic drop by ISP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-07-2024 02:54 PM - edited 02-07-2024 02:54 PM
I am facing SSH connection failure between a source and destination using Public IPs over internet, It seems SSH traffic is blocked somewhere in the middle. Tried to telnet destination IP on port 22 but fails, while with some other TCP ports it's successful. SSH traffic was not reaching the other side. Source IP is a public IP that is static natted(on the cisco router) to one of the inside server private IPs. Is it possible to overcome this issue with a workaround like a GRE tunnel between source and destination, and forcing SSH traffic to pass through the tunnel. If possible, will the static NAT be a problem? Suggestions please. Thanks in advance.
- Labels:
-
Other Routing
-
WAN
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-07-2024 03:35 PM
Hello
Is ssh enabled on the destination device and is there any ACL or Control plane policing negating access to the vty lines?
If the host is behind a NAT then is port forwarding enabled for ssh for that particular device?
Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.
Kind Regards
Paul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-07-2024 07:45 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-07-2024 11:49 PM
If the device you need to access via ssh is ASR then it can ssh port is not 22 and it use other ssh port.
Force router using port 22.
MHM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2024 12:26 AM
To make sure that your config is right, i suggest you run a packet capture at the source/destination (ideally at the edge) and confirm then where the traffic is getting dropped.
Please mark it as Helpful and/or Solution Accepted if that is the case. Thanks for making Engineering easy again.
Connect with me for more on Linkedin https://www.linkedin.com/in/rubencocheno/
