[Solved] DNS query sent on wrong interface

actaully, It's working fine with the IR domain policy; I can split IR traffic and tunnel traffic. but when I want to add the cidr IP range, then pbr is not working properly. anywebsite.com domain with an Iranian IP range will go through a tunnel interface. also dnsmasq full is already installed

/usr/share/pbr/pbr.user.irancidr

#!/bin/sh
# This file is heavily based on code from https://github.com/Xentrk/netflix-vpn-bypass/blob/master/IPSET_Netflix.sh

TARGET_SET='pbr_wan_4_dst_ip_user'
TARGET_IPSET='pbr_wan_4_dst_net_user'
TARGET_TABLE='inet fw4'
TARGET_URL="/usr/share/pbr/irancidr.list"
TARGET_DL_FILE="/var/pbr_tmp_aws_ip_ranges"
TARGET_NFT_FILE="/var/pbr_tmp_aws_ip_ranges.nft"
[ -z "$nft" ] && nft="$(command -v nft)"
_ret=1

if [ ! -s "$TARGET_DL_FILE" ]; then
	uclient-fetch --no-check-certificate -qO- "$TARGET_URL" 2>/dev/null | grep "ip_prefix" | sed 's/^.*\"ip_prefix\": \"//; s/\",//' > "$TARGET_DL_FILE"
fi

if [ -s "$TARGET_DL_FILE" ]; then
	if ipset -q list "$TARGET_IPSET" >/dev/null 2>&1; then
		if awk -v ipset="$TARGET_IPSET" '{print "add " ipset " " $1}' "$TARGET_DL_FILE" | ipset restore -!; then
			_ret=0
		fi
	elif [ -n "$nft" ] && [ -x "$nft" ] && "$nft" list set "$TARGET_TABLE" "$TARGET_SET" >/dev/null 2>&1; then
		printf "add element %s %s { " "$TARGET_TABLE" "$TARGET_SET" > "$TARGET_NFT_FILE"
		awk '{printf $1 ", "}' "$TARGET_DL_FILE" >> "$TARGET_NFT_FILE"
		printf " } " >> "$TARGET_NFT_FILE"
		if "$nft" -f "$TARGET_NFT_FILE"; then
			rm -f "$TARGET_NFT_FILE"
			_ret=0
		fi
	fi
fi

return $_ret

I am talking about your IranDomain Policy, which uses ir.
That will only work if you use nftset/ipset, perhaps you are already doing that but if not enable it under Use resolver set support for domains

Yes, dnsmasq nft set is enabled, but my problem is with the cidr IP range list in PBR. I need to route it via the wan interface.

Did you already downloaded a list of IP addresses?

The TARGET_DL_FILE should point to your downloaded list of IP addresses

You can see if the list is added as an nft set with:
nft list set 'inet fw4' pbr_wan_4_dst_ip_user

I changed the script.
but still, I can't route the.com domain with the iran ip cidr range via the local internet interface.

#!/bin/sh

NETWORKS='irancidr'
_ret=0

for NETWORK in $NETWORKS
do
    while read -r p; do "/usr/sbin/nft" "add element inet fw4 pbr_wan_4_dst_ip_user { $p }" || _ret=1; done < "/usr/share/pbr/${NETWORK}.txt"
done

return $_ret

result(sample cidr range):

root@OpenWrt:~# nft list set 'inet fw4' pbr_wan_4_dst_ip_user
table inet fw4 {
        set pbr_wan_4_dst_ip_user {
                type ipv4_addr
                policy memory
                flags interval
                auto-merge
                comment ""
                elements = { 185.141.132.0/22, 185.141.168.0/22,
                             185.141.212.0/22, 185.141.244.0/22,
                             185.142.92.0/22, 185.142.124.0/22,
                             185.142.156.0/22, 185.142.232.0/22,
                             185.143.72.0/22, 185.143.204.0/22,
                             185.143.232.0/22, 185.144.64.0/22 }
        }
}

First this is a prerouting chain so only works for connected LAN clients, it does not work from the router as that should be set as output chain

A couple of things you can check:
Is the .com domain in the ip address range, you can check with nslookup
Is the pbr_wan_4_dst_ip_user set added to the pbr_prerouting chain? You can check with nft list chain 'inet fw4' pbr_prerouting
Are the rules applied: ip rule show

It is possible that the tunnel policy is executed before other policies, if tunnel policy is the default I would not set a policy but just a static default route in the main table.
this will route everything via the tunnel unless there is a policy via the WAN

1 Like

I am checking from client side.
.com domain is in the ip address range

Non-authoritative answer:
Name: ipnumberia.com
Address: 185.142.159.194 >> 185.142.156.0/22

router internet should be local internet at all, but on the client side, there should be 2 routes.

  1. Iran domains and Iran IP ranges should route via the WAN interface.
    2: Rest traffic should route via the IPv4-gre6 interface.
root@OpenWrt:~# nft list chain 'inet fw4' pbr_prerouting
table inet fw4 {
        chain pbr_prerouting {
                ip daddr @pbr_wan_4_dst_ip_cfg036ff5 goto pbr_mark_0x010000 comment "Direct Cloud"
                ip daddr @pbr_wan_4_dst_ip_cfg046ff5 goto pbr_mark_0x010000 comment "IranDomain"
                ip daddr @pbr_ipv4gre6_4_dst_ip_cfg066ff5 goto pbr_mark_0x020000 comment "Tunnel"
                ip daddr @pbr_wan_4_dst_ip_user goto pbr_mark_0x010000
                ip saddr @pbr_wan_4_src_ip_user goto pbr_mark_0x010000
                ether saddr @pbr_wan_4_src_mac_user goto pbr_mark_0x010000
                ip daddr @pbr_ipv4gre6_4_dst_ip_user goto pbr_mark_0x020000
                ip saddr @pbr_ipv4gre6_4_src_ip_user goto pbr_mark_0x020000
                ether saddr @pbr_ipv4gre6_4_src_mac_user goto pbr_mark_0x020000
        }
}
root@OpenWrt:~# ip -4 ro list table all
default via 172.18.15.x dev pppoe-wan table pbr_wan
default via 192.168.154.1 dev gre6-gre6 table pbr_wan proto static metric 2
8.8.4.4 via 192.168.154.1 dev gre6-gre6 table pbr_wan proto static metric 2
8.8.8.8 via 192.168.154.1 dev gre6-gre6 table pbr_wan proto static metric 2
192.168.1.0/24 dev wan table pbr_wan proto kernel scope link src 192.168.1.150
192.168.31.0/24 dev br-lan table pbr_wan proto kernel scope link src 192.168.31.1
192.168.154.0/30 dev gre6-gre6 table pbr_wan proto static scope link metric 1
default via 192.168.154.1 dev gre6-gre6 table pbr_ipv4gre6
default via 192.168.154.1 dev gre6-gre6 table pbr_ipv4gre6 proto static metric 2
8.8.4.4 via 192.168.154.1 dev gre6-gre6 table pbr_ipv4gre6 proto static metric 2
8.8.8.8 via 192.168.154.1 dev gre6-gre6 table pbr_ipv4gre6 proto static metric 2
192.168.1.0/24 dev wan table pbr_ipv4gre6 proto kernel scope link src 192.168.1.150
192.168.31.0/24 dev br-lan table pbr_ipv4gre6 proto kernel scope link src 192.168.31.1
192.168.154.0/30 dev gre6-gre6 table pbr_ipv4gre6 proto static scope link metric 1
default via 172.18.15.x dev pppoe-wan proto static metric 1
default via 192.168.154.1 dev gre6-gre6 proto static metric 2
8.8.4.4 via 192.168.154.1 dev gre6-gre6 proto static metric 2
8.8.8.8 via 192.168.154.1 dev gre6-gre6 proto static metric 2
85.15.1.14 via 172.18.15.x dev pppoe-wan proto static metric 1
85.15.1.15 via 172.18.15.x dev pppoe-wan proto static metric 1
91.107.x.x via 172.18.15.x dev pppoe-wan proto static metric 1
172.18.15.x dev pppoe-wan proto kernel scope link src 151.242.x.x
192.168.1.0/24 dev wan proto kernel scope link src 192.168.1.150
192.168.31.0/24 dev br-lan proto kernel scope link src 192.168.31.1
192.168.154.0/30 dev gre6-gre6 proto static scope link metric 1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 151.242.x.x dev pppoe-wan table local proto kernel scope host src 151.242.x.x
local 192.168.1.150 dev wan table local proto kernel scope host src 192.168.1.150
broadcast 192.168.1.255 dev wan table local proto kernel scope link src 192.168.1.150
local 192.168.31.1 dev br-lan table local proto kernel scope host src 192.168.31.1
broadcast 192.168.31.255 dev br-lan table local proto kernel scope link src 192.168.31.1
local 192.168.154.2 dev gre6-gre6 table local proto kernel scope host src 192.168.154.2
broadcast 192.168.154.3 dev gre6-gre6 table local proto kernel scope link src 192.168.154.2
root@OpenWrt:~# ip -4 ru
0:      from all lookup local
30000:  from all fwmark 0x10000/0xff0000 lookup pbr_wan
30001:  from all fwmark 0x20000/0xff0000 lookup pbr_ipv4gre6
32766:  from all lookup main
32767:  from all lookup default

Guys any idea? how to fix my problem

Run a traceroute/tracert/mtr from a lan client to the 185.142.159.194 and post here the results.
Also what does this return?
ip route get 185.142.159.194 from 192.168.31.2 iif br-lan

C:\Users\Win10>tracert 185.142.159.194

Tracing route to mail.p30hosting.com [185.142.159.194]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  OpenWrt.lan [192.168.31.1]
  2   131 ms   134 ms   131 ms  192.168.154.1
  3   133 ms   134 ms   134 ms  172.31.1.1
  4   131 ms   131 ms   131 ms  12022.your-cloud.host [116.203.160.231]
  5     *        *        *     Request timed out.
  6   132 ms   131 ms   132 ms  spine1.cloud1.nbg1.hetzner.com [85.10.246.25]
  7   388 ms   219 ms   444 ms  spine15.cloud1.nbg1.hetzner.com [213.133.112.41]
  8   135 ms   130 ms   131 ms  core11.nbg1.hetzner.com [213.239.203.101]
  9   135 ms   134 ms   135 ms  core4.fra.hetzner.com [213.239.245.33]
 10   136 ms   137 ms   134 ms  195.219.223.8
 11   139 ms   137 ms   135 ms  if-ae-25-2.tcore2.fr0-frankfurt.as6453.net [80.231.65.20]
 12     *      136 ms   135 ms  if-ae-9-2.tcore1.fnm-frankfurt.as6453.net [5.23.30.16]
 13   135 ms   163 ms   136 ms  if-ae-29-2.tcore2.fnm-frankfurt.as6453.net [195.219.156.151]
 14   214 ms   212 ms   211 ms  195.219.87.199
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21   222 ms   218 ms   221 ms  mail.p30hosting.com [185.142.159.194]
root@OpenWrt:~# ip route get 185.142.159.194 from 192.168.31.2 iif br-lan

185.142.159.194 from 192.168.31.2 via 172.18.15.x dev pppoe-wan
    cache iif br-lan

Run these and paste them here to have a look.