ssh into Cisco router not working

Question

On a 2800 series router, I used to be able to ssh in via two public interfaces, but now I can't seem to. One of these two public interfaces has an ACL, the other currently doesn't. When I ssh to the one with the ACL, I do see the counter go up on the permit rule for the ACL. However, I can't telnet to port 22 on either interface. I am still able to ssh into the router using the internal interfaces over IPSEC VPN tunnels. Anyone know what might be going on?

Here is a debug log of an attempt to telnet from the outside over the internet, 12.12.12.12 is the outside computer, 13.13.13.13 is the public interface on the router that I telnet too:

000263: *Sep 15 13:18:46.505 UTC: IP: tableid=0, s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), routed via RIB
000264: *Sep 15 13:18:46.505 UTC: IP: s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), len 60, rcvd 3
000265: *Sep 15 13:18:46.505 UTC:     TCP src=48143, dst=22, seq=1929678540, ack=0, win=5840 SYN
000266: *Sep 15 13:18:46.505 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000267: *Sep 15 13:18:46.509 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 44, sending
000268: *Sep 15 13:18:46.509 UTC:     TCP src=22, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK SYN
000269: *Sep 15 13:18:48.509 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000270: *Sep 15 13:18:48.509 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 44, sending
000271: *Sep 15 13:18:48.509 UTC:     TCP src=35, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK SYN
000272: *Sep 15 13:18:49.501 UTC: IP: tableid=0, s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), routed via RIB
000273: *Sep 15 13:18:49.501 UTC: IP: s=12.12.12.12 (FastEthernet0/1/0), d=13.13.13.13 (FastEthernet0/1/0), len 60, rcvd 3
000274: *Sep 15 13:18:49.501 UTC:     TCP src=48143, dst=22, seq=1929678540, ack=0, win=5840 SYN
000275: *Sep 15 13:18:49.501 UTC: IP: tableid=0, s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), routed via FIB
000276: *Sep 15 13:18:49.501 UTC: IP: s=13.13.13.13 (local), d=12.12.12.12 (FastEthernet0/1/0), len 40, sending
000277: *Sep 15 13:18:49.501 UTC:     TCP src=22, dst=48143, seq=3745978889, ack=1929678541, win=4128 ACK

Update:
Perhaps a nat problem?

The output of show ip nat trans of the above is:

tcp 11.11.11.11:22     14.14.14.14:22      12.12.12.12:42884     12.12.12.12:42884

Where 14.14.14.14 is the other public interface on the router.

Solution 1

Things to check:

• On the router, do debug ip ssh and then terminal monitor, then try to connect.
• Use debugging on the client side. With OpenSSH, run it with the -v flag. With PuTTY, go to Logging and select SSH Packets before you try to connect. I'd imagine other SSH clients have debugging mechanisms as well, but those are the two I use most often.

A combination of both should give you some indication of where the connection is getting stuck.

Also, make sure you do undebug ip ssh when you're done.

Solution 2

Kyle, A NAT problem is likely, although hard to tell without seeing the config.

A good way to help troubleshoot it is to create an access-list with the router's external IP and then enable NAT debugging for that ACL. For example:

R> enable
R# conf t
! XXX is the number of an unused access-list
R(config)# access-list XXX permit 13.13.13.13 0.0.0.0
R(config)# ^Z
! XXX is the ACL defined above
R# debug ip nat XXX
R# term monitor

When done:

R# no access-list XXX
!Removing the ACP should automatically turn off NAT debugging for it but to be thorough
R# no debug ip nat XX

Comments

[Kyle Brandt]

With -v, I just see it hang at the connecting to port. If this were In summary, if this were a Linux box, I would say ssh isn't listening on that interface... The debug ip ssh doesn't show anything for the new session I try to establish.

[Kyle Brandt]

Does the SYN, SYN ACK, SYN ACK, SYN, ACK say anything?

[James Sneeringer]

TCP connections start with a "three-way handshake". The host initiating the connection sends a SYN packet. The remote host response with ACK SYN. The connecting hosts sends a final ACK to start the connection. When you see "ACK SYN" multiple times, it indicates that the response from your router isn't being received (or is being ignored) by the connecting client. I agree with Charles that your NAT configuration may well be causing this. It would be helpful if you could post the "ip nat" commands in your config.