@Clive_A 

Thank you for your response and input, much appreciated.

I am focused on trying to identify what was triggering the logged entries for TCP-SYN "attack". 

Based on reading several other posts on the forum (https://community.tp-link.com/en/business/forum/topic/637224; https://community.tp-link.com/en/business/forum/topic/636216; and this new one https://community.tp-link.com/en/business/forum/topic/649386 ) it seems logical to conclude that trapping for RSTs could lead directly to the activity which is triggering the logged "attack".

From your response:

>> I don't know if you port mirroring for this.

>>>> I did have port mirroring configured. The OC200 (on MGMT vlan) was connected directly to the ER7206 on port LAN2 (port 6) with the PVID of my MGMT vlan. The port selected for mirroring was the WAN (port 2) and Mirror Mode was set to Ingress and Egress. I think this propagates a mirror of all WAN packets onto the MGMT vlan. The Wireshark report is from the MGMT vlan and filtered for "tcp:flags.reset==1". If any of those settings are incorrect I would welcome your input for correcting the settings.

>> So, I think it is not the same thing that was talked about in the TCP attack. 

>>>> I believe the settings as noted above should capture all RST responses to any incoming packets which were originating from either 1)the WAN or 2)the MGMT vlan.

>> You are capturing the packets between the OC200 and your PC, what would it relate to the router under attack?

>>>> I believe you are saying packets between the OC200 and my PC should not relate to generating a reported log event for the router being under attack and I certainly agree with that assertion.

>>This RST is not your PC checking the router ingress or egress, so that does not make a question because it is wrong in the first place.

>>>> The only RST which were seen by Wireshark were not originating from the WAN. However, if my setup was correct, Wireshark was seeing all RST responses to the WAN or MGMT vlan. The RST seen by Wireshark were between the OC200 and the Wireshark PC, so if those local RST were the only RST which were occurring then they shound not trigger a log entry. As expected, the log entries which were recurring every 10 minutes did stop when RST in Attack Defense was disabled. However, if the only RST which were occurring were internal then turning off reporting for this event just hides the error in reporting.

In any event, it seems better from a security perspective to have the RST response off. 

What might be more beneficial from a security perspecitve is to be able to log when the ER7206 would have sent an RST in response to a WAN packet but did not because RST response was diabled in Attack Defense.

Again, thanks for your time and input.

Carl

  @Clive_A 

Thanks for your reply. 

The improvements in logging are certainly appreciated and improve our ability to understand what's going on in our networks.

There is still an open point for which I would like a response. It is highlighted in red below.

>>This RST is not your PC checking the router ingress or egress, so that does not make a question because it is wrong in the first place.

>>>> The only RST which were seen by Wireshark were not originating from the WAN. However, if my setup was correct, Wireshark was seeing all RST responses to the WAN or MGMT vlan. The RST seen by Wireshark were between the OC200 and the Wireshark PC, so if those local RST were the only RST which were occurring then they shound not trigger a log entry. As expected, the log entries which were recurring every 10 minutes did stop when RST in Attack Defense was disabled. However, if the only RST which were occurring were internal then turning off reporting for this event just hides the error in reporting.

I concur with this quote from your previous response.

RST is also common and when you do a 443 access. It continued and is normal to me.

Therefore, to reduce it to a question: Given RST is common during 443 access, why are internal RST triggering a log entry in the context of security?

Perhaps I am not thinking correctly, in the context of security our primary concern is when a RST is triggered from a WAN packet only?

Thanks,

Carl

  @Clive_A 

I looked at your posts and could not identify the specific reference.

Would you please let me know the post to which you are referring below?

About your suggestion for that log, you might wanna take it to the solution post I replied to earlier and see how others think this.

 

Thanks,

Carl

  @clangren 

I had the same issue

after testing, it turned out for me at least,  to be external wireguard config files on VPS's i have which were pinging the router every 10 mins.  

You need to remove the following line from all your wireguard conf files and the TCP SYN packets attack will stop. 

PersistentKeepalive = 25

persistantkeepalive is not needed and in my case at least was removed, re-setup various external wireguard vpns.   Now it all works.

It's surprising that TP link didn't figure this out, 

  @Clive_A 

Well I don't know the level of resources you have to test with if any.  Anyway, apologies if i upset anyone, well I can't easily  test with wireshark due to physical access to the router,  but the attacks have been consistent for months if not years regular SYN attacks.   I can't be 100% sure without further testing, which i'm not going to do as the issue is sorted for me now, 

But i've getting them every 10 mins, for a while now after redoing all my WG configs on remote servers I get less than 1 a day.  compared to 6 an hour before.

If you want to replicate for testing.  I have been using cheap 1GB VPNs with Ubuntu 22.04 and installed, and wireguard using the roadwarrior script, 

https://github.com/Nyr/wireguard-install

then use the QR code in the terminal or cat the conf file.  It automatically has the persitantkeepalive in the roadwarrior script. 

Not suggesting this is everyone's issue , but those with regular TCP SYN packets attack in the logs should defiantly look at this.    The TCP vs UDP im not sure why wireguard would show as TCP SYN attack  But I know my issue it resolved and Im 99% sure it's not a coincidence due to the first time i noticed a drop in the attacks was the same day i reinstalled android on my phone. It had 3 or 4 wireguard profiles on it. 

So at first I suspected some malware on my phone that was deleted when reinstalling android,  but as i added things back to my phone the attacks came back.   I suspected wireguard persitant keepalive for a long time, but only got chance to test it a few days ago.

Just checked the OC200 again and 0 attacks. 

  @Clive_A 

10 mins is fine imho any shorter fills the events log in a few days.  

With wireguard I don't know if UDP is only used for the tunneling and TCP is used elsewhere.   But the attacks were coming in my case from the local devices as they were still coming even if I added a firewall rule to block all incoming globally.

So each device was trying to ping the remote wireguard servers and the router /oc200 was picking it up as an attack.   i'm sure of that.  If you're still not convinced then maybe just keep it in mind as a possible line of questioning when users are coming with similar issues.