Hi @Rigaro 

Thanks for posting in our business forum.

Can you point out a brand/vendor that supports this feature on their routers?

MisterW gave the solution by using the Policy Routing. That's the only proper way to use it.

Hi @Rigaro 

Thanks for posting in our business forum.

Except for Merlin open-source firmware. Any other vendor like Cisco or UNBT? We don't usually consider them as our competitors as they are more home-oriented. OpenWRT and other open sources as well.

Cisco, UBNT, and Mikrotec are more worthy of consideration and evaluation. Would appreciate it if you could offer some information about that as supplementary info.

Hi @Rigaro 

Thanks for posting in our business forum.

Rigaro wrote

  @Clive_A 

 

Cisco also has support for a kill switch in some models and if it is not available it is possible to use routing policies and firewall rules to accomplish the same result without any leaks. I can do the same thing with my TPLINK ER605, but the problem is that it leaks my actual IP for 15 to 20 seconds until the routing policies and firewall rules take effect.

 

Since I have not provided any public reviews about TPLINK, I think that it is time to provide my feedback and this security issue that I found because as a customer I expect that any hardware that I buy will have the expected behaviour regarding security and DNS leak is a very important issue.

 

This is an issue that affects business and home users and the reason why I bought these routers is that I'm testing different brands to establish connectivity between different locations and I don't want any location to be able to access their local internet connection directly.

I understand that. So the thing you said, Cisco supports that, can you list the models? I searched on Google and I don't find any models mentioning it. All I see is the software that Cisco has. Not their hardware routers.

Confirm your feature request again:

Your VPN usage scenario is to mask your real IP address in a Client-to-Site VPN. You hope that the router should have a kill switch feature on when it works as a client. Correct?

Hi @almeida123

If you don't want to provide, that's fine. I, personally, did not FORCE anyone to give proof or evidence. I need that for the report to the dev and that would be helpful for the dev to learn what others do when it comes to a function you ask. Fact is that I still report it if you don't have it.

This is not open source and everyone can add a line to it and make it functional. In the dev's eye, it's only a project and paperwork needs to be done on a project. It goes through the evaluation and is placed in the requests pool and is pending to be developed.

Usually, a feature that's available on the competitor device would bring the priority and schedule a little bit up.

If you look at every request I replied, I ask this every time because I know how the dev team works. I am working with the tech support and forum, and I am doing my best to provide any information that benefits both people and the dev. But I am not almighty and I don't program so I cannot do anything with your requests but report it. My reports simply reflect how many people want a feature and it could be just a number to the dev if I am not putting something convincing or informational.

Like I said, it takes time for a feature and if it fails the evaluation, that'll not be available. If I have a definite answer to a request that's been denied, I'll let people know.

Hi @tmp-link 

tmp-link wrote

  @Clive_A 

since i am not able to post a link, under restoreprivacy dot com, you can find a list of routers that support a kill switch

Among them are business routers like ASUS for example.

Please get this security issue fixed ASAP.

Thank you

Thank you for your feedback and post. We have forwarded your request to our developer team for evaluation.

To stay updated on firmware releases, we recommend subscribing to the pinned thread on the related page or regularly checking our official website where new releases are typically announced promptly.

Please note that all requests undergo thorough evaluation by our developer team before being added to the roadmap. This process may take some time, so please be patient if you don't see immediate results. Features with lower priority or fewer user reports might experience delays in implementation as we gather more feedback.

It is important to understand that submitting a request does not guarantee its implementation; only requests that pass the evaluation will be considered for inclusion in future updates.