Use case:

(The specified firmware version is a custom version given to me by TP-Link over a year ago to fix an issue that stil has not been fixed in the latest current firmware release.  it is a known issue. Evidently they say the fix was not included even n the latest v1.2.3 firmware as it would require considerable work and I am the only customer who has come to them with this issue (WHAAAT???!?!?!??). They have offered to give me another Beta version built on top of v1.2.3 with the fix included.)

I do not understand why this is so hard for them to fix and also don't understand why I am the only one who has discovered this bug. Maybe there is an alternative?

When using even the best VPN service provider for internet access, if you select a specific server for the client tunnel - either due to the server itself or something in between, 100% uptime for the connection cannot be guaranteed, so setting this up in the router is a big pain because when the internet then goes down, you have to log into your router and then switch to a different tunnel for all of the devices. The way to resolve this is to have several tunnels open at the same time and pool them together into one connection, so it doesn't matter if some of the tunnels go down or come back up, as long as at least one in the group is working.

I have 5 VPN client tunnels from one VPN Service Provider, and another 5 VPN client tunnels from another VPN Service Provider, for a total of 10 tunnels open at the same time.

For some reason the only protocol that can be used with routing policies for pooling a group of VPN tunnels AS CLIENT is L2TP. I have had long discussions with TP-Link about this and I do not quite understand why, except I was told for OpenVPN, due to it's nature, that connection is initiated by the remote server instead of being controlled from my end, so there is no way of changing the routing policies for my devices for that because the changes have to take place on the server (other) end. In any event I would much prefer one of the newer protocols than L2TP but evidently that is the only one they support for routing policies as client.

Ideally I am trying to have the ability for turn on or off VPN internet access (rather than access to internet without a VPN) device by device on the local network from my router, and that is why the routing policies are required. 

I also selected two VPN service providers whose headquarters are NOT in any of the 9-eyes or 14-eyes countries - that also support L2TP (they are not easy to find).

The bug is, that for any one L2TP VPN Client tunnel, the settings required include:

Remote Server

Remote Subnet

For each VPN Service provider, the remote subnet is the same exact IP for all servers - which should be acceptable as that is an internal IP subnet to that server - the remote server names are unique (that is how I select what region (again in a non 9-eye and non-14-eye country) I prefer the server to be in for each tunnel). So for my 10 tunnels I only have two different Remote Subnets, one from each VPN Service Provider - the same for all of their servers. This makes sense - if you were a VPN Service provider, wouldn't you set up all of your servers to the same standard setup?

However, the internal logic for policy routing of this kind for the ER707-M2 router (evidently not a bug in the ER7206 model) - only examines the Remote Subnet, and when two of the tunnels in the same routing poolicy have the same Remote Subnet - the policy breaks (stops working) and the clients all have ful linternet access without using any vpn tunnel at all!

In discussions with the technical folks at TP-Link, the primary key for lookups for any routing rules in their logic is just the Remote Subnet as a programmer way back when assumed they would be unique. However they and I agree it should be a combined key of the Remote Server name and the Remote Subnet. They agree this is an issue but have not yet resolved it because they claim it would be a complete revamp of all of the logic used for policy routing. I am not sure why they also tell me however they will supply me with a beta firmware with the fix right after releasing the newer firmware (v1.2.3) if it was so hard to fix (!)

Also, for VPN tunnel as client, there are only three options - L2TP, PPTP and OpenVPN. PPTP security is much weaker than L2TP (so using PPTP would be like moving backwards), and OpenVPN can only work evidently as client if it is assigned to an entire vlan (rather than for routing within it). I noticed the VPN as client ALL require the Remote Subnet in their settings so maybe that has someting to do with the way they have written the code:

So above is my issue forcing me to stay on old beta firmware until they give me a new beta firmware based upon the latest firmware release.

Stepping back to my basic needs for pooling VPN Client tunnels (to servers not in any 9-eye or 14-eye country with a VPN service provider that does not have their headquarters in a 9-eye or 14-eye country) and having them included in routing policies.

I like my VPN service providers and they do also offer newer protocols other than L2TP so that selection has already been made and is not an issue. (I can also supply three or four configuration screenshots if that would help)...

What is my alternative - to be able to have routing policies for pooled client vpn connections for something newer than L2TP without having to have a custom beta firmware?

This is nuts!