We have set up a Raspberry Pi as a honeypot using honeypi. Now it is in a different network with a firewall in between with static NAT configured. It is possible to ping the Raspberry Pi but SSH does not work even though the tcpdump shows that the SSH request arrives, so we figured the network/firewall config is not the problem but something on the Raspberry Pi blocks it.

iptables on the Raspberry Pi is disabled.

Is it possible that the Raspberry Pi doesn't accept the SSH request for some reason? It is possible to SSH from the Firewall to the Raspberry Pi, but not from the devices “on the other side of the Firewall”. Attached is the output of the tcpdump. Thanks for your help!

tcp dump

  • Hi and welcome! Before putting your RPi behind a firewall, did you try accessing it through SSH? – David Apr 7 '19 at 15:38
  • Hi David, not before we set the new IP for the ethernet interface, but we did use it in the same network without FW but over wifi – code_muffin Apr 7 '19 at 16:16
  • > ssh does not work ... As stated, there is not enough information to figure out what's going on... Try ssh -vvv user@host ... the -vvv option will provide plenty of debugging information... – RubberStamp Apr 7 '19 at 23:55

My first inclination is to suggest you thoroughly read the docs on honeypi. It looks fairly new, and may not have been properly "wrung out" yet. You also stated in your question:

iptables on the Raspberry Pi is disabled.

But according to the honeypi website, one of their 3 "ingredients" is"

PSAD: Port Scan Attack Detection – This uses iptables...

But assuming everything is as it should be, and as you say it is, my first step would be to check the sshd log file to see if the connections are even reaching your RPi. You'll (likely) need to establish an SSH connection to do this, so you should connect to your honeypot from the same subnet.

Some time before you attempt a connection to your honeypi RPi from the "threat network", begin monitoring sshd log file:

$ sudo tail -f /var/log/auth.log | grep sshd 

Attempt an ssh connection from a "threat" machine, and you should see an entry that reflects that. If you need more detail to figure out what's going on, increase the #LogLevel INFO entry in /etc/ssh/sshd_config:

     #LogLevel INFO 
     LogLevel VERBOSE

This will get you started. Let us know how this goes & we'll proceed from there.

| improve this answer | |

we managed to finally figure out that it was a routing problem. the ping was sent via FW to the network the ethernet interface was in and then the answer came back via the “direct” route from the pi. but of course for SSH this didnt work and therefore the pi dropped it. it was such a simple and obvious solution yet we pulled our hair out over this... after we disabled wifi, it worked🤦🏼‍♀️

| improve this answer | |

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.