low rate port scans from spoofed addresses

[#1]

Recently transferred from BE, and hadn't had reason to look at the logs for ages, so don't know if this was happening then. I've needed to tell the router to re-connect a couple of times so I've been checking more often to watch for problems, and seen this ...
Getting ICMP entries, mostly replay check, in the log. at approx 1 minute intervals, from mixed addresses.  Seems to go away for a while after a reset  (presumably because I have a new IP address), then restarts at an unknown point.
(1) Is this unusual activity
(2) is there any way I can look for a possible trigger activity from one of our (mostly wireless) connected devices.
(3) can I get a longer log via the CLI than from the web interface so I can see when the activity starts?
>>>>>>>>>
Error May 22 11:03:18 FIREWALL replay check (1 of 25): Protocol: ICMP Src ip: 122.118.55.21 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 11:02:17 FIREWALL replay check (1 of 38): Protocol: ICMP Src ip: 94.215.129.141 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Communication Administratively Prohibited
Error May 22 11:01:14 FIREWALL replay check (1 of 37): Protocol: ICMP Src ip: 46.120.171.242 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 11:00:13 FIREWALL replay check (1 of 46): Protocol: ICMP Src ip: 46.116.235.243 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 11:00:01 FIREWALL icmp check (1 of 3): Protocol: ICMP Src ip: 213.55.104.155 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:58:59 FIREWALL replay check (1 of 36): Protocol: ICMP Src ip: 177.98.167.254 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:57:58 FIREWALL replay check (1 of 61): Protocol: ICMP Src ip: 98.140.240.225 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Info May 22 10:57:26 LOGIN User admin logged in on [HTTP] (from 192.168.1.64)
Error May 22 10:56:57 FIREWALL replay check (1 of 26): Protocol: ICMP Src ip: 94.215.129.141 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Communication Administratively Prohibited
Error May 22 10:55:55 FIREWALL replay check (1 of 34): Protocol: ICMP Src ip: 177.67.192.46 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:55:19 FIREWALL icmp check (1 of 2): Protocol: ICMP Src ip: 213.55.104.155 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:54:54 FIREWALL replay check (1 of 30): Protocol: ICMP Src ip: 186.54.238.18 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:53:53 FIREWALL replay check (1 of 36): Protocol: ICMP Src ip: 200.138.153.57 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:53:40 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 213.55.104.155 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:52:52 FIREWALL replay check (1 of 26): Protocol: ICMP Src ip: 190.93.108.147 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:51:50 FIREWALL replay check (1 of 34): Protocol: ICMP Src ip: 177.67.192.46 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:50:43 FIREWALL replay check (1 of 34): Protocol: ICMP Src ip: 67.164.215.67 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Communication Administratively Prohibited
Error May 22 10:49:40 FIREWALL replay check (1 of 32): Protocol: ICMP Src ip: 200.175.180.253 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:48:37 FIREWALL replay check (1 of 24): Protocol: ICMP Src ip: 125.253.100.84 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Port Unreacheable
Error May 22 10:47:47 FIREWALL icmp check (1 of 1): Protocol: ICMP Src ip: 37.157.208.50 Dst ip: xx.xx.xx.xx Type: Destination Unreachable Code: Host Unreacheable

[#2]

What makes you think these are port scans, or from spoofed addresses? The ICMP protocol itself doesn't have ports.
If you do a lot of P2P the entries are not unusual, and they're not even malicious.

[#3]

(3) CLI command syslog msgbuf show hist=enabled
(1) I'd have thought slightly unusual that many in such rapid succession, but as ejs says & it may not be you doing the P2P may have been a previous user of your current IP address.
Don't do a reset, just do a Gateway hop, log in to your modem/router and go to the Internet Box as shown here and click Disconnect. This drops the PPP session to the Plusnet. Wait about 30 seconds and then Click Connect. You'll likely be on a different Gateway and will also get a different IP address.
(2) That may well depend on the websites visited, etc    Have you done a whois on any of those IP addresses to see if you can spot any common factors etc.?
You could make sure you have the  Plusnet Firewall turned on if you don't want to use the ports it blocks (incoming) if you don't P2P you can turn on Safe Surf to block some additional ports but it doesn't stop all P2P.

[#4]

Thanks both.
"portscan" Not a network geek, so was going by the "port unreachable" part of the message.  I thought that the address may be spoofed because error messages appear to be coming in on a fairly consistent 1 min schedule (unless it's an artifact of the router logging) , I would have thought that wasn't easy to do if the sources are independent, and keeping the rate down rather than flooding, and changing the source would be less likely to set off automated systems.
"p2p".  No 1 son is downloading games updates from steam - does that use peering?  Other than that, no-one admitting to using torrents in this timeframe.
"Whois" Yes - all over the shop, Romania, Korea, Ethiopia, Brazil, India, Israel.  No obvious pattern.
"Common Factors".  I was hoping to spot when the traffic starts up, and link that back in time to something tangible - machine starting up, login, particular application being run or website visited.
"reset" - i probably mean gateway hop - and I'm not doing the disconnects anyway, they're being done automatically
"firewall" alrady enabled low.
I'll do a hop later, clear the logs and see what turns up. (It's still ticking away now, so persistant)

Thanks again.

[#5]

The "ICMP Destination Unreachable" message itself is a reply you would expect to receive if a program on your computer had tried to connect to a port on that IP address, but wasn't successful. I don't think there would be any response to these packets, regardless of if you were expecting them or not. What "replay check" means isn't terribly clear. I don't know what the "1 of 37" numbers refer to, but I'd guess higher numbers indicate more activity, perhaps the 37 means there were 37 valid entries in some list to check against.

[#6]

It's all to do with the Firewall rules in this animal of a 582n. This is definitely incoming traffic.
The 1 of  xx  is all to do with the entry in the Rules, not the number of events.
Why quite a lot of those above are called Replay check, I'm not sure - looking into it now.
Here's one from mine, but this is taken from the CLI log -
<81> May 20 02:35:57 FIREWALL icmp check (1 of 1): Protocol: ICMP  Src ip: 61.147.80.179 Dst ip: 84.xx.xxx.xxx Type: Destination Unreachable Code: Port Unreacheable
If you look at the GUI error log and do a copy and paste of that you can get things like -
Error May 22 16:35:22 SNTP Systemtime update: time setting 00:05:57 > new time setting: 16:35:22
Info Jan 1 00:05:44 FIREWALL event (1 of 32): modified rules
Info Jan 1 00:05:44 FIREWALL event (1 of 50): created rules
Warning Jan 1 00:05:44 PPP link up (Internet) [87.xxx.xxx.xx]
Info Jan 1 00:05:44 FIREWALL event (1 of 19): deleted rules
It says Warning when you get a Yellow triangular exclamation mark
It says Error when you get a Red circle exclamation mark
It says Info when you get a Green circle letter i
It would have an identical entry in the GUI log to the example CLI log entry if I had one in my current log, except the <81> would be replaced by the word error.
HTH. I'll post back more info if/when I have it.

[#7]

I decided to read up on how this type of packet could be used to probe networks. Apparently the lack of a response would be used to infer the packet reached its destination and the target IP is online, but if an ICMP destination unreachable: host unreachable packet was generated by a router (as in gateway, not as in Technicolor) before the packet reaches its destination, that would indicate that the IP isn't online.
Source: ICMP Attacks Illustrated, page 5, "Inverse Mapping"

[#8]

I added an extra iptables rule to log whatever gets blocked by my router firewall. Over a couple of days I've not noticed any of these ICMP Destination Unreachable packets. Because the dmesg log buffer is tiny, and the log is sometimes cluttered up with other things, plus the router resets the firewall rules at midnight, I would only notice if there were a lot of them. With the Plusnet Firewall off, I can spot the occasional attempt to connect to common ports, the most popular tried is tcp port 445. Some of the other things logged are obviously related to valid web traffic, including IPs related to this forum.