x3mRouting x3mRouting ~ Selective Routing for Asuswrt-Merlin Firmware

[Kingp1n]

L&LD do you have IVP6 enabled and are you using the DNS64 with unbound?

Oops guess I sld bring move this to the correct thread..I apologize!

 

[Skeptical.me]

@Skeptical.me, that's the spirit! Everything is good. Now... let's try to break it again!

Keep pushing for better and keep us informed of your trials too.

Btw, v2.06 of unbound_manager is working great here.

If you do get unbound working in your more complicated setup? You can always try IPv6 again too.

Thanks!

I may have over 500 posts but I can guarantee they're all questions, with a dash of advice. I hope I can give back as I go along.

I'm really grateful for this site.

 

[Xentrk]

I've been trying to do the same for the last week or so, but am struggling with the config.

I mined IP addresses for iPlayer and tried those and they work fine, but it seems that some websites then stop working - I assume I've included too much in the rules or the CDN providers are affecting traffic other than iPlayer.

The mined IPs were from a range of domains;

2x IPs - AKAMAI-AS, US
2x IPs - AKAMAI-ASN1, US
10x IPs - AMAZON-02, US
2x IPs - AMAZON-AES, US
2x IPs - BANDWIDTH-AS, GB
3x IPs - BBC BBC Internet Services, UK, GB
5x IPs - CLOUDFLARENET, US
2x IPs - GOOGLE, US
1x IP - HIGHWINDS3, US
1x IP - LLNW, US
10x IPs - MICROSOFT-CORP-MSN-AS-BLOCK, US
1x IP - SOFTLAYER, US
2x IPs - TEFINCOMSA-AS-AP TEFINCOM S.A., PA

Then I tried using the DNSMASQ scripts instead with domains I found on this and another page, but that doesn't appear to work at all and gives me the standard "you are not in the UK" error;

sh /jffs/scripts/x3mRouting/load_DNSMASQ_ipset.sh UKTV bbc.net.uk,bbc.co.uk,bbc.com,bbc.gscontxt.net,bbci.co.uk,ssl-bbcsmarttv.2cnt.net,itv.com,channel4.com,channel5.com,llnwd.net,edgefcs.net

Ideally I'd like to get iPlayer, ITV, Channel 4 and Chanel 5 all working via ipset tables if possible, as I don't want to force an entire device down the VPN and break local streaming.

Has anyone had any luck doing this recently or know of up to date ipset lists for these services as I notice the posts are from a couple of years ago that mention it.

Thanks.

I wiped my ipset lists for BBC and have it working using this combination. This requires the installation of openvpn-event using Option 6. I am routing BBC to client 3 in the example below:

/jffs/scripts/x3mRouting/vpnclient3-route-up (make sure the script is executable)

#!/bin/sh
logger -st "($(basename "$0"))" $$ Starting Script Execution

sh /jffs/scripts/x3mRouting/load_DNSMASQ_ipset_iface.sh 3 BBC2 www.bbc.co.uk,bbc.co.uk,bbc.com,bbc.gscontxt.net,bbci.co.uk,bbctvapps.co.uk,ssl-bbcsmarttv.2cnt.net

sh /jffs/scripts/x3mRouting/load_MANUAL_ipset_iface.sh 3 BBC

logger -st "($(basename "$0"))" $$ Endting Script Execution

Create the file /opt/tmp/BBC and place the following ip addresses in the file:

132.185.0.0/16
132.185.112.0/20
132.185.128.0/20
212.58.224.0/19
132.185.224.0/20

The sources of these addresses are from AS2818 and AS31459. You could also use the ASN method.

Restart the VPN client to set up the routing rules and populate the IPSET lists.

 

[dojrude]

I wiped my ipset lists for BBC and have it working using this combination. This requires the installation of openvpn-event using Option 6. I am routing BBC to client 3 in the example below:

/jffs/scripts/x3mRouting/vpnclient3-route-up (make sure the script is executable)

#!/bin/sh
logger -st "($(basename "$0"))" $$ Starting Script Execution

sh /jffs/scripts/x3mRouting/load_DNSMASQ_ipset_iface.sh 3 BBC2 www.bbc.co.uk,bbc.co.uk,bbc.com,bbc.gscontxt.net,bbci.co.uk,bbctvapps.co.uk,ssl-bbcsmarttv.2cnt.net

sh /jffs/scripts/x3mRouting/load_MANUAL_ipset_iface.sh 3 BBC

logger -st "($(basename "$0"))" $$ Endting Script Execution

Create the file /opt/tmp/BBC and place the following ip addresses in the file:

132.185.0.0/16
132.185.112.0/20
132.185.128.0/20
212.58.224.0/19
132.185.224.0/20

The sources of these addresses are from AS2818 and AS31459. You could also use the ASN method.

Restart the VPN client to set up the routing rules and populate the IPSET lists.

Why option 6? I'm not specifically routing clients, which seems to be what option 1 is for.
Wouldn't option 3 be enough?

Thanks for this. I'll give it a go later.

 

[Xentrk]

Why option 6? I'm not specifically routing clients, which seems to be what option 1 is for.
Wouldn't option 3 be enough?

Thanks for this. I'll give it a go later.

It is the solution I recommend if you want to have the script run at system start or when the OpenVPN client route is created. The other solution is to place the script in /jffs/scripts/nat-start. See more details on the Run Scripts at System Boot section on the README.

 

[dojrude]

It is the solution I recommend if you want to have the script run at system start or when the OpenVPN client route is created. The other solution is to place the script in /jffs/scripts/nat-start. See more details on the Run Scripts at System Boot section on the README.

Tried installing option 1, 3 and 6 and following your instructions, but it appears to break routing when enabling OVPN2 even if no scripts/rules are configured.
OVPN2 is configured with Exclusive DNS, Policy rules routing and the Dummy VPN entry, nothing more.

I have 3 OVPN connections, 1 server 10.8.0, and 2 clients 10.8.1 and 10.7.3

As soon as I start the OVPN2 client connection, I get some additional routes that break DNS and internet access for the entire network.

Without x3mscripts installed;
# ip route
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.51.xxx.xxx dev ppp0 proto kernel scope link
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.1.0/24 dev tun12 proto kernel scope link src 10.8.1.4
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.2
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
default via 103.51.xxx.xxx dev ppp0

After x3mscripts are installed;
# ip route
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.51.114.7 dev ppp0 proto kernel scope link
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.4
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.2
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link
default via 103.51.xxx.xxx dev ppp0

I get 2 additional routes and one duplicate;
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.4
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link

The tun12 route appears to be a duplicate of an existing tun21 route which doesn't occur when the scripts are removed.
I assume the 0.0.0.0 via tun21 is attempting to send everything via tun21, which is what's breaking things.

Do the scripts do anything without being manually invoked or does starting and stopping an OVPN client interface call the scripts?

Seems very strange that as soon as I remove the x3mscripts repository and restart the OVPN client everything comes back to life and those 3 differing routes disappear.

 

[Xentrk]

Tried installing option 1, 3 and 6 and following your instructions, but it appears to break routing when enabling OVPN2 even if no scripts/rules are configured.
OVPN2 is configured with Exclusive DNS, Policy rules routing and the Dummy VPN entry, nothing more.

I have 3 OVPN connections, 1 server 10.8.0, and 2 clients 10.8.1 and 10.7.3

As soon as I start the OVPN2 client connection, I get some additional routes that break DNS and internet access for the entire network.

Without x3mscripts installed;
# ip route
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.51.xxx.xxx dev ppp0 proto kernel scope link
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.1.0/24 dev tun12 proto kernel scope link src 10.8.1.4
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.2
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
default via 103.51.xxx.xxx dev ppp0

After x3mscripts are installed;
# ip route
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.51.114.7 dev ppp0 proto kernel scope link
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.4
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.2
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link
default via 103.51.xxx.xxx dev ppp0

I get 2 additional routes and one duplicate;
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.4
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link

The tun12 route appears to be a duplicate of an existing tun21 route which doesn't occur when the scripts are removed.
I assume the 0.0.0.0 via tun21 is attempting to send everything via tun21, which is what's breaking things.

Do the scripts do anything without being manually invoked or does starting and stopping an OVPN client interface call the scripts?

Seems very strange that as soon as I remove the x3mscripts repository and restart the OVPN client everything comes back to life and those 3 differing routes disappear.

I haven't had anyone report a similar issue before. What router model and firmware version are you using?

The x3mRouting scripts don't create any of the routes that are displayed when using the ip route command. The scripts do create policy rule priorities for each fwmark in the Routing Policy Database (RPDB). iptables rules are used to route the traffic thru the RPDB.

Make sure you have the router IP address to the WAN in the first OpenVPN client instance you use:

The below appears that the 10.8.0.0 subnet list for tun21 and tun12 doesn't look right unless it is a typo.

10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.4

You could shut down the OpenVPN Server and Clients. Then, bring them up one by one to see how your server and clients create the routes to help narrow down the source of the issue.

 

[dojrude]

Make sure you have the router IP address to the WAN in the first OpenVPN client instance you use:

View attachment 21291

I've never had to do this before.
Both VPN clients are configured for policy rules, so wouldn't only matching traffic be directed down the tunnel?
I don't understand the need to exclude the router.

Unfortunately my router is not an Asus, so I'll stop there.

I'll try doing one thing at a time as suggested, but the issue is that everything else is up and running with no issue. It's only this pursuit of trying to get iPlayer working that's causing me the issues.

Thanks.

 

[Xentrk]

I've never had to do this before.
Both VPN clients are configured for policy rules, so wouldn't only matching traffic be directed down the tunnel?
I don't understand the need to exclude the router.

Unfortunately my router is not an Asus, so I'll stop there.

I'll try doing one thing at a time as suggested, but the issue is that everything else is up and running with no issue. It's only this pursuit of trying to get iPlayer working that's causing me the issues.

Thanks.

My recommendation to route the routers IP address to the WAN is based on my experience of testing policy routing with multiple concurrent OpenVPN Clients. Things didn't work as expected without the entry. I wrote an explanation in the Policy Routing article on my blog post. Below is the explanation from the page:

OpenVPN Client Priorities
The Asuswrt-Firmware supports up to five OpenVPN Clients running concurrently. OpenVPN Client 1 has a higher priority than OpenVPN Client 2. OpenVPN Client 2 has a higher priority than OpenVPN Client 3 and so on. From my experience, If you have more than one OpenVPN client active, you must configure the router’s IP address to use the WAN interface. If you are using more than one OpenVPN Client, you only have to add the router’s IP address entry in the OpenVPN Client screen with the highest priority. For most people, this will be the OpenVPN Client 1 screen.

Defining the router’s IP address to use the WAN interface and the priorities of the OpenVPN Clients is the first place to look if you experience issues with Policy Rules or traffic is not going where you expect it to.

 

[dojrude]

Seems it's option 6 that's causing me issues.

With just option 1 and 3 installed and restarting OVPN2 client I get the following routes;
# ip route
103.51.xxx.xxx dev ppp0 proto kernel scope link
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.3.0/24 dev tun12 proto kernel scope link src 10.8.3.2
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.7
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
default via 103.51.xxx.xxx dev ppp0

If I then install option 6 and restart OVPN2 I get some additional conflicting routes;
# ip route
103.51.xxx.xxx dev ppp0 proto kernel scope link
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.12
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.7
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link
default via 103.51.xxx.xxx dev ppp0

I had added the router WAN policy rule to OVPN1 prior to this testing.

Not sure what option6 is doing. Is it just the single OpenVPN-event script that gets installed?
I've tried renaming the script to old-openvpn-event and restarting the client, but the additional routes are still there.
Then I deleted the script and restarted the OVPN2 client again and the routes have returned to normal.

 

[The Chief]

OpenVPN GUI doesn't work with 384.15 on AC86U. After adding ipset rule and hitting «Apply» it just does nothing, just stuck in «Applying settings…» forever. What i've done wrong?

 

[Xentrk]

OpenVPN GUI doesn't work with 384.15 on AC86U. After adding ipset rule and hitting «Apply» it just does nothing, just stuck in «Applying settings…» forever. What i've done wrong?

I just tested the OpenVPN GUI with 384.15 on AC88U and it tested out okay. The last patch was made on 2 January, 2020. Run the x3mRouting menu and check for updates. If you still have issues, look in the system log for clues. I find it very helpful using Scribe+uiScribe to view the system log in real time. I will hit the apply on one browser tab and switch to a new browser tab that has the system log open for viewing.

 

[Xentrk]

Seems it's option 6 that's causing me issues.

With just option 1 and 3 installed and restarting OVPN2 client I get the following routes;
# ip route
103.51.xxx.xxx dev ppp0 proto kernel scope link
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.3.0/24 dev tun12 proto kernel scope link src 10.8.3.2
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.7
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
default via 103.51.xxx.xxx dev ppp0

If I then install option 6 and restart OVPN2 I get some additional conflicting routes;
# ip route
103.51.xxx.xxx dev ppp0 proto kernel scope link
185.134.22.235 via 103.51.xxx.xxx dev ppp0
103.137.14.179 via 103.51.xxx.xxx dev ppp0
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
10.8.0.0/24 dev tun12 proto kernel scope link src 10.8.0.12
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.7.3.0/24 dev tun11 proto kernel scope link src 10.7.3.7
169.254.0.0/16 dev eth0 proto kernel scope link src 169.254.167.22
127.0.0.0/8 dev lo scope link
0.0.0.0/1 via 10.8.0.1 dev tun21 scope link
128.0.0.0/1 via 10.8.0.1 dev tun21 scope link
default via 103.51.xxx.xxx dev ppp0

I had added the router WAN policy rule to OVPN1 prior to this testing.

Not sure what option6 is doing. Is it just the single OpenVPN-event script that gets installed?
I've tried renaming the script to old-openvpn-event and restarting the client, but the additional routes are still there.
Then I deleted the script and restarted the OVPN2 client again and the routes have returned to normal.

You may have to purchase an Asus router to get this to work. I have no clue why the routes are getting created as x3mRouting only uses the routes established by the firmware and does not create them. No one else has reported an issue like this. Hope we can solve it though.

Option 6 installs the openvpn-event file and creates a line in /jffs/scripts/openvpn-event to call the openvpn-event script in the x3mRouting directory. You must then create the scripts you want run based on the events in the x3mRouting directory, such as vpnclient3-route-up, vpnserver1-down, vpnserver1-up, etc

The following is required so the scripts run when the vpnclient connection has been established.

If you use Method 1 - x3mRouting for LAN Clients Method combined with Method 3 - x3mRouting IPSET Shell Script Method, don't use the nat-start method. Instead, select Option 6 - Install x3mRouting OpenVPN Event from the installation menu. In the project directory /jffs/scripts/x3mRouting, create a corresponding script called vpnclientX-route-up for each OpenVPN Client used for x3mRouting, where the "X" is the OpenVPN Client number 1, 2, 3, 4 or 5. Then, add the required entry for each x3mRouting script that requires routing through the OpenVPN Client.

/jffs/scripts/x3mRouting/vpnclient1-route-up example

#!/bin/sh
sh /jffs/scripts/x3mRouting/load_AMAZON_ipset_iface.sh 1 AMAZON-US US
sh /jffs/scripts/x3mRouting/load_ASN_ipset_iface.sh 1 NETFLIX AS2906
sh /jffs/scripts/x3mRouting/load_DNSMASQ_ipset_iface.sh 1 HULU_WEB hulu.com,hulustream.com,akamaihd.ne

Remember to make the script executable.

Curious as to why tun12 uses 10.8.3.0 in the first scenario.

10.8.3.0/24 dev tun12  proto kernel  scope link  src 10.8.3.2

Then it is 10.8.0.0 in the second scenario

10.8.0.0/24 dev tun12  proto kernel  scope link  src 10.8.0.12

This is an example of the fwmarks and the routing policy database rules created by x3mRouting.

ip rule command example

0:      from all lookup local
9990:   from all fwmark 0x8000/0x8000 lookup main
9991:   from all fwmark 0x3000/0x3000 lookup ovpnc5
9992:   from all fwmark 0x7000/0x7000 lookup ovpnc4
9993:   from all fwmark 0x4000/0x4000 lookup ovpnc3
9994:   from all fwmark 0x2000/0x2000 lookup ovpnc2
9995:   from all fwmark 0x1000/0x1000 lookup ovpnc1
10104:  from 192.168.1.150 lookup ovpnc1
10105:  from 192.168.1.151 lookup ovpnc1
10106:  from 192.168.1.153 lookup ovpnc1
10107:  from 192.168.1.154 lookup ovpnc1
10301:  from 192.168.1.165 lookup ovpnc2
10302:  from 192.168.1.149 lookup ovpnc2
10303:  from 192.168.1.152 lookup ovpnc2
32766:  from all lookup main
32767:  from all lookup default

This shows the iptables table chain that handle the routing rules for the IPSET lists.

iptables -nvL PREROUTING -t mangle --line

Chain PREROUTING (policy ACCEPT 5808K packets, 6404M bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        1    60 MARK       all  --  tun13  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
2     661K  863M MARK       all  --  tun15  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
3        1    60 MARK       all  --  tun14  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
4    76880   70M MARK       all  --  tun12  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
5    2030K 2737M MARK       all  --  tun11  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
6        0     0 MARK       all  --  tun21  *       0.0.0.0/0            0.0.0.0/0            MARK xset 0x1/0x7
7        0     0 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set NETFLIX dst MARK set 0x1000
8    1067K   60M MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set HULU_WEB dst MARK set 0x1000
9    33488 6945K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set AMAZON dst MARK set 0x1000
10    129K 9898K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set MOVETV dst MARK set 0x3000
11   27284 5635K MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set CBS_WEB dst MARK set 0x3000
12       0     0 MARK       all  --  br0    *       0.0.0.0/0            0.0.0.0/0            match-set BBC dst MARK set 0x4000

 

[Olivier L]

Hello
I have a list of IPs (txt file, exclusion list) for which I want my LAN clients 192.168.1.192/28 to bypass VPN client 2.
Is there a simple way to do so ? I want to avoid to manually add a rule for each IP of my exclusion list.
Thanks

 

[Skeptical.me]

This might seem like a dumb question, but I ask as I have no idea. When you run, say, 2 OpenVPN clients in Merlin, does each client connect from VPN > WAN, or does the second VPN connection connect through the Tunnel of the first?

 

[L&LD]

@Skeptical.me, they each run through WAN in parallel.

 

[Skeptical.me]

@Skeptical.me, they each run through WAN in parallel.

Excellent, thank you.

 

[Xentrk]

Hello
I have a list of IPs (txt file, exclusion list) for which I want my LAN clients 192.168.1.192/28 to bypass VPN client 2.
Is there a simple way to do so ? I want to avoid to manually add a rule for each IP of my exclusion list.
Thanks

x3mRouting Lan Clients Method will create a text file with device name and ip address from dhcp static lease entries and allow you to assign the interface.

 

[Olivier L]

not sure I have understood how to proceed with Lan Clients method.
To be clearer here is what I want to do.

For exemple 192.168.1.192 is set to use VPN client 2 (thanks to UI). But I want an exception rule, meaning for a list of public IPs I want 192.168.1.192 to use WAN interface.

 

[Xentrk]

not sure I have understood how to proceed with Lan Clients method.
To be clearer here is what I want to do.

For exemple 192.168.1.192 is set to use VPN client 2 (thanks to UI). But I want an exception rule, meaning for a list of public IPs I want 192.168.1.192 to use WAN interface.

If you just have a handful or two of IP address, you can specify the list in the GUI. Check out the Policy Routing Guide and see if this will be a good fit for you. Otherwise, we will need to create an IPSET list that contains the source and destination address if the list of IP addresses is large.

In the example below 192.168.1.0/24 is the range for 192.168.1.1 through 192.168.1.254. This rule routes all traffic through the VPN interface. In the second rule, 192.168.1.50 is the LAN IP address for one LAN Client and 173.252.64.0/19 is the CIDR notation for Facebook. All traffic from 192.168.1.50 will use the VPN interface, except for the Facebook traffic, which will get routed to the WAN interface.

Router    192.168.1.1       0.0.0.0            WAN
LAN       192.168.1.0/24    0.0.0.0            VPN
Laptop    192.168.1.50      173.252.64.0/19    WAN