Hi @SakamotoBlog 

Thanks for posting in our business forum.

SakamotoBlog wrote

  @Clive_A 

 

There is no setting.

 

 

Then, you seem to have a problem communicating with me. I have talked about it before...

 

Let me rephrase the points below so you understand what I mean?

 

1. No matter whether DDNS is set up or not, as long as you enter the URL, an error will appear.

2. URL = error, but IP address = okay.

3. Only ER707-M2 has a problem, the other ER605 has no problem

 

Because it has been mentioned above, it is a very clear question. How about you get the ER707 device, enter the URL, and you will see the error. Is it that difficult?

I mean if you have set up anything on the router which binds the DDNS. So, I read the OP in the beta test, it is NO-IP DDNS?

I find it hard to communicate with you because I am asking if you have any DDNS set on the router/controller. After all, judging from the backup you sent to the test team, they reported that you did not set up any DDNS. That information does not match the current situation.

So I am confirming this with you. I am asking a generic question about if you have configured DDNS on the router actually. Does not mean it has to be the Custom DDNS.

If you can confirm that you have set it up and everything is proper, I'll ask the team again to further analyze it. Do you get my point? I just need a confirmation from you so I can proceed with what I need to do and ask the test team to do what they gotta do.

Hi @sycshk 

Thanks for posting in our business forum.

sycshk wrote

 Dear @SakamotoBlog  and @Clive_A  

I have the same problem. Have you fixed this yet? Any ideas? I have reverse proxy that should bring me to the site. This worked for ER605 but not working for ER707-M2. I suspect they changed some codes that checks the referer header. I have added this to my reverse proxy header script so that it should work but it's still not working.

If you have any idea, please let me know as well.

 

proxy_hide_header Upgrade;
proxy_hide_header X-Powered-By;
add_header X-Content-Security-Policy "default-src 'self';";
add_header X-Frame-Options "SAMEORIGIN";
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Cache-Control "no-transform" always;
add_header Referrer-Policy "no-referrer" always;
add_header X-Robots-Tag none;
add_header X-WebKit-CSP "default-src 'self';";

I am aware of what you reported but this takes some time before we have a fix or workaround for you.

The team is working with the OP and finding the reason behind it.

If you don't mind, you may wait for a while.

If you want to help us debug this issue, you should remove anything unrelated to the sole DDNS config. It looks like that ER707-M2 might be the only model having this problem.

To help the debug, post your DDNS config here. I need to make sure that your DDNS domain is the same as the domain on the DDNS provider's. Please paste screenshots and mosaic-sensitive parts.

Dear @sycshk,

Certainly,

Thank you for your insights. Indeed, there seems to be an issue with the ER707. Following your suggestion, it might be related to a header error. However, the fact that the ER605, a similar product, doesn't have this problem up to the latest version raises questions about the inconsistency in code issues for products within the same category. This is a seemingly illogical situation.

I have set up a self-hosted Docker with a proxy header script, incorporating the rules you provided, and it effectively resolved the issue. Nevertheless, my domain is hosted on Cloudflare, and applying rules requires enabling CDN services, which is a drawback.

Therefore, both the self-hosted approach with rule implementation and the CDN-enabled rule application are temporary effective solutions.

Another workaround, if rules are not applied above, is utilizing the ER707's Custom DDNS. By intentionally entering incorrect information in fields other than the correct domain data and saving the configuration, the issue can also be resolved.

However, relying on triggering a bug event within the ER707 itself to make it function properly is not a recommended practice.

Do you have any suggestions on how to advise TP-Link on a better direction for fixing the ER707? Or should we confirm whether this issue has been addressed as an official issue to be investigated by TP-Link @Clive_A , especially since the ER605 doesn't exhibit similar problems?

Thank you for helping identify the root cause.

Best regards,

Hi @sycshk 

Thanks for posting in our business forum.

sycshk wrote

  @Clive_A I would like to help debug but I'm not too technical in this field. But from what I see I don't think it has anything to do with DDNS. Since when I had it setup, when no DDNS was set, it still has the same problem. I'm pretty sure it's to do with the http header issue.

ER707-M2 added Refer Check in DDNS. So, if the domain name in the config does not match what you have in the DDNS server at the provider end, it'll pop up this error.

What's your DDNS provider?

How do you set up the DDNS on the ER707-M2?

Does your Domain Name in the DDNS setup match the domain you registered on the provider's server? If possible, provide the screenshots.

  @Clive_A  @sycshk 

Allow me to provide additional information. 

Regarding the rules he provided in the proxy header script configuration, implementing these rules indeed eliminates the [Referer check failed] error. 

However, it results in an inability to log in. The primary objective of introducing these rules is to address the issue stemming from the [Referer check failed] error. 

Therefore, it is evident that there are concerns related to headers and CSRF.

Screenshots are attached to illustrate the process, similar to the steps shown in the video.

https://youtu.be/0JaNShUIcm8

If you have any further suggestions or solutions, please feel free to share. Thank you for your patient assistance.