Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control.
If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

Wi-Fi Router Charts

Click for Wi-Fi Router Charts

Mesh System Charts

Click for Wi-Fi Mesh System Charts

Security Test

Doing a proper check of security products requires tools and knowledge beyond my expertise. So I stuck to a rather small set of tests. I confirmed that devices could be blocked and paused, which produced the block messages below when I tried to browse. If I stopped then restarted the block, however, I could not get the messages to reappear.

Core device block messages

Core device block messages

I did a quick check of web filtering by setting the Filter Level to Ages < 8 for the default shared category. I then went to Google and entered "porn" in the search bar and got plenty of search results, both listings and images. This is typical of any web filtering "solution" I've tried, which is why I don't spend much time testing web filtering.

I was more interested in testing Core's DPI/IPS/IDS features that are supposed to protect against bad things other than naughty websites. Despite the awesome power implied by these acronyms, packet inspection features on consumer routers, even those with multi-core processors, are pretty limited. They generally are limited to blocking access to internet servers known to host malware or other nasty stuff designed to mess you up, bigly.

Since I don't subscribe to AMTSO's (Anti-Malware Testing Standards Organization) Real Time Threat List (RTTL), I settled for running all's Malware tests. All 12 triggered the page shown below, once I bypassed the warning page Firefox first put up.

Core WICAR malware test result

Core WICAR malware test result

My last security test attempted to verify Core's claims to protect against rogue IoT devices. I did this by using nping to execute a SYN flood from a system on Core's LAN to a machine on its WAN, i.e. nping -tcp -p 5000 --flags SYN -c 10000 --rate 1000 10.168.X.Y I ran this multiple times, with not a peep out of Core.

Thinking the attack might not be enough to be seen as a compromised machine acting as a zombie in a DDoS attack, I then tried hping3 and the command lines suggested in this article. Again, no matter what I tried, Core didn't flag a thing. So if you're expecting Core to let you know if something on your network has been zombified and is being used to DDoS someone, that's not going to happen.

Routing Performance

The Core was tested with our new V10 router test process, loaded with 170927_191 firmware. It didn't do very well. Core has three levels of network inspection, which the app warns affect routing performance. I tested ran the test suite in all three modes, but the results posted in the Router Charts and used for ranking are with the Default setting.

Core Network Inspection Level

Core Network Inspection Levels

The table shows results for all three Core modes and includes results for the current top-ranked ASUS GT-AC5300. Yes, I know it's not a fair comparison, but it does show that Core's routing will not keep up with higher bandwidth internet services. Even if you used the Off mode—which would be nuts since it disables all the security that you bought the Core for in the first place—the HTTP scores show Core won't keep up with heavy traffic loads.

Test Description Norton Core (default) Norton Core (Off) Norton Core (Advanced) ASUS GT-AC5300
WAN - LAN Throughput (Mbps) 62.7 934 66.9 719
LAN - WAN Throughput (Mbps) 58.4 940 59.9 713
HTTP Score - WAN to LAN (%) 4.4 4.5 3.2 68.1
HTTP Score - LAN to WAN (%) 4.9 4.7 4.9 68.4
Bufferbloat Score- Down Avg. 1282 266 1259 450
Bufferbloat Score- Down Max. 253 235 253 317
Bufferbloat Score- Up Avg. 1133 521 1311 227
Bufferbloat Score- Up Max. 70 375 775 162
CTF Score (%) 6.2 - - 64.5
Firmware Version 170927_191
Table 2: Routing throughput

I thought it odd that Bufferbloat increased in the Off mode. But even then, we're talking latency of 3.7 ms average and 4.3 ms maximum for download and 1.9 average and 2.7 ms maximum. Default mode had average up and download latencies below 1 ms. The HTTP Score plots by filesize are below. Core never really gets out of the mud running in either direction.

HTTP Score comparison

HTTP Score comparison
Plot key file size: [A] 2 KB, [B] 10 KB, [C] 108 KB and [D] 759 KB file

I based the Cut Through Forwarding score on the worst case difference between routing throughput in default mode and both Off and Advanced mode. Yep, Core ekes out only around 6% of the Off mode throughput when running in its Default mode.

Support Us!

If you like what we do and want to thank us, just buy something on Amazon. We'll get a small commission on anything you buy. Thanks!

Don't Miss These

  • 1
  • 2