SSH Raspberry Pi from other local network

Question

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!

Answer 1

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:

FROM: 
     #LogLevel INFO 
TO:
     LogLevel VERBOSE

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

Answer 2

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🤦🏼‍♀️