MD5 support will be dropped at the end of April 2018 & date & time of the router is not updated

[Adham]

Hi

There is a bug on the router where when the router restarts, the date & time are not updated, I will have to go to "Schedule" then click on "Apply" to update the date and time according to the selected time zone there.

If I don't do this, the VPN won't work.

Also, Apple iOS is reporting that the MD5 support will be ended at the end of April.

See attached photo.

thx

[schumaku]

One more thread - well discussed and explained what is going on. Netgear promised firmware updates including SHA256 signed certificates for the still maintained routers to come in time. You would have discovered several posts with long lists or replies when taking a minute to search for "openvpn md5" before posting.

Ref. date/time config not set at startup - what ISP are you connected to? What firmware is in place on your router?

[Adham]

Firmware version V1.0.1.34

ISP: TPG Australia

One more thing, when the date & time are not updated, I'll have to do the following in the precise order to get the VPN fixed:

Advanced >> Security >> Schedule >> Apply >> Advanced Setup >> VPN Service >> Apply

If I don't follow this order, then VPN won't work.

Advanced >> Security >> Schedule >> Apply alone won't work

Advanced Setup >> VPN Service >> Apply alone won't work (if the date & time are not fixed)

[schumaku]

Advanced -> Administration -> NTP Settings ... is the default Netgear NTP server or a user preferred NTP server configured? If it's the second - by name or by IP?

Any signs of time/date problems in the Advanced -> Administration -> Logs after booting?

@Case850 - one of your "neighbours" downunder with a time/date problem on the D7800.

Thank you for the update - correct date/time is core for any kind of certificate usage, otherwise the OpenVPN will badly fail.

A little bit of investigation unveiled a longer talk about the similar time/date problem in 1.0.1.16, apparently fixed in 1.0.1.20 https://community.netgear.com/t5/DSL-Modems-Routers/Wrong-date-and-time-in-Nighthawk-X4S-D7800-V1-0-... - not sure if there are still some systematic issues around on this router.

[Adham]

One more thing, when the date & time are not updated, I'll have to do the following in the precise order to get the VPN fixed:

Advanced >> Security >> Schedule >> Apply >> Advanced Setup >> VPN Service >> Apply

If I don't follow this order, then VPN won't work.

Advanced >> Security >> Schedule >> Apply alone won't work

Advanced Setup >> VPN Service >> Apply alone won't work (if the date & time are not fixed)

---

 There are no NTP settings available on the router

 Here are the logs:

[OpenVPN, connection successfully] from remote IP address: masked, Thursday, April 05, 2018 20:26:09
[Time synchronized with NTP server] Thursday, April 05, 2018 20:25:00
[OpenVPN, connection fail] from remote IP address: masked, Thursday, April 05, 2018 20:24:29
[OpenVPN, connection fail] from remote IP address: masked, Thursday, April 05, 2018 20:23:24
....
[Internet connected] IP address: masked, Thursday, April 05, 2018 20:20:49
[Initialized, firmware version: V1.0.1.34] Thursday, April 05, 2018 20:20:24

There are no errors except for the openvpn but in the Schule screen, I can see that the date and time are set to a very old minimum value of timestamp or date & time.

[Adham]

One more thing, when the date & time are not updated, I'll have to do the following in the precise order to get the VPN fixed:

Advanced >> Security >> Schedule >> Apply >> Advanced Setup >> VPN Service >> Apply

If I don't follow this order, then VPN won't work.

Advanced >> Security >> Schedule >> Apply alone won't work

Advanced Setup >> VPN Service >> Apply alone won't work (if the date & time are not fixed)

---

 There are no NTP settings available on the router

 Here are the logs:

[OpenVPN, connection successfully] from remote IP address: masked, Thursday, April 05, 2018 20:26:09
[Time synchronized with NTP server] Thursday, April 05, 2018 20:25:00
[OpenVPN, connection fail] from remote IP address: masked, Thursday, April 05, 2018 20:24:29
[OpenVPN, connection fail] from remote IP address: masked, Thursday, April 05, 2018 20:23:24
....
[Internet connected] IP address: masked, Thursday, April 05, 2018 20:20:49
[Initialized, firmware version: V1.0.1.34] Thursday, April 05, 2018 20:20:24

There are no errors except for the openvpn but in the Schule screen, I can see that the date and time are set to a very old minimum value of timestamp or date & time.

[schumaku]

The last thing to try would be an (unpopular, yes ...) factory reset. You had to re-configure your DSL connection (or any other Internet connection requiring authentication), re-create NAT port forwardings, re-create DHCP reservations, ....

Before doing so, lets see if somebody else does come up with some smarter ideas.

[Adham]

Gone through the other discussion you mentioned, and this reply is the one.

What you're asking is what I already did, and it's not really helpful, only that reply which is exactly what I'm through, and is the best workaround for now.

[Adham]

Here is the links available and administration tab view, no NTP settings available

See attached photo

[schumaku]

No doubts your workaround should not work unless the time service would fail during a later attempt, too.

My stomach says this is work for Netgear Skunk Works department - more green bananas from Taiwan.

I feel bad, sorry.

[schumaku]

---

@Adhamwrote:

Here is the links available and administration tab view, no NTP settings available

---

Yes, got this from @Case850 post above already - one more inconsistent feature implementation.

[Adham]

@Case850 : 

This problem existed for too long even before we enabled Use VLANID, however since we are getting many users on the VPN, this issue is becoming critical in our environment. We cannot simply disable the VLAN due to the setup and the running environment of servers here. And we are not grouping the VLANs by tag group, we're using by bridge group instead. But again this setting is long after the VPN enabled and this issue was already there.

The IPTV  is set to DHCP & it's IP address is set to 0.0.0.0, these are the default settings (untouched) Not sure where we can disable it or edit it.

Edit: I just finished going through all links in the router, no page available for NTP settings nor IPTV

Another Edit: I have checked User Manual for D7800 and it seems that "IPTV" is linked to "Use VLAN", and there are no NTP settings mentioned there at all, in fact no NTP word exist in this manual. However in regards to "Use VLAN", we can't disable it.

[Adham]

@schumaku : would be nice if I can enable L2TP IPSec, but not sure if I can SSH the router? Is this possible and working for D7800?

[schumaku]

No (well, very unlikely). Required Kernel objects and code for tools and utilities required are missing. And then, never forget that OpenVPN is very sexy as it's using one protocol type and one port only - while L2TP IPSec is a different beast. Just like @Case850 - we're both are "just"  yet another community member(s).

[Adham]

Then let us please go back to the main topic of this discussion, is it possible to add this bug to the bug fixes list of the firmware? And have it fixed in the one of the next releases?

[schumaku]

The md5 signed certificate part should be already in the works as of writing. Any serious QA testing should unveil the date/time problem of course.

Anything is possible if

- Netgear does listen (they alreay received a nasty email ref. the D7800 issues you had shown here)

- Netgear does reply here (different from my emails [except of the R9000 project engineer] which are commonly not answered).

- ....

My trust level in this product line - read any Nighthawk or Orbi - and their ability to change in time is very low these days. Fellow @Case850 answer you already know - change products.

[Adham]

@schumaku:

This is a brand new router, doesn't make sense that we change it when the lifecycle of this router is not ended yet, and as part of our trust in NetGear, if there are any issues with Netgear products, we have had a belief that this shall be fixed and maintained by Netgear, otherwise, we should be considering alternatives to Netgear and migrate to a different vendor.

There is a bug that we see and experience, we provided the details here & reported, then we would expect Netgear to maintain that and continue delivering what is promised of good quality products.

Thanks

[Adham]

@Case850:

Not really sure why would we need to change the role to modem? Would this fix any issue here? 

We can't do this anyway because we are using routing functions. Again, currently, we are workaround this issue by the steps provided above:

Advanced >> Security >> Schedule >> Apply >> Advanced Setup >> VPN Service >> Apply

---

@Case850wrote:

The Netgear Nighthawks are curve of best fit products. Your wanting routing functions that a pure router delivers.

---

I would be agreeing if Netgear really provides a fix for this issue.
 

[Adham]

Again @Case850: Why should we buy another router when we already purchased this one expecting a functioning VPN functionality.

There are other vendors that can beat Netgear like LinkSys for 

This D7800 that we purchased is more expensive than this one, and yet this one's functionality seems to be better than D7800, this puts Netgear best curve Nighthawk on the side 🙂

If Netgear has no intentions of fixing this bug, please simply let us know so we can be aware of such cases and close this topic since no point. And have these considerations next time we decide to buy something.

[Adham]

@Case850: Can we get to the bottom line of this topic here, please? Would this bug be fixed or not? Can you know about this?

[Adham]

Thanks, @Case850, appreciate your help! You have great knowledge, but we're not really looking to buy another networking product for now. According to eBay and here in Australia, this EdgeRouters starting from $400+

[schumaku]

---

@Case850wrote:

Any thoughts on this latest option?

---

VPN Clients > TPG(VDSL) > D7800(Router mode) > (DMZ) EdgeRouter X VPN Server

Double NAT (also the DMZ is an all NATed thing) is a problem I would try to avoid, even with L2TP. The concern is that these Nightawk consumer devices aren't properly handling anything outside of TCP, UDP, ICMP in a correct way - specifically I'm talking about ESP (Protocol 50). Ther are often dirty patches in such consumer devices to allow what does show up as "IPsec passthrough" or the like in the specs. Some completely fail, other allow only one session, for some it works only for VPN client on the LAN, for others on the LAN ... overall a mess I would strongly suggest to avoid.