Thank you very much for your answer, I’ll try it. But the day when the IP linked to the domain changes, you will also need to update the IP each time. In addition, does the IP of websites often change automatically?
Depends on the website. Those with few IPs tend to remain consistent. Larger, mega-websites (Amazon, Netflix, etc.) tend to change more often.
Another solution is to switch to DD-WRT, I read that we could directly set the rules for domain names (without IP).
I work w/ DD-WRT (and FreshTomato) on a regular basis (in fact, more often than Merlin), and routinely consult w/ one of the developers @ DD-WRT (@egc) to help maintain and enhancement it, the most recent contribution being the new OpenVPN kill switch. So I'm very familiar w/ other third-party firmware.
When it comes to destination IPs and routing policy (at least if we're talking about OpenVPN), afaik, there is no formal support for it in DD-WRT. The policy rules you're allowed to define are strictly in terms of the source ip/network, NOT the destination ip/network. Not unless something changed recently I don't know about (it's possible, I don't monitor DD-WRT changes on a daily basis). I know @egc did add some enhancements to the PBR field in the past year or so, but I don't know the full extent of it.
That's where Merlin probably has the upper hand. At least you can include the destination IP (and *only* the destination IP if you so choose) for a policy rule. But you can't use a domain name.
Even if you could use a domain name, that is typically implemented by resolving the domain name at the time the rule is added. IOW, it's static. And as long as the OpenVPN client is running w/o interruption, any underlying changes to the domain name will NOT be detected! You would have to periodically restart the OpenVPN client process to pick up any such changes.
If you *only* need to route specific destination domains through either the WAN or VPN (without concern for the source ip/network), you can always use OpenVPN's built-in routing facility to do so. You simply add appropriate route directives to the OpenVPN client's customization field.
Code:
route cnet.com 255.255.255.255 vpn_gateway
route google.com 255.255.255.255 net_gateway
vpn_gateway and net_gateway (which means WAN/ISP gateway) are reserved words. At runtime, OpenVPN will resolve those domain names (and the value of those reserved words) and add routes to direct those domains either over the VPN or WAN/ISP.
But even here, that name resolution is still static. Should the public IP(s) associated w/ those domain names change, they will NOT be detected until you restart the OpenVPN client process.
This is a common problem when dealing w/ policy based routing, regardless of the firmware. In order to *dynamically*, and in realtime, detect any changes in the IPs associated w/ a given domain, you need to use a completely different set of procedures, typically using ipset. But there is no such capability at the moment for this in Merlin. And the DD-WRT documentation only shows how YOU can set it up. The only firmware I know of that supports ipset w/ policy based routing in the GUI is FreshTomato (and has done so for YEARS).
Unfortunately, policy based routing, in all its forms, is inherently complicated. And trying to compare one implementation to another isn't as simple as it may appear at first blush. For example, although you can use route directives (as I described above) w/ Merlin, Merlin *ignores* any route directives bound to the WAN/ISP (net_gateway) whenever you use the VPN Director! Instead, you have to create policy rules to bind destination IPs to the WAN. But then you lose access to domain names for those purposes. Then again, at least you can qualify it w/ source IP if you find the need.
As I said, it's complicated. It's taken me YEARS to learn and appreciate all the subtle differences between the various firmwares. They all have advantages and disadvantages. And it's VERY difficult to explain all those differences within a few paragraphs of this forum.
So be careful about any assumptions you may have drawn about whether one or the other firmware is better for policy based routing or the handling of domain names. One of the reasons I use/recommend different third-party firmware w/ different customers is precisely because every customer's needs can't be met w/ just one of them. Some are better than others depending on the specific requirements. I find they *all* can be awesome given the right conditions. But they all have serious limitations too. The trick (and what takes experience) is learning which is better suited to a given set of conditions.
Knowing that I have two asus router that are connected:
The router "A" is the main router. It runs on Merlin with several plugins.
So on router "B" I switched it to merlin but I did not install any plugin because router "A" does all the work.
If I switch Router "B" to DD-WRT I will continue to enjoy the benefits of Router "A" plugins?
I assume router B is connected to router A, WAN to LAN respectively. IOW, router B and A maintain their own separate IP networks. That's good for isolation purposes (e.g., a guest or IOT network) on router B. But the amount of benefit that router B's network will gain from Router A's services/features is questionable, since from router A's perspective, there's only one IP on its network associated w/ router B's network, and that's the WAN ip of router B. If some AddOn (or built-in feature) is offering QoS, for example, you can't distinguish individual clients of router B for the purposes of prioritization. You'd probably have to change router B from Gateway to Router mode (to disable NAT). And that can present its own set of issues.
In short, you will probably derive *some* benefit w/ that arrangement, but just how much compared to using router A as your primary local network is hard to say. It just depends on the feature or AddOn. Something you'll have to determine on a case by case basis. In general, I don't recommend this type of configuration when router B ends up being your primary, private network. It works better when router B is truly secondary, such as guest or IOT network. But that's your call.
