packages
packages copied to clipboard
openwrt
Https-dns-proxy option 'src' specifies invalid value 'lan'
Maintainer: Maintainer: @stangri Environment: (ipq40xx, Wallystech DR4029, 22.03 snapshot 20/8/22)
Description: after a fresh install I have to reload https-dns-proxy or my internet fails to operate on first boot upon doing that I get the error below when reloading my firewall.
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) option 'src' specifies invalid value 'lan'
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) skipped due to invalid options
I have dual DNSMASQ instances and I dont have anything called 'lan' except for the physical switch port name defined in the dts. I have interfaces named 'kids_lan' and 'adults_lan' and bridges called 'br-adults_lan' and 'br-kids_lan'
I'm not sure if it works correcly with multiple dnsmasq instances or networks named other than the expected conventional naming 'lan' It seems to be ignoring my source interface names when creating rules. i would expect the 'src' to be loaded as 'adults_lan' and 'kids_lan' for each instance.
config interface 'Adults_Lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option ip6assign '60'
option device 'br-Adults_Lan'
config device
option name 'br-Adults_Lan'
option type 'bridge'
list ports 'lan'
There's a setting in https-dns-proxy where you can configure it for specific dnsmasq instances.
If you have an idea on how I can identify multiple LAN interfaces whatever they are called, please let me know, I'm open to pushing a fix.
@jow- @feckert @neheb @aparcar @BKPepe -- if you have an idea for me on the issue above or a suggestion for improve these firewall objects so they don't trigger an error mentioned above, I'd appreciate it.
Would this work to get a list of them all ?
ubus list network.interface.*
that will list interfaces in the format network.interface.xxxx Then to get detailed information on that interface you can work out the interface instances.
ifstatus xxxx
I think that will work but there may be better ways or directly parsing the instance names or dhcp config file directly or something? But with switch to DSA I think things are now called devices?
As a temporary or alternative option could there be a config option to manually input the dnsmasq instances via the config file or manual entry on luci ?
Would this work to get a list of them all ?
The problem is not iterating over all interfaces, the problem is identifying which ones are LAN.
As a temporary or alternative option could there be a config option to manually input the dnsmasq instances via the config file or manual entry on luci ?
If there's a proper/elegant solution to identify the LAN interfaces, I'd rather implement that. As a temporary solution you may want to edit lines 152-161 of the /etc/init.d/https-dns-proxy and insert your actual LAN interface name instead of 'lan'.
Alternatively, you can turn off the the force_dns option to avoid warnings from firewall.
Thaks for the tip I did not know they were hard coded in init.d I have edited them for my purpose and it is happily working now, but yes an automated solution would be best.
Since no solution was proposed on how to identify/iterate over LAN interfaces with random names, maybe an alternative would be:
- Disable
force_dnssetting inhttps-dns-proxyconfig - Manually create the relevant firewall rules to hijack DNS requests from both of your renamed LANs.
Would it be possible to add the option to manually input the instance name via luci ? That is how adblock and a few other packages operate, at least it makes it functional for users with non standard interface names.
Would it be possible to add the option to manually input the instance name via luci ?
Instance of what?
Sorry just a wrong term used, I have my LAN segments configured as with dnsmasq under two different instances, in my case my instances are my LAN segments.
I should of said if I could manually type in my LAN interfaces into Http-dns-proxy as an alternative to proposed automatic recgonition of interfaces.
It would enable me to configure to make a working solution with non standard interface names all from luci.
would this be a potential solution ? it requiress the scapy library tho.
https://stackoverflow.com/questions/43040700/get-list-of-physical-interfaces-in-openwrt
in my case my instances are my LAN segments.
I'd be reluctant to introduce what you're asking for as very few people rename their LAN interface.
modifying the initscript is not really a workable solution as when you make changes to https-dns-proxy one must manually intervene and update the initscript.
If the lan segment names https-dns-proxy is attached to are incorrect there is no warning in the log of the failure to add firewall rules on the https-dns proxy luci interface it suggests everything is working correctly,
Is there a chance you can specify the lan segments to attatch to via the configfile and default to Lan if nothing is specified? Is it possible adding scripting to check the firewall rules are actually added via ubus and specify outcome on luci?
Please try the init script from this commit and add an option procd_fw_src_interfaces to the config file listing your "lan segments".
I used the updated initscript as suggested it but on restarting the firewall it still mentions invalid src lan This was my config:
config main 'config'
list force_dns_port '53'
list force_dns_port '853'
option dnsmasq_config_update '*'
option force_dns '1'
option procd_fw_src_interfaces 'adults_lan kids_lan'
option canary_domains_icloud '0'
option canary_domains_mozilla '0'
I used the updated initscript as suggested it but on restarting the firewall it still mentions invalid src lan This was my config:
config main 'config' list force_dns_port '53' list force_dns_port '853' option dnsmasq_config_update '*' option force_dns '1' option procd_fw_src_interfaces 'adults_lan kids_lan' option canary_domains_icloud '0' option canary_domains_mozilla '0'
Can I see the output/log of the service restart with the new init script? I'm not in a position to test it for about a week more. Also, how are the interfaces defined?
This is the error message on the firewall on restart:
ubus rule (ubus:https-dns-proxy[instance1] rule 1) option 'src' specifies invalid value 'lan'
ubus rule (ubus:https-dns-proxy[instance1] rule 1) skipped due to invalid options
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) option 'src' specifies invalid value 'lan'
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) skipped due to invalid options
my config files are on my github but I have two dnsmasq instances with two lan segments named adults_lan and kids_lan:
https://github.com/professor-jonny/pj_openwrt/blob/master/files/etc/config/dhcp
@professor-jonny Please try restarting RPCD and if things still don't work right, rebooting.
defiantly does not work tried restarting RPCD it still defaults to lan interface name despite the new config setting.
root@OpenWrt:~# /etc/init.d/https-dns-proxy restart
Starting https-dns-proxy dev-test ✓✓
root@OpenWrt:~# logread -e https-dns; netstat -l -n -p | grep -e https-dns
Wed Jun 14 23:27:09 2023 user.notice https-dns-proxy: Starting service ✓✓
Wed Jun 14 23:29:23 2023 user.notice https-dns-proxy: Starting service ✓✓
udp 0 0 127.0.0.1:5053 0.0.0.0:* 17218/https-dns-pro
udp 0 0 127.0.0.1:5054 0.0.0.0:* 17217/https-dns-pro
ubus rule (ubus:https-dns-proxy[instance1] rule 1) option 'src' specifies invalid value 'lan'
ubus rule (ubus:https-dns-proxy[instance1] rule 1) skipped due to invalid options
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) option 'src' specifies invalid value 'lan'
ubus redirect (ubus:https-dns-proxy[instance1] redirect 0) skipped due to invalid options
I don't get a fault now but I'm unsure if it worked?
it is a dnat redirect so the source is a zone or a lan interface?
It does not mention https-dns-proxy in the firewall chains etc...
and it does not show up in the port forwards in firewall rules.
I don't get a fault now but I'm unsure if it worked?
The way to check is to run service https-dns-proxy info and in the first instance data/firewall object check for the redirects.
Looks good to me as below the only thing that is weird is the reference to port 5053 and 5054. There is no port 5053 or 5054 firewall rules in the status menu but it is listed from the info command.
Are we able to add other hotplug triggers to other interfaces than wan also via a config option? I have a wwan interface as backup it would be nice to re init if wwan_4 or wwan_6 goes online.
root@OpenWrt:~# service https-dns-proxy info
{
"https-dns-proxy": {
"instances": {
"instance1": {
"running": true,
"pid": 28286,
"command": [
"/usr/sbin/https-dns-proxy",
"-r",
"https://cloudflare-dns.com/dns-query",
"-a",
"127.0.0.1",
"-p",
"5054",
"-b",
"1.1.1.1,1.0.0.1",
"-4",
"-u",
"nobody",
"-g",
"nogroup"
],
"term_timeout": 5,
"data": {
"firewall": [
{
"type": "redirect",
"target": "DNAT",
"src": "adults_zone",
"proto": "tcp udp",
"src_dport": "53",
"dest_port": "53",
"family": "any",
"reflection": false
},
{
"type": "rule",
"src": "adults_zone",
"dest": "*",
"proto": "tcp udp",
"dest_port": "853",
"target": "REJECT"
},
{
"type": "redirect",
"target": "DNAT",
"src": "kids_zone",
"proto": "tcp udp",
"src_dport": "53",
"dest_port": "53",
"family": "any",
"reflection": false
},
{
"type": "rule",
"src": "kids_zone",
"dest": "*",
"proto": "tcp udp",
"dest_port": "853",
"target": "REJECT"
}
],
"https-dns-proxy_5053": {
"service": "_https-dns-proxy._udp.local",
"port": 5053,
"txt": [
"DNS over HTTPS proxy"
]
},
"url": "https://cloudflare-dns.com/dns-query"
},
"respawn": {
"threshold": 3600,
"timeout": 5,
"retry": 5
}
},
"instance2": {
"running": true,
"pid": 28287,
"command": [
"/usr/sbin/https-dns-proxy",
"-r",
"https://dns.google/dns-query",
"-a",
"127.0.0.1",
"-p",
"5053",
"-b",
"8.8.8.8,8.8.4.4",
"-4",
"-u",
"nobody",
"-g",
"nogroup"
],
"term_timeout": 5,
"data": {
"https-dns-proxy_5054": {
"service": "_https-dns-proxy._udp.local",
"port": 5054,
"txt": [
"DNS over HTTPS proxy"
]
},
"url": "https://dns.google/dns-query"
},
"respawn": {
"threshold": 3600,
"timeout": 5,
"retry": 5
}
}
},
"triggers": [
[
"interface.*",
[
"if",
[
"eq",
"interface",
"wan"
],
[
"run_script",
"/etc/init.d/https-dns-proxy",
"restart"
]
],
1000
],
[
"config.change",
[
"if",
[
"eq",
"package",
"https-dns-proxy"
],
[
"run_script",
"/etc/init.d/https-dns-proxy",
"reload"
]
],
1000
]
]
}
}
Looks good to me as below the only thing that is weird is the reference to port 5053 and 5054.
Please clarify which references to 5053 and 5054 you mean.
There is no port 5053 or 5054 firewall rules in the status menu but it is listed from the info command.
I'm not seeing any fw rules for ports 5053/5054 in the info command.
It is possibly me not understanding Im guessing below is the ports for the upstream dns resolvers?
"https-dns-proxy_5054": {
"service": "_https-dns-proxy._udp.local",
"port": 5054,
"txt": [
"DNS over HTTPS proxy"
It is possibly me not understanding Im guessing below is the ports for the upstream dns resolvers?
This is data for umdns for automatic service discovery/bonjour. Actually it needs to be nested in the mdns object, this will be another bugfix.
mdns is port 5353 by default and provided in a reserved address range you have confused me.
config rule
option name 'mdns ipv4 allow (kids_lan 5353)'
option family 'ipv4'
option src 'kids_zone'
option src_port '5353'
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
config rule
option name 'mdns ipv6 allow (kids_lan 5353)'
option family 'ipv6'
list proto 'udp'
option src 'kids_zone'
option src_port '5353'
list dest_ip 'ff02::fb'
option dest_port '5353'
option target 'ACCEPT'