Big wireguard subnet vs dnsmasq localserivce

Hi all,

I do have two solutions to a local dns resolution problem and like to discuss the implication of both.
What I am having is a remote machine connected to my local OpenWrt via wireguard vpn. The remote machine needs to resolve dns names against the local OpenWrt dnsmasq. What I have learned is that because of localservice '1' in dnsmasq conf I can not set up the wireguard interface on the router as an /128 ipv6 network (only want to use ipv6 by the way).

The current (working) configuration looks like this:

config interface 'wg0'             
        option proto 'wireguard'        
        option private_key 'xxx'
        option listen_port 'xxx'                                                                      
        list addresses 'x:x:x:x::x/64'

As you can see I reverted back to a /64 network which works with the dnsmasq default settings. I could of cause change the localservice value but that seams like not being the thing I want to do?

So the question is:
Does anyone know of any other implications for setting the size of the subnet of an wireguard interface?

So is the WG interface address a public one you're getting from your upstream ISP?

Because normally you get a /48 or /56 from your ISP, and then each IPv6 device/client in turn gets assigned a /64 to generate it's own unique addresses from. Every phone and toaster is supposed to get a /64 by design.

I'd keep it as it is, keep your dnsmasq configuration (add list interface 'wg0'). Test if traffic is flowing in both ways properly without any packet drop, run nmap scans to see if you're leaking any ports or are able to access any subnets you might want to keep hidden from your wireguard clients, etc.

1 Like

It looks like you are mixing the WG interface mask with the allowed IPs mask.
Typically, the former is /64 while the latter can be limited to /128.

Sorry I did not show the other side of the connection (server):

PublicKey = xxx
PresharedKey = xxx
Endpoint = my.domain:xxx
AllowedIPs = x:x:x:x::/64 # OpenWrt lan subnet
AllowedIPs = x:x:x:x::x/128 # Subnet of wireguard interfaces

regarding the allowed ips I like to have one subnet where only the wireguard interfaces live with there ips but furthermore route all requests from the server to the subnet of the OpenWrt router through the wireguard connection

All ips I am referring to are ULA addresses. The isp is only involved in the connectivity between OpenWrt and server over the internet and wireguard handshakes is working fine.
To add the specific interfaces to the dnsmasq config sure is an option. The only reason I have not done that at the moment is that I do use other subnets / interfaces for lan and guest at the router and I would need to check all options if they still work or I messed something up.

The posted configs look normal and seem to be working, so there's nothing to fix.
You should post the configs for the desired setup which you have problems with.

In addition, check out the documentation for WG IPv6 site-to-site setup:

the Router config looks like the following. Server config not changed

# /etc/config/network
config interface 'wg0'             
        option proto 'wireguard'        
        option private_key 'xxx'
        option listen_port 'xxx'                                                                      
        list addresses 'x:x:x:x::x/128'

# /etc/config/network
config dnsmasq
        option localservice '1'

With this one tcpdump shows traffic on the routers wiregurd interfaces from the server targeting port 53 which will not be answered by OpenWrts dns server. (I just changed the subnet at the wiregurd interface)

Okay, a subnet can be /64, /56, /48.

/128 is not a subnet.
You cannot use /128 for a subnet.
Replace /128 with a proper subnet mask.


Ahhhh, got it!
in fact /128 of cause is nothing to call a subnet. Sorry for wrong wording.

But anyway with what ever I prefix the ip address at this point in the config transfers to the prefix the interface will get when it comes up.

/# ip a s wg0
702: metrics: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet6 x:x:x:x::x/128 scope global 
       valid_lft forever preferred_lft forever

And from what I understand this is the "subnet" the OpenWrt documentation refers to?

localservice` boolean `1` `--local-service` Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server.

Therefore my question what implications the prefix thing at the and of the ip address has or if there is another more reasonable way of querying on OpenWrt dns over a vpn tunnel.

1 Like

Here is how I've got my wireguard setup:

config interface 'wg0'
	option proto 'wireguard'
	option listen_port '4111'
	option private_key 'key'
	list addresses ''
	list addresses 'fd43::1/64'
	option mtu '1412'
	option delegate '0'

Like vgaetera said, specify a subnet above (look at CIDR and how it designates the subnet/network and host part of the IP addresses).

config wireguard_wg0
	option public_key 'key'
	option description 'description'
	option preshared_key 'key'
	list allowed_ips ''
	list allowed_ips 'fd43::2/128'

Here, specify your endpoint IP addresses (/128 is one single IPv6 address, likewise /32 for IPv4). You can also add an entire subnet here if you want it routed over a wireguard tunnel as well (site-to-site VPN). Example:

	list allowed_ips ''
	list allowed_ips 'fd43::/64'

The interface as seen from ip addr:

17: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1412 qdisc noqueue state UNKNOWN group default qlen 1000
    inet brd scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fd43::1/64 scope global 
       valid_lft forever preferred_lft forever

I've allowed wg0 to send DNS queries to dnsmasq. The wireguard clients/endpoints also have both fd43::1 and set as a DNS server address. That allows the basics to work, Wireguard clients can ping both addresses, and DNS queries respond back.

If you can connect to wireguard and talk with your router, getting DNS queries running over the tunnel is the easy part.


All Right
Sounds good to me. Looks like the subnet configuration was the only issue here and in fact I had the wrong idea of how it is suposed to work. Thanks @ergamus for that example. Makes sense to me. And indeed this configuration works for me as well.

So Thanks for discussing this we me.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.