0

I have a Raspberry Pi3 with Raspbian Stretch that is behind a home router.

/var/log/auth.log in the RPi consistently shows failed login attempts with generic usernames (root, operator, webmaster, and so on), on random ports with high numbers, 3 attemps every 10 seconds approximately, from a chinese address. I know this is unsurprising.

What I don't understand is how come PuTTY can't reach that same server when I try to contact it through my public IP ?

I am very much a newbie in this field, but with my knowledge, this is a complete paradox.

Some additional technical notes :

  • iptables is untouched

  • nmap to my public IP address gives "all 1000 ports scanned are filtered"

  • a functionnal LAMP server hosts an Owncloud that works, but only from LAN, as any attemps of contacting my public IP address miserably fail.
  • my attempts at connecting to my public IP are made from the same LAN as the RPi's.
  • port 22 is redirected to the RPi in the router, and the router's firewall is completely off for the purpose of my present tests.
  • in the router, my RPi is set to be in the DMZ. Afaik, results are the same with this setting off.

Where are my packets dropped and why ?

Where could I search for the log that would show me ?

Thanks in advance

Alexandre Cariage
  • 1

1 Answers1

3

This is a common issue caused by the inability to do a Hairpin NAT. Most cheap home routers handle this simply by turning on port forwarding. However, higher end routers actually need separate rules to address the issue.

Your regular NAT rules only work from outside your network. If you try to connect from inside your network there is a NAT issue.

Consider this...

  • You have Server A on your local network with IP 10.10.10.10.
  • You have Computer A on your local network with IP 10.10.10.20.
  • You have Router A with a LAN IP of 10.10.10.1 and a WAN IP of 11.11.11.11.
  • You have Computer B outside your network with IP 12.12.12.12.
  • You have port 22 forwarded from your WAN IP to Server A.

From outside your network the traffic looks like this:

Computer B tries to connect to Server A:

Source IP: 12.12.12.12   Src Port: 12345
Destination IP: 11.11.11.11    Dest Port: 22

Router A NATs the packet and sends it on to Server A:

Source IP: 12.12.12.12   Src Port: 12345
Destination IP: 10.10.10.10   Dest Port: 22

Server A responds to Computer B:

Source IP: 10.10.10.10    Src Port: 22
Destination IP: 12.12.12.12   Dest Port: 12345

Router A NATs the packet and sends it on to Computer B:

Source IP: 11.11.11.11   Src Port: 22
Destination IP: 12.12.12.12   Dest Port: 12345

Everything works as intended. Now, consider the same scenario but from inside your network:

Computer A tries to connect to Server A:

Source IP: 10.10.10.20   Src Port: 12345
Destination IP: 11.11.11.11   Dest Port: 22

Router A NATs the packet and sends it on to Server A:

Source IP: 10.10.10.20   Src Port: 12345
Destination IP: 10.10.10.10   Dest Port: 22

Server A responds to Computer A:

Source IP: 10.10.10.10   Src Port: 22
Destination IP: 10.10.10.20   Dest Port: 12345

The source IP is on the same subnet as the destination IP. Server A does not send the packet back to the router, it sends it directly to Computer A. Computer A drops the packet, because it came from 10.10.10.10 and it sent the original packet to 11.11.11.11. It expects the packet to return from 11.11.11.11.

To resolve the issue, you must create a second, more specific NAT rule to match traffic originating from inside your network. It will come after your original NAT rule. You'll need to do a Source NAT that looks like this:

srcnat src-address=10.10.10.0/24 dst-address=10.10.10.10 dst-port=22 out-interface=LAN action=masquerade

Now, lets look at this again:

Computer A tries to connect to Server A:

Source IP: 10.10.10.20   Src Port: 12345
Destination IP: 11.11.11.11   Dest Port: 22

Router A NATs the packet and sends it on to Server A:

Source IP: 10.10.10.1   Src Port: 12345
Destination IP: 10.10.10.10   Dest Port: 22

Server A responds to Computer A:

Source IP: 10.10.10.10   Src Port: 22
Destination IP: 10.10.10.1   Dest Port: 12345

Router A NATs the packet and sends it on to Computer A:

Source IP: 11.11.11.11   Src Port: 22
Destination IP: 10.10.10.20   Dest Port: 12345

Everything works as intended.

How you implement this second NAT rule is dependent on your router hardware and software. Your mileage may vary.

Appleoddity
  • 11,730
  • "common issue caused by Hairpin NAT" – What is "hairpin NAT" exactly? I thought it's a solution, you say it's a cause. Please address my doubts. I lack knowledge to be sure your answer is technically right. Still I think it would benefit from mentioning that some home routers implement the right solution by default, all one needs to do is to define a port forwarding rule like with a web interface of the router. Obviously the OP's router is not one of them. – Kamil Maciorowski Feb 13 '18 at 00:09
  • 2
    @KamilMaciorowski NAT hairpinning (aka NAT loopback) is what you're trying to do -- use a port forward from inside the private network to another computer in the private network. The problem is that not all routers support this. Depending on the router, you might be able to enable it, or you might need to switch to a router that does support it. – Gordon Davisson Feb 13 '18 at 03:27
  • It's a silly problem. Either use the local IP you want to communicate with, or set up a dns record on the host machine that points internally to the IP you want to be directed to. That's quite the post BTW. – Tim_Stewart Feb 13 '18 at 23:14
  • Thanks @Appleoddity for the clear explanation that made me understand what happens packet-wise ! But for the NAT rule I don't know how I will set it in my router (can't log to it through telnet), so I'll use the DNS record solution from Tim_Stewart, thanks Tim. – Alexandre Cariage Feb 14 '18 at 10:16