Can't SSH in past router (D-Link DI-604)

Setup: I have a new install of Debian Woody hooked up to my router with a static IP of 192.168.0.2 (I've got two MS machines on the router, too). The router is set to pass incoming packets addressed to port 60 to 192.168.0.2, and I'm running sshd on the Debian machine listening to port 60. I have nothing in hosts.deny and all the IPs I want to come in from (the LAN ones and my work machine) in hosts.allow, as well as SSH: ALL in hosts.allow.

I can ssh in to the machine from my other two LAN machines, no problem. But I can't get in from outside, like from a work or school machine. The router log doesn't show it stopping or blocking the packets to port 60 from work or school, but ssh just times out trying to get in. (To get in, I just run ssh -p 60 user@<router's external IP>).

Does anyone have any suggestions? Especially obvious ones that I might have missed. I have no rules in ipchains yet.

It would help if I had some kind of log that would tell me if incoming packets were coming in at all, or what is happening with them. I'm a semi-newb at this stuff (had it working on a Mandrake 10 machine until it died and we got the router), so even if something sounds obvious but I haven't mentioned it, please, tell me!

Good links would be nice, too -- I've been reading through the Debian FAQ and the ipchains HOWTO but haven't seen anything that seems directly relevant.


thanks in advance for any help anyone can offer,

Try setting a counting only iptables rule. A rule without a target (-j).

iptables -A INPUT -p tcp --dport 60

Using iptables -n -v -L you can now see a count of packet matchings.
Alternative you can use the LOG target to the above rule, -j LOG
Now these packets will be logged to your system log.

Okay, so after various adventures including a kernel upgrade, I've got iptables up. Added a rule that logs all packets. When I try to SSH in, here's what I get:

Nov 2 07:12:40 opal kernel: IN=eth0 OUT= MAC=00:05:5d:dc:9f:2c:00:0d:88:c4:b7:7b:08:00 SRC=<deleted> DST=192.168.0.2 LEN=100 TOS=0x00 PREC=0x00 TTL=248 ID=63306 DF PROTO=TCP SPT=22 DPT=1079 WINDOW=10136
RES=0x00 ACK PSH URGP=0

Now, that SPT is the source port, right? That's fine. But why is the DPT 1079 instead of 22? I try to run sshd listening on 1079, but it says something else is already bound there.

Help!?! Or should this be in the newbie forum?

No, this forum is apropriate for this question.

Now we know that the ssh request is let through the router/firewall and reaches the server.
The DPT and SPT seems mixed up, they should be the oposite.
What do you get running:

lsof -i 1079

This will show what process using the 1079 port.

I just get this:
kdeinit 537 chuk 8u unix 0xc0c8dae0 1079 socket

The command name should have been

lsof -i :1079

Don't know if that would change it, probably not.
This shows that kdeinit have a socket open (read/write) for port 1079. To track down which process is responsible for that, you will have to ask someone else.

I'm still confused about the apparent switch of DPT/SPT. Can't see why that occurs.

If you are running ssh -p 60 user@<router's external IP> then where is the port 22 coming from in your packet log? I agree with ugge that the dest and source ports shouldn't look that way regardless of the port 22.

What is your dlink doing? Do you have it set to port forward or otherwise mangle connections coming in? Might want to fire up the browser and check the dlink settings. Long shot but it's worth looking at.

tcpdump -vvvns0 may shed some light for you. You'll get a better picture of what is happening than with iptables logs.

-b

Originally posted by bignerd If you are running ssh -p 60 user@<router's external IP> then where is the port 22 coming from in your packet log? I agree with ugge that the dest and source ports shouldn't look that way regardless of the port 22.

Sorry, I went back to regular ssh for now just in case there was a problem with the router -- I'm coming in on 22 again.

What is your dlink doing? Do you have it set to port forward or otherwise mangle connections coming in? Might want to fire up the browser and check the dlink settings. Long shot but it's worth looking at. tcpdump -vvvns0 may shed some light for you. You'll get a better picture of what is happening than with iptables logs. -b

Yes, the dlink is forwarding incoming port 22 stuff (from some IPs) into the 192.168.0.2 address of the linux box. I figured that since I was seeing the packets on the linux machine, that meant the router settings were okay -- is there something else I could look for?

Originally posted by Chuk Sorry, I went back to regular ssh for now just in case there was a problem with the router -- I'm coming in on 22 again. Yes, the dlink is forwarding incoming port 22 stuff (from some IPs) into the 192.168.0.2 address of the linux box. I figured that since I was seeing the packets on the linux machine, that meant the router settings were okay -- is there something else I could look for?

I don't have a dlink since I do my firewalling/routing/natting through a multihomed linux box. But after a quick look at your model's help from dlink I would suggest you just double check that the "private port" setting and "public port" setting are both set for whatever you are listening on for ssh (currently port 22 I think). This would be under Virtual Server, Advanced.

That will ensure that any hits to your public ip on your dlink on port 22 will get forwarded to your internal and natted linux box's port 22. This is static nat.

-b

Originally posted by bignerd I don't have a dlink since I do my firewalling/routing/natting through a multihomed linux box. But after a quick look at your model's help from dlink I would suggest you just double check that the "private port" setting and "public port" setting are both set for whatever you are listening on for ssh (currently port 22 I think). This would be under Virtual Server, Advanced.

Thanks -- checked that already.

Is there some way (maybe with iptables) that I can reroute the packets coming in on 1092 so that they then come in on 22?

Originally posted by Chuk Thanks -- checked that already. Is there some way (maybe with iptables) that I can reroute the packets coming in on 1092 so that they then come in on 22?

Afraid it doesn't work that way. The last device to forward a packet decides how it's gonna hit the wire.. in your case it's your dlink. This is a dlink problem. The behavior you describe is not normal.

To verify I would pull the dlink off the network and directly connect the linux box. I won't go into the details of this in case you all ready know what you have to do to accomplish this. If not then post back and I or someone else can give easy instructions.

If this corrects the problem then you know for sure it's the dlink mucking things up. It's my guess this is the case.

Good luck.

-b

Originally posted by bignerd To verify I would pull the dlink off the network and directly connect the linux box. I won't go into the details of this in case you all ready know what you have to do to accomplish this. If not then post back and I or someone else can give easy instructions.

Okay, I tried that -- no luck. I could get online, ssh out, no problem, but I couldn't SSH in from offsite machines.

Anyone got any other suggestions?

Originally posted by Chuk Okay, I tried that -- no luck. I could get online, ssh out, no problem, but I couldn't SSH in from offsite machines. Anyone got any other suggestions?

Either examin the outputs from the below or post them up so we can look at them:

netstat -an
netstat -anr
cat /etc/ssh/sshd_config
iptables -L -n -v
iptables -t nat -L -n -v

-b

Originally posted by bignerd [B]Either examin the outputs from the below or post them up so we can look at them: netstat -an netstat -anr

netstats -an relevant stuff?

tcp 0 0 192.168.0.2:22 0.0.0.0:* LISTEN
tcp 0 0 192.168.0.2:32895 <foreignIP>:22 TIME_WAIT

netstat -anr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 40 0 0 eth0


cat /etc/ssh/sshd_config

# Package generated configuration file
# See the sshd(8) manpage for defails

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
ListenAddress 192.168.0.2
#ListenAddress <gatewayIP>
Protocol 2,1
# HostKeys for protocol version 1
HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation no

# ...but breaks Pam auth via kbdint, so we have to turn it off
# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user (off due to PrivSep)
PAMAuthenticationViaKbdInt no
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel DEBUG

# Authentication:
LoginGraceTime 600
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# rhosts authentication should not be used
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes


# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd yes
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem sftp /usr/lib/sftp-server

AllowUsers mylogin




iptables -L -n -v
iptables -t nat -L -n -v


Nothing in either iptable.

I have since found out that the particular offsite machine I was trying to come in from must be at fault, since I can get to my box from other offsite machines. So now I'm just trying to figure that out.

Thanks to everyone who helped!