0

I have 3 devices in my home network; a Netgear ReadyNAS, a Raspberry Pi [Pi1] running Raspbian Debian and a Raspberry Pi [Pi2] running XBMC which I think is also based on Debian.

I have set up 3 port forwarding rules at the router and can now connect to ReadyNas & Pi1 without issue over the web.

Pi2 is not contactable, connection refused. I have re-pointed the rule which works for the ReadyNas to Pi2, and it still doesn't work leading me to believe it is a problem on the Pi. I have tried both port 22 (SSH) & 8001 (web server)

Internally I can connect to Pi2 with no issues.

The service I am most concerned about is SSH on port 22 which has been used for most of my testing. Ultimately I'll be wanting to forward webserver ports as well.

What could be wrong?

  • 1
    What service are you trying to connect to on your second pi? – JNevill Sep 22 '14 at 16:18
  • 1
    Can you access any website from Pi2? – abacabadabacaba Sep 22 '14 at 16:35
  • 1
    Is openSSH installed on the second pi? You say it's an XBMC installation, is it openelec or Raspbmc or something like that? – JNevill Sep 22 '14 at 16:43
  • 1
    iptables rules on pi2? – ssnobody Sep 22 '14 at 17:07
  • 1
    When you say "Internally I can connect to Pi2 with no issues." you mean you can ssh for example from Pi1 to Pi2 ? If so, there may be some AllowUsers rule in sshd_config to restrict access, or iptables rule. – tonioc Sep 23 '14 at 7:17
1

You should check your firewall rules on the XMBC Pi. The reason is that, out of security cocerns, some preconfigured boxes bar all connections originating from outside one's LAN.

The command to do this is

  iptables -t filter -L -n -v

and likewise for the other tables, nat and mangle. If you can act on these rules, then this is the simplest solution.

Alternatively, if your router runs software like dd-wrt, OpenWrt, Tomato, and so on, then the following rule on the router

 iptables -t nat -A POSTROUTING -o LAN_IFACE -s ! 192.168.0.0/24 -d 192.168.0.15 -p tcp --dport 22 -j MASQUERADE

This assumes that your home net is 192.168.0.0/24, that the recalcitrant Pi is 192.168.0.15, and that the router's LAN interface is called LAN_IFACE. The rule simply rewrites the packet's origin as coming from the router itself (192.168.0.1 under the above assumptions), thus tricking the XMBC to think that the connections are initiated locallly, rather than remotely.

Lastly, if your router does not allow the above, if you have some other Linux machine (like, I presume, the first Pi), you can

  1. port forward the connections for the Pi2 to some high-numbered ports of Pi1

  2. redirect these packets, after masquerading, to Pi2 and its proper port.

This time, per port, you need two commands: let us again consider ssh, and let us say that the router has port-forwarded ssh connections for Pi2 to Pi1's 51111 port (192.168.0.10:51111). Then:

  iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 51111 -j DNAT --to 192.168.0.15:22
  iptables -A FORWARD -p tcp -d 192.168.0.15 --dport 22 -j ACCEPT

Just make sure you have allowed forwarding on Pi1,

  sysctl net.ipv4.conf.eth0.forwarding=1
  • There was a rule "dropping" any connections from outside the local network. Thanks for your help – G-. Sep 24 '14 at 14:41

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.