0

My router forwards incoming traffic on port 42424 to port 22 on my raspberry pi. But when i try to connect to the ssh server on the pi i only get Operation timed out. I've tried via tcpdump to see if the traffics comes in at the raspberry, and the traffic gets in but it looks like it will be ignored or something like that. Also checked firewall for allowing incoming traffic. Does anybody now something else i might did not consider?

  • are you trying to connect from an external source, or internally. If from internal, some gateway devices won't allow this, and/or attempt to return the traffic incorrectly. – stevieb Nov 1 '16 at 17:31
  • it's from outside – Pascal Nov 2 '16 at 14:00
1

Timed out means either there is no system at that address (i.e., your router is forwarding it, but not to the pi) or else a firewall/router is dropping incoming or outgoing packets. The latter is significant because if you can demonstrate the Pi is trying to reply, then the router is not forwarding out.

The fact that you can see the traffic with tcpdump on the Pi does not prove that it is targeting the Pi's actual address. Tcpdump is a network packet sniffer and can report any traffic that reaches the interface, which often includes more than just traffic addressed to that particular machine. For example, on a wifi network, it can include everything (although encryption will complicate this), as it commonly also does on ethernet.

It is actually unusual for a firewall to drop packets instead of replying immediately with an ICMP message denying access, so this is unlikely to be that, and it certainly wouldn't be so on the Pi unless you set that up on purpose. So the two most likely explanations are:

  • The IP address being forwarded to is not the Pi's real address. This would be my first guess.

  • The router is not forwarding back out.

Note that the problem cannot be that sshd is not running, because that will not cause a timeout. It will cause the OS to reply immediately with a message that the service is unreachable. So even if sshd isn't running, that is not the cause of the timeout.

  • I've analyzed the incoming packets from tcpdump in Wireshark and it shows that the packages come from the ip address i want to connect from, and the destination is the pi's ip address. Maybe it's because the pi is connected to two different networks? – Pascal Nov 2 '16 at 14:02
  • If you are satisfied that is true then there isn't much to add. If the pi is not sending any reply at all, then the only way for that to happen is because iptables has been configured to DROP packets. It is not that way by default but it is easy to check with sudo iptables -L. If that is not the case then you are wrong either about the Pi's address (double check from the pi with sudo ip addr), or about the fact that it isn't sending a reply (in which case it is the router, or something beyond the pi, that is screwing something up). – goldilocks Nov 2 '16 at 14:05
  • iptables allows incoming and outgoing traffic at all so this shouldn't be a problem too. The pi is connected to two networks. One thats behind a firewall in an local intranet and one network with direct internet access. So it actually has 2 ip addresses. But it's possible to connect to the pi via both network as long as it's local access. Maybe thats the clue? – Pascal Nov 2 '16 at 14:13
  • Probably. First you have to make certain the Pi is not responding to the packets at all. If not, then the OS does not consider this traffic addressed to it. Otherwise it would send something, either an actual reply from sshd if it is running or else a TCP RST/ACK packet if it is not. If it is sending one of those, you then have to look at how it is being routed, because obviously it is not getting to where it is supposed to go. – goldilocks Nov 2 '16 at 14:18
  • Finally found something about this. The pi sends the answer of the packets that come from eth1 to eth0, so they never actually get back to me. Looks like it need to route the packets so they get send back to their origin interface? – Pascal Nov 10 '16 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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