NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Inter VLAN Traffic open between Multi-PSK SSID Connected VLANS - BUG
Hello, I run a PR60X via Insight, and have five vlans. My Core Switch is the MS510TXUP and intervlan routing as far as I am aware is done on the PR60X. When I log on directly to the MS510TXUP, its disabled. The Router Traffic Rules are quite limited, no feature to create IP/Network Groups, or select Interface Groups (LAN/VLAN) and in general, the featureset is quite disappointing (Yes, no IPv6 support, no Snort, no affordable Exium support for private/insight premium users, etc. Way to go, Netgear!) That rant had to be :-) I run five vlans with Class B Nets: 10.10.0.0/16 10.20.0.0/16 10.30.0.0/16 ... I run three SSID: 1: home -> connected to VLAN10 2: iot -> Multi-PSK connected to VLAN20, 30, 40 3: Guest -> connected to VLAN50 When I do a network sweep from the Multi-PSK Networks, every thing is open. I added a few allow lists in the Traffic Rules, but nevertheless, all is wide open, and no implicit DENY rule is applied. When I run a sweep from the Guest net, it seems there is an implicit DENY rule active. So the only difference is the Multi-PSK Network. This in my opinion is a dangerous and buggy approach to handle different SSID Types differently. The interesting thing is, all vlans are open, not only the three Multi-PSK connected VLANS. So where is this behavior documented, or is it at all? Anyway, should we find a way to have a simple solution for explicit catch-all DENY rules for inter-vlan traffic? How would we do that? Blocking the A-Net space (10.0.0.0/8) leaves the Router offline because the Rules block all VLAN Interfaces too. So do we need 5x5 Rules to explicitly block the ip subnets of each vlan from each vlan? Because just use Source Interface: VLANXX, Source IP Any, Destination Interface ANY, Destination IP ANY seems to block any Interface, so the router goes offline even when there is an explicit Allow rule beforehand. Help and Info much appreciated Thanks, MichaelIPSec Tunnel Not Starting
I have two PR60X with a IPSec tunnel connecting them over Verizon FIOS Business GB WAN connection. Tunnel ran fine without errors for almost 1 year. My IPSec tunnel stopped working after upgrading both PR60X to firmware V3.0.0.105. It was down for almost 24 hours and suddenly the tunnel started working without any changes. I double checked the IPSec configuration on both devices. No misconfiguration or changes. I powered down one PR60X to change location in rack, reconnected the router, but no IPSec tunnel. Waited approximately 10-11 hours and for some reason ... IPSec tunnel was working again. Anytime I reboot the router, the IPSec tunnel required 10-24 hours for it to start working again. Never had this problem with previous firmware. Any thoughts?BR500 & Insight Support
I'm looking to get input on how I have them not renew the support by Insight given the fact that this unit is no longer supported. I can't seem to find any way to do it from my console or support page because this unit doesn't have support anymore and there doesn't seem to be a Insight support that seems readily accessible.. I've tried emailing support but that doesn't seem to go anywhere either.PR460X crash
My PR460X on firmware 2.7.0.111 (current latest available) sometimes crashes. Stack trace from the crash logs below. This appears to be a firmware/driver bug. 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.476240] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1559 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.476262] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/3 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.483736] CPU: 3 PID: 0 Comm: swapper/3 Tainted: P 5.4.164 #0 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.491544] Hardware name: Generic DT based system 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.499016] [<4210fa8c>] (unwind_backtrace) from [<4210b870>] (show_stack+0x10/0x14) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.503608] [<4210b870>] (show_stack) from [<42738500>] (dump_stack+0x88/0xa8) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.511506] [<42738500>] (dump_stack) from [<4213e278>] (___might_sleep+0x13c/0x17c) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.518538] [<4213e278>] (___might_sleep) from [<42751ebc>] (down_write+0x18/0x70) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.526438] [<42751ebc>] (down_write) from [<42355ffc>] (debugfs_remove+0x24/0x60) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.533823] [<42355ffc>] (debugfs_remove) from [<3f7a8888>] (eip_ctx_final+0x38/0x68 [qca_nss_eip]) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.541396] [<3f7a8888>] (eip_ctx_final [qca_nss_eip]) from [<3f7ac310>] (eip_tr_inval_done+0x44/0x90 [qca_nss_eip]) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.550317] [<3f7ac310>] (eip_tr_inval_done [qca_nss_eip]) from [<3f7a8e88>] (eip_dma_napi_rx_poll+0x230/0x29c [qca_nss_ei p]) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.561080] [<3f7a8e88>] (eip_dma_napi_rx_poll [qca_nss_eip]) from [<425ffef8>] (__napi_poll+0x28/0xb8) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.572272] [<425ffef8>] (__napi_poll) from [<4260012c>] (net_rx_action+0xf0/0x280) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.581472] [<4260012c>] (net_rx_action) from [<42102148>] (__do_softirq+0xd0/0x280) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.589114] [<42102148>] (__do_softirq) from [<42120f20>] (irq_exit+0x74/0xd4) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.597097] [<42120f20>] (irq_exit) from [<42165810>] (__handle_domain_irq+0x90/0xb4) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.604129] [<42165810>] (__handle_domain_irq) from [<423ddc40>] (gic_handle_irq+0x58/0x90) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.612027] [<423ddc40>] (gic_handle_irq) from [<42101a78>] (__irq_svc+0x58/0x8c) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.620184] Exception stack(0xbe4c3f60 to 0xbe4c3fa8) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.627822] 3f60: 00000000 00014fd8 bedb2a34 42118140 00000000 ffffc000 00000000 42b06e48 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.632859] 3f80: 00000008 42b06ea8 42a41470 00000000 42b91730 be4c3fb0 42108b38 42108b3c 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.641017] 3fa0: 60000013 ffffffff 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.649177] [<42101a78>] (__irq_svc) from [<42108b3c>] (arch_cpu_idle+0x2c/0x38) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.652479] [<42108b3c>] (arch_cpu_idle) from [<42145038>] (do_idle+0xf8/0x274) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.660116] [<42145038>] (do_idle) from [<4214545c>] (cpu_startup_entry+0x18/0x1c) 2026-03-13T13:34:28+00:00 router.lan kernel: [ 40.667147] [<4214545c>] (cpu_startup_entry) from [<42102390>] (__enable_mmu+0x0/0x30)PR60X - Domain-Based Filtering in Firewall Traffic Rules
Dear Netgear Team, currently, the Traffic Rules feature only allows filtering based on IP addresses, ports, and services. While this works for many use cases, it is not sufficient for scenarios where modern services rely on dynamically changing IP addresses (e.g., CDNs or cloud-based endpoints). It would be highly beneficial to have the ability to define firewall rules based on domain names (FQDN). Ideally, this feature could include: support for FQDN in Traffic Rules automatic DNS resolution and IP updates in the background optional wildcard support (e.g., *.example.com) This enhancement would greatly improve real-world usability, especially in environments with IoT devices and cloud services. Thank you for considering this request. Best regards, Alex