Hi @Rigaro 

Thanks for posting in our business forum.

Rigaro wrote

Hi @pablosaad,

 

I agree with you. This is a security bug that the TP-Link dev team should take seriously. The routing and firewall rules should work immediately when the VPN connection is down instead of working 15 to 20 seconds later.

So, based on what I know about our product, our goal was never to compete with the vendors that provide proxy connections to bypass some censorship. So, we don't add the kill switch or consider it after several updates on the new VPN protocols.

If you think this is a security concern for your network, you may consider an alternative solution.

I know that a kill switch is critical for bypassing and masking your real IP address. But our product was meant to be S2S VPN. If for C2S, that'll be used with the Policy Routing and we don't consider getting too many features on that part as our main goal is to provide a solution for the business environment where they need S2S connection or C2S when the employees go out on a travel.

I totally understand that home users require enhanced privacy features like this but not really look promising for the PM.

Will keep recording and feedback on this but for this moment, it is not promising.

Hi @Rigaro 

Thanks for posting in our business forum.

Rigaro wrote

  @Clive_A 

 

You are missing the point. Based on your reply, I am sure you barely understand your company and product goals. Otherwise your reply would be more in line with providing good customer service and giving your customers confidence that TP-Link products are safe and work as expected. 

 

My apologies for the upper case, but I do not want you to miss the key point here.

 

THIS IS THE MAIN POINT THAT YOU ARE MISSING:

 

This is not about the kill switch itself or proxy connections to bypass some censorship. THIS IS ABOUT THE FACT THAT TP-LINK's ROUTING & FIREWALL RULES DO NOT TAKE EFFECT IMMEDIATELY.  IT IS NOT ACCEPTABLE THAT ROUTING POLICIES & FIREWALL RULES ARE TAKING EFFECT 15 TO 20 SECONDS LATER.

 

Regarding your comments:

"But our product was meant to be S2S VPN":

Please do not advertise that your product is good for C2S if your company did not design it for C2S. Also, the problem with routing policies and firewall rules also occurs in S2S setting. It is very concerning that it takes 15 to 20 seconds for the routing policies and firewall rules to work as expected.

 

If for C2S, that'll be used with the Policy Routing and we don't consider getting too many features on that part as our main goal is to provide a solution for the business environment where they need S2S connection or C2S when the employees go out on a travel."

 

"If for C2S, that'll be used with the Policy Routing and we don't consider getting too many features on that part as our main goal is to provide a solution for the business environment where they need S2S connection or C2S when the employees go out on a travel":

Again, you keep missing the point as you assume I bought this for home use. I have been evaluating different brands of products for a business application and TP-Link is the only brand with a problem with the routing policies taking effect 15 to 20 seconds after an event using S2S or C2S.

 

Again, please forget about the kill switch. This is what should happen, but is not happening:

 

IF Specific Condition=True THEN Specific ROUTING POLICIES AND FIREWALL RULES TAKE EFFECT IMMEDIATELY.

 

Finally, what is clear is that you and your company have little regard for your customers who trust and buy your company products.

 

Since you and your company 

I understand that you need the kill switch for instance to cut down the connection. But in what scenario do you use it?

That's what I want to know from you and why I explained it is meant for an S2S between two locations or a C2S for employees on travel.

Here's the question, if you are an employee out for the travel, what scenario do you need the kill switch?

Or you use it for proxy, what scenario do you need for the kill switch? Isn't that the case I discussed with you that censorship might be a concern that eventually leads to privacy or security in your eye?
My point is that we never try to make it very friendly for proxy if the router is working as a "client" to connect to a VPN server in which case you need the kill switch function as a client.

Note that we never advertise you can use it for proxy and bypass censorship. We also did not advertise the kill switch.

The point is that the device supports C2S VPN but it does not fit your purpose for your setup. You can consider this as a missing feature on the product but what I explained is that what you proposed might divert from the product purpose we initially designed.

Summarize this whole conversation:

1. The "security reason" was merely a result of your point of view as it does not disconnect timely. Not from our eye and our design purpose. So, here's the disagreement between us.

2. I had the same requests like yours when I was in the tech rep team. But no one was from the typical business scenario to request this feature. Most are for the home and proxy purposes.

3. I am open to hearing from you about the scenario you need for the business environment I described above(two scenarios for S2S and C2S). Until I have a proper scenario I can demo to the dev and PM, I will consider writing a more detailed report to them. I am only counting the numbers without any background or scenario in the report and you can imagine how important and attention it will get. Not to mention this mostly comes from the home users' requests.

4. About your comments on 15-20 sec to disconnect the connection. Do you have the Wireshark or any methods to show this to me?

Note that if the session of the VPN is disconnected, it will take effect immediately. What you said involved Policy Routing and VPN, my questions to reproduce this issue are:

a. What's the setup? VPN and Policy Routing you have configured.

b. Your test methodology and how do you monitor that time? 15-20 secs?

c. Can you rule out it might be a cache issue? Can you confirm this with the Wireshark which would be the strong evidence so I can forward it to the dev for an improvement if this is confirmed to be true?

I am okay to start a new thread with you to discuss this 15-20 sec delay which you commented.

Hi @pablosaad 

Thanks for posting in our business forum.

pablosaad wrote

TP-LINK 
 

This is a security issue , it is an important topic and there isn't excuses, 15 seconds in networking is a decade. 
 

If TP-Link can't manage advance networking features is better sell other things. I won't buy anything else from tp-link and I would like my money back for this 2 omadas :(

I don't know if you are using the same as the OP. If yes, please explain in detail. Start a new thread and we discuss this matter.

We don't provide a refund as we don't have a direct sell-and-buy relationship with you. We distribute the products to the retailers first and then they sell the individual products to the customers. If you need a refund, within the return window based on your retailer's policy, you may contact them for the refund. But if you made a procurement from our local company from a contract, you may directly contact our local company to submit a request for the feature and see if they can get you customized firmware. Only for the procurement users.

If that's the case, you are reluctant to buy any from us, that's a pity. It is your choice and we do respect that.

Feature request is not guaranteed and I did not guarantee this from the beginning of this thread. I was discussing this with the OP.

Second, I have filled out a chart to record the vote and request but this does not mean it will pass the evaluation. Not to mention the vote is merely 3 and one of the votes is mine. I agreed with the comments of the OP and that's the reason why I voted, too. I understand this is a feature that might be important for the home users.

Hi @wizard123 

Thanks for posting in our business forum.

wizard123 wrote

  @Clive_A 

 

Unifi's default behaviour for VPN client since a few versions back is to drop any routed traffic if the VPN goes down, you can also set in the policy routing to route specific IP to the VPN tunnel.

Along with this you can also set firewall rules that state if traffic is headed for VPN tunnel then allow but if headed for normal isp wan then drop so they have multiple ways of providing this now.

 

I have tested this on the udm pro and ucg ultra.

You can also do the same with fireguard not just open vpn.

Policy Routing is now only for L2TP protocol. Not for the OpenVPN and Wireguard.

Wireguard does not have to be considered in PBR as it is called peer instead of client and server(the line between the two is obscure as they are peers, not a specific client/server). If you need specific clients to use the full tunnel, you can set its parameters in the peer settings.

I also searched for something about the UBNT PBR in Wireguard. Nothing useful and doable and they don't seem to support it either. If you have some Reddit or any links, greatly appreciated.

Last comment, I don't understand. You mean they have the kill switch on the the Wiregaurd and OpenVPN(client) settings in UBNT?

And "drop any routed traffic", meaning the Internet access is completely down when it is disconnected so to inform the user that the VPN is disconnected. How long will it recover? Or manually recover it?