NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
DDOS Attacks causing disconnecting internet connection
My internet connection keeps on disconnecting and after going through the logs, there are DDOS attacks that is causing this. I had contacted my ISP to get new IP, that didn't work. I got the latest O...
The Orbi logs what it labels Denial of Service (DoS) attempts that it detects and recognizes. This is normal because there are so many folks out there causing mischief. My log contains many of them every day. In general, DoS attempts do not cause an Internet disconnect, and changing IP's has no effect because most of these DoS attempts are scanning every possible IP address, one after another.
If you can provide more information about your situation, there are Community members who have a lot of experience diagnosing how Orbi works. The discussion usually starts by asking what model of Orbi and firmware release is involved, the Internet Service Provider, and the specific brand and model of modem/router that the Orbi is connected to.
Then, how is the "disconnect" manifested? Is there a specifc circumstance or error condition?
CrimpOn wrote:
.......... My log contains many of them every day. ...........
Same here.Here is how my logs look like daily, still my Orbi is operational and I don't notice any effect of those attacks:
[DoS Attack: SYN/ACK Scan] from source: 185.152.66.166, port 25461, Monday, February 25, 2019 19:02:02
[DoS Attack: SYN/ACK Scan] from source: 195.181.162.116, port 25461, Monday, February 25, 2019 18:52:21
[DoS Attack: SYN/ACK Scan] from source: 195.181.162.116, port 25461, Monday, February 25, 2019 18:33:43
[DoS Attack: ACK Scan] from source: 17.252.105.75, port 5223, Monday, February 25, 2019 15:44:40
[DoS Attack: ACK Scan] from source: 17.252.105.75, port 5223, Monday, February 25, 2019 15:42:10
[DoS Attack: SYN/ACK Scan] from source: 223.15.229.232, port 443, Monday, February 25, 2019 15:31:04
[DoS Attack: RST Scan] from source: 62.201.225.70, port 3026, Monday, February 25, 2019 15:17:40
[DoS Attack: SYN/ACK Scan] from source: 223.111.239.80, port 443, Monday, February 25, 2019 15:14:36
[DoS Attack: SYN/ACK Scan] from source: 23.98.39.221, port 8787, Monday, February 25, 2019 15:02:50
[DoS Attack: SYN/ACK Scan] from source: 23.98.39.221, port 8787, Monday, February 25, 2019 14:55:12
[DoS Attack: ACK Scan] from source: 65.55.163.87, port 443, Monday, February 25, 2019 14:47:55
[DoS Attack: TCP/UDP Chargen] from source: 120.52.152.16, port 58914, Monday, February 25, 2019 13:28:39
[DoS Attack: TCP/UDP Chargen] from source: 45.79.19.150, port 49402, Monday, February 25, 2019 11:15:56
[DoS Attack: TCP/UDP Echo] from source: 120.52.152.16, port 58914, Monday, February 25, 2019 10:39:33
[DoS Attack: RST Scan] from source: 213.186.119.48, port 443, Monday, February 25, 2019 10:24:45
[DoS Attack: SYN/ACK Scan] from source: 195.181.162.116, port 25461, Monday, February 25, 2019 09:55:25
[DoS Attack: ACK Scan] from source: 157.55.134.17, port 443, Monday, February 25, 2019 09:22:03
[DoS Attack: SYN/ACK Scan] from source: 1.180.88.14, port 49153, Monday, February 25, 2019 09:03:14
[DoS Attack: SYN/ACK Scan] from source: 202.97.231.50, port 80, Monday, February 25, 2019 07:59:53
[DoS Attack: SYN/ACK Scan] from source: 202.97.231.50, port 80, Monday, February 25, 2019 07:56:23
[DoS Attack: SYN/ACK Scan] from source: 202.97.231.50, port 80, Monday, February 25, 2019 07:20:39
[DoS Attack: SYN/ACK Scan] from source: 202.97.231.50, port 80, Monday, February 25, 2019 07:07:38
[DoS Attack: SYN/ACK Scan] from source: 36.250.235.88, port 80, Monday, February 25, 2019 06:59:05
[DoS Attack: TCP/UDP Chargen] from source: 184.105.139.73, port 34242, Monday, February 25, 2019 05:13:32
[DoS Attack: TCP/UDP Chargen] from source: 52.73.169.169, port 51441, Monday, February 25, 2019 04:16:12
[DoS Attack: SYN/ACK Scan] from source: 180.101.150.30, port 80, Monday, February 25, 2019 04:05:12
[DoS Attack: TCP/UDP Chargen] from source: 212.64.111.52, port 16680, Monday, February 25, 2019 02:50:48
[DoS Attack: SYN/ACK Scan] from source: 124.67.215.6, port 80, Monday, February 25, 2019 02:31:01
[DoS Attack: SYN/ACK Scan] from source: 124.67.215.101, port 80, Monday, February 25, 2019 02:28:02
[DoS Attack: SYN/ACK Scan] from source: 120.221.200.146, port 80, Monday, February 25, 2019 02:02:38
[DoS Attack: SYN/ACK Scan] from source: 85.132.26.15, port 80, Monday, February 25, 2019 00:50:47
[DoS Attack: SYN/ACK Scan] from source: 117.174.129.84, port 80, Monday, February 25, 2019 00:34:52
[DoS Attack: SYN/ACK Scan] from source: 117.174.129.84, port 80, Monday, February 25, 2019 00:31:48
[DoS Attack: SYN/ACK Scan] from source: 111.7.187.216, port 80, Monday, February 25, 2019 00:16:53
[DoS Attack: SYN/ACK Scan] from source: 60.223.217.219, port 80, Sunday, February 24, 2019 23:56:58
[DoS Attack: SYN/ACK Scan] from source: 60.223.217.219, port 80, Sunday, February 24, 2019 23:54:36
[DoS Attack: SYN/ACK Scan] from source: 58.205.221.226, port 80, Sunday, February 24, 2019 23:45:14
[DoS Attack: ACK Scan] from source: 17.252.105.72, port 5223, Sunday, February 24, 2019 23:31:06
[DoS Attack: ACK Scan] from source: 17.252.105.72, port 5223, Sunday, February 24, 2019 23:28:36
[DoS Attack: ACK Scan] from source: 17.252.105.72, port 5223, Sunday, February 24, 2019 23:27:21
[DoS Attack: ACK Scan] from source: 17.252.105.72, port 5223, Sunday, February 24, 2019 23:26:05
[DoS Attack: SYN/ACK Scan] from source: 36.250.235.86, port 80, Sunday, February 24, 2019 23:20:51
[DoS Attack: SYN/ACK Scan] from source: 27.221.84.217, port 80, Sunday, February 24, 2019 23:00:29
[DoS Attack: SYN/ACK Scan] from source: 27.221.84.217, port 80, Sunday, February 24, 2019 22:55:52
[DoS Attack: SYN/ACK Scan] from source: 195.181.162.116, port 25461, Sunday, February 24, 2019 22:43:29
[DoS Attack: Ascend Kill] from source: 195.54.122.198, port 53, Sunday, February 24, 2019 22:42:06
[DoS Attack: SYN/ACK Scan] from source: 27.221.84.215, port 80, Sunday, February 24, 2019 22:35:53
[DoS Attack: SYN/ACK Scan] from source: 27.221.84.215, port 80, Sunday, February 24, 2019 22:34:07
These were false positive attacks. I did all that was suggested, including
isable backhauk daisy chaining, MIMO and Fast Roaming, shutting down the two satellites and just leaving the router. I thought it was my switch and router, but replacing those didn't do anything. We were not doing anything different, the disconnects on the router just happened. I woke up in the middle of the night and the disconnects were happening. I found an old ASUS router and hooked it up. It's been up for 3 days now. After googling and doing research online, this seems to be a common issue, and Netgear has not come up with any robust solution. I returned the Orbi and just stick with my ASUS that has been reliable for me now and in the past.
Problem may be in the response of the router to ping requests. Go to Advanced>WAN Settings and be sure the “Respond to Ping requests” is unchecked (disabled). If the router actually needs to respond to Ping (or ACK, SYN, or other DoS attacks), it will bury itself and you will get the magenta ring.
Unfortunately, if you are using OpenVPN through the firmware, enabling OpenVPN will automatically enable (check the box) for Respond to Ping requests. You cannot have one without the other. This is a major bug in the firmware. Netgear has known of this for 2 years, and there is no solution on the horizon.
almhuss wrote:
.....
Unfortunately, if you are using OpenVPN through the firmware, enabling OpenVPN will automatically enable (check the box) for Respond to Ping requests. You cannot have one without the other. This is a major bug in the firmware. Netgear has known of this for 2 years, and there is no solution on the horizon.
I overcame this limitation (enabling VPN will automatically enable Respond to Ping) by doing the following telnet command (this does not impact VPN, it will continue working and the router will stop responding to pings):
root@RBR50:/# config get wan_endis_rspToPing
You will get the default which is 1 (means Orbi should respond to WAN ping requests)
root@RBR50:/# config set wan_endis_rspToPing=0
root@RBR50:/# config commit