NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
FURRYe38
Apr 23, 2022Guru - Experienced User
New - RAX200 Firmware Version 1.0.6.138 Released
New Features and Enhancements:
Adds support to EU SKU for Router Analytic (RA) opt-in, opt-out feature
Removes support from China SKU for gaming VPN Funjsq
Security Fixes:
Fixes sec...
adm1r4lj
Apr 27, 2022Star
I can confirm that 1.0.6.138 DOES INDEED contain a DNS breaking bug for DHCP clients and any device using the RAX200 for DNS.
I spent the entire day debugging this, performing factory resets, up/downgrading firmware, etc. to see where it starts to come apart. From my testing starting with a factory-reset RAX200, everything seems to hold up well for my environment on 1.0.6.138 until I start to create DHCP reservations. The second I create one entry, any device using the RAX200 for DNS (both DHCP clients and devices manually pointing to the RAX200) are unable to receive DNS replies. The RAX200 receives the queries, but does not forward them out to the WAN interface. Deleting the DHCP reservations also does not fix the issue. When I downgrade back to 1.0.5.132, the bug is eliminated and everything works as expected. Switching between 1.0.5.132 and 1.0.6.138 with a fully populated DHCP reservation table confirms the bug exists in 1.0.6.138.
Until Netgear support can release a bugfix, these are the available options:
1. Run 1.0.5.132 until the bug is fixed, or
2. Run 1.0.6.138 and manually configure all client devices to use external DNS servers on the client itself. I have confirmed this works and was using this as a workaround during my debugging, though it is not a practical solution as many devices don't allow you the option to manually configure the device (IoT devices specifically).
CD_router_888
Apr 28, 2022Guide
Hi adm1r4lj crjohnson Crash83K nicoimages
Can you check when the issue is happened, the openvpn function is enable or not?
I know there is a DNS proxy crash issue when enabling the openvpn.
- nicoimagesApr 28, 2022Tutor
Hi
The OpenVPN function was enabled
Thanks
Nicholas
- Crash83KApr 28, 2022Guide
Yes. We are using OpenVPN. So this is the lynch pin?
- crjohnsonApr 28, 2022Guide
I too utilize OpenVPN. However, I can't speak to the 138's issues first hand due to having avoided the headache based on this discussion thread.
Again, very much appreciative of the contributions provided by all.
I don't mind leading the way testing the next firmware release in hopes of confirming resolution of identified issues.
- adm1r4ljApr 28, 2022StarWe have openvpn enabled on the RAX200. I will have some time later tonight to see if disabling it and upgrading to 1.0.6 will avoid the DNS issues.
- adm1r4ljApr 29, 2022Star
CD_router_888 FURRYe38 crjohnson Crash83K nicoimages -
These are my findings from yesterday:
- The DNS proxy crash issue triggers on 1.0.6 when we enable OpenVPN and reboot the RAX200.
- If we enable OpenVPN on 1.0.6 and do not reboot the RAX200, the DNS issue does not trigger. Tested working fine for approx. 2hrs.
- Reverting back to 1.0.5 eliminates this bug while maintaining VPN and DNS functionality after a reboot.
Hopefully a bugfix will be made available soon.
- FURRYe38Apr 29, 2022Guru - Experienced User
Is the DNS issue seen if OpenVPN not used at all? Just the router and default DNS settings?
adm1r4lj wrote:
These are my findings from yesterday:
- The DNS proxy crash issue triggers on 1.0.6 when we enable OpenVPN and reboot the RAX200.
- If we enable OpenVPN on 1.0.6 and do not reboot the RAX200, the DNS issue does not trigger. Tested working fine for approx. 2hrs.
- Reverting back to 1.0.5 eliminates this bug while maintaining VPN and DNS functionality after a reboot.
Hopefully a bugfix will be made available soon.
- adm1r4ljApr 29, 2022Star
FURRYe38 - not in our testing. When we disabled OpenVPN and rebooted the RAX200 under 1.0.6, the issue went away. When we enabled OpenVPN and rebooted, the issue resurfaced. Also if we disabled OpenVPN under 1.0.5 and then upgraded to 1.0.6, the issue did not resurface. So I'd say there is a pretty strong connection linking the DNS issue to having OpenVPN be enabled on 1.0.6 and something loading at boot-time which triggers this issue.