Attack using NAT?

Today I noticed several odd messages in the log files of a Raspberry pi showing this sort of thing:

[UFW LIMIT BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:YY:YY:YY:YY:YY:YY:08:00:45:00:00:3c:74:09:40:00 SRC= DST= LEN=60 TOS=0x00 PREC=0x00 TTL=45 ID=29705 DF PROTO=TCP SPT=36152 DPT=18768 WINDOW=29200 RES=0x00 SYN URGP=0

Here XX:XX:XX:XX:XX:XX is the MAC address of the Pi, and YY:YY:YY:YY:YY:YY is the MAC address of the ASUS RT-AC85P router running OpenWRT 23.05.2

The destination port of 18768 is used as an external SSH log-in and is port-forwarded by OpenWRT to the Pi.

The extra MAC information (here 08:00:45:00:00:3c:74:09:40:00) and the source port changed from message to message, but I don't really know if that is important or not.

What is puzzling my is the source address of as that is the router! So it appears that my router is trying to brute-force SSH and it was the UFW firewall that kicked in to block multiple attempts in a short period.

But...that is not what seems to happen on an external attack. I tried to generate the same UFW LIMIT by repeatedly SSH'ing in from another external network and I got this sort of thing:

[UFW LIMIT BLOCK] IN=eth0 OUT= MAC=XX:XX:XX:XX:XX:XX:YY:YY:YY:YY:YY:YY:08:00:45:00:00:3c:65:8d:40:00 SRC=ZZZ.ZZZ.ZZZ.ZZZ DST= LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=25997 DF PROTO=TCP SPT=58972 DPT=18768 WINDOW=64240 RES=0x00 SYN URGP=0

It looks very similar, but the critical difference is the source IP address of ZZZ.ZZZ.ZZZ.ZZZ is the address of the network I tested from. So if it was a normal credential stuffing attack or similar from an external machine, why would it show up as the router's IPv4 address?

I am not doing anything terribly fancy with OpenWRT, though I do have a guest WiFi using a VLAN, but that is on the 192.168.3.nnn subnet, and at the time the above happened there was nobody home to be using WiFi anyway (and its a pretty quiet location, so drive-by snooping seems unlikely).

TL;DR how can an external attacker appear to be using the router's own IP address?

After 3 attempts SSH will drop connection and a new one will need to be established.

Look for this in system log.

No SSH was established, maybe because it is key-exchange only so password stuffing won't get far.

Real question is why seems to come from the router itself?

The request will be logged. look, if it is not there then it is something else. Will be close to bottom.

I don't see any related logs that match. Around the time of the puzzling messages (Feb 7 19:05:12) , and filtering out a successful login from a machine on, I see these in auth.log:

Feb  7 19:04:58 porta sshd[24741]: Received disconnect from port 53142:11: Bye Bye [preauth]
Feb  7 19:04:58 porta sshd[24741]: Disconnected from authenticating user root port 53142 [preauth]
Feb  7 19:05:07 porta sshd[24763]: Received disconnect from port 41510:11: Bye Bye [preauth]
Feb  7 19:05:07 porta sshd[24763]: Disconnected from authenticating user root port 41510 [preauth]
Feb  7 19:06:47 porta sshd[24768]: Invalid user business from port 57838
Feb  7 19:06:48 porta sshd[24768]: Received disconnect from port 57838:11: Bye Bye [preauth]
Feb  7 19:06:48 porta sshd[24768]: Disconnected from invalid user business port 57838 [preauth]

Nothing relates to the router IP address.

It could be someone from inside using the external wan address, because of hairpining it becomes the routers address?

Better use WireGuard or OpenVPN to remotely connect

Do you have a device named "Bye Bye"?

OK that might make some more sense. I will try and find out if anyone was doing that to see if it is a benign warning.

Nope, nothing like that!

Close the ports. Then figure it out.

If the port facing the Internet (before DNAT) is 22, it is going to get probed a lot. Use a high nonstandard port number.

The external port already is a high-number one to reduce the random attempts already, compared to the usual 22 for SSH. is from Belgium is in France.

Both from "Bye Bye"

I'd lock it down but it is your network.

"Bye Bye" is the accompanying message when an attempt gets denied at "preauth", not the name of the device/user trying to connect. You'll see these message alot due to port scans.


I'm locked down/drop so I have never seen that.
I thought it was kinda snarky; now I know why.

If you need to have a port for something like ssh open to the public internet that is really meant for your own private use, then you should secure that port with port knocking. The package luci-app-fwknop should be helpful to you.

Moving the ssh server to a different port number won't help. The problem is that the ipv4 address space is small. All of the time, bot nets are scanning all of the address space, and they do probe the entire port space. If you have an open port on the public internet, a bot will eventually find it and share that discovery with other bots.

The answer lies in what firewall configuration(s) you've made that allows this traffic, but uses the SRC IP of the router.