Bug 14030

Summary: DNS resolution via OpenVPN or Wireguard not possibe
Product: IPFire Reporter: Joern Koerner <joern.koerner>
Component: ---Assignee: Michael Tremer <michael.tremer>
Status: ASSIGNED --- QA Contact:
Severity: Major Usability    
Priority: Will affect most users CC: adolf.belka, carlos.e, michael.tremer, Reinoso, tg92, timo.eissler
Version: 2   
Hardware: unspecified   
OS: Unspecified   

Description Joern Koerner 2026-07-28 10:49:19 UTC 
Since the introduction of Knot as DNS resolver with Core 203, OpenVPN or WireGuard users can no longer resolve names via IPFire’s DNS. For clients that have joined the IPFire network via a VPN connection, every DNS query results in a timeout.

The Knot documentation states:

"On machines with multiple IP addresses, avoid listening on wildcards like 0.0.0.0 or ::. If a client can be reached through multiple addresses, UDP responses from a wildcard address might use the wrong source address—most well-behaved clients will then reject such a response."

https://www.knot-resolver.cz/documentation/latest/gettingstarted-config.html#id1



A temporary solution is to add the IP addresses of the network zones to the file “/etc/knot-resolver/config.yaml”.


"
network:
  listen:
    - interface: 0.0.0.0@53
    - interface: 192.168.1.1@53
"

It should also be possible to enter the zone names (green0, blue0, orange0, ect) there, but doing so causes knot to crash. See Bug 14024, https://bugzilla.ipfire.org/show_bug.cgi?id=14024
Comment 1 Michael Tremer 2026-07-29 07:35:20 UTC 
Hello Jörn,

I can acknowledge this problem and I have been working on fixing this problem in Knot Resolver. A PoC patch is available and has already been tested successfully internally.

I have submitted it to the Knot Resolver developers and am awaiting whether this has a chance of being merged as many more people are experiencing the same problem:

> https://gitlab.nic.cz/knot/knot-resolver/-/work_items/173#note_335164
Comment 2 R R 2026-08-05 12:04:08 UTC 
Hi!

Do you thunk the patch will also help with the problem using Keepalived virtual IP address?

My setup consists of two IPFire systems:
    Primary IPFire: 192.168.222.251
    Secondary IPFire: 192.168.222.252
    Keepalived virtual IP: 192.168.222.254

The virtual IP is used as both the default gateway and the primary DNS server for clients on the GREEN network.

The virtual IP is present correctly on the active node:
inet 192.168.222.251/24 scope global green0
inet 192.168.222.254/32 scope global proto keepalived green0

Knot Resolver is listening on:
0.0.0.0:53

The generated configuration contains:
network:
  listen:
    - interface: 0.0.0.0@53

When a client sends a DNS query to the virtual address, the reply is sent from the physical address of the active IPFire system:

nslookup google.com 192.168.222.254

reply from unexpected source: 192.168.222.251#53,
expected 192.168.222.254#53
Comment 3 Michael Tremer 2026-08-05 12:33:02 UTC 
Hello,

yes, this is exactly what this patch is supposed to fix.

Sadly I have not heard back from upstream yet and therefore cannot finish working on the patch.
Comment 4 R R 2026-08-07 08:25:22 UTC 
If you do not get a response from upstream, the https://gitlab.nic.cz/knot/knot-resolver/-/blob/master/CONTRIBUTING.md mentions the following options:

1. File issues and merge requests directly against the upstream repository:
   https://gitlab.nic.cz/knot/knot-resolver

2. Open a pull request on GitHub:
   https://github.com/CZ-NIC/knot-resolver
   They will take care of it and move it upstream.

3. Send a patch to the users mailing list:
   knot-resolver-users@lists.nic.cz