Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm having some issues setting up port forwarding using static NAT on a Cisco 881W ISR. I've confirmed that the ssh daemon is working from the linux box inside the nat. My question is regarding the fact that any inbound ssh connections are able to open the socket, but it appears the ssh handshake times out or is otherwise hampered by the NAT configuration on the router. I thought this to be odd, and have suffered through hours of googling to no avail. I've got other port forwards on the router and they work just fine -- HTTP and subversion on ports 8080 and 8081, respectively.

Here's my NAT, ACL, and interface configs:

interface Dialer0
  description WAN-ADSL
  ip address negotiated
  no ip redirects
  no ip unreachables
  no ip proxy-arp
  ip mtu 1452
  ip flow ingress
  ip nat outside
  ip virtual-reassembly
  zone-member security out-zone
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  ppp authentication chap callin
  ppp chap hostname user@adsl.provider
  ppp chap password 7 HERPADERPADERP
  no cdp enable

ip nat translation timeout 30
ip nat inside source list 101 interface Dialer0 overload
ip nat inside source static tcp 22 interface Dialer0 22
ip nat inside source static tcp 8080 interface Dialer0 8080
ip nat inside source static tcp 8081 interface Dialer0 8081

access-list 101 permit ip any any
access-list 101 permit tcp any any established

Any words of wisdom that would help me get SSH to properly handshake and actually open a connection? I REALLY do not want to resort to telnet for remote access, and (as stated above), google comes up blank.


Since HTTP is going through just fine, I'm wondering if this is a configuration issue with SSH. For the record, I'm using a vanilla openssh daemon from the debian repository. I've also tested this with the ssh daemon running on my Macbook with the same results.

share|improve this question
up vote 0 down vote accepted

Turn on verbose debugging on the ssh client trying to connect, and post the results. Also take a look at the sshd log, that should help isolate where the issue is.

share|improve this answer
And Lo - a solution has been found! Turns out that I was being too restrictive on my inspection rules. Let this be a warning and potential push in the right direction for anyone else having a similar issue: always make sure your traffic inspection rules are permissive enough to allow the NAT'd traffic through. All it took for me was adding TCP/22 to the inspection rules and blammo -- worked like a charm. – Edmond Belliveau May 23 '11 at 16:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.