Cu 203 knot-resolver openvpn not working

[urmelchen]

ovpn-clients connect successfully, but name resolution seems not to work.

[kuni (kuni bertus)]

Here the name resolution also not working for openvpn roadwarriors.

[binabik (Binabik CC)]

Hi,

I’m having the same problem here: the VPN connection works, but name resolution isn’t working for roadwarriors.

[kuni (kuni bertus)]

Ok, the same problem occurs with wireguard and i followed this post:

Core 203 and wireguard

I have the same problem. I worked around it by creating DNAT rules for WireGuard traffic (udp 53) from the WG side to the red IP. I also have Kubernetes, and it’s experiencing the same issue, so I created DNAT rules for the 10.0.0.0/8 network as well. in knot doc Configuration — Knot Resolver 6.4.1 documentation there is warning for using 0.0.0.0, so i have also tried to list all the interfaces and now it is working fine. network: listen: # - interface: 0.0.0.0@53 - interface: lo # 12…

and changed /etc/knot-resolver/config.yaml

# Listen on all interfaces
network:
  listen:
#    - interface: 0.0.0.0@53
    - interface: lo # 127.0.0.1
    - interface: green0
#    - interface: blue0 # no blue-if
    - interface: orange0
    - interface: red0

Restartet knot-resolver:

/etc/rc.d/init.d/knot-resolver restart

Check, if it’s running:

/etc/rc.d/init.d/knot-resolver status

And now it’s working again. Be careful with syntax. I’m not familiar with yaml, but i had a lot of trouble editing the config.yaml and knot-resolver not starting.

Also, I’m not sure, if this is a good idea. But as a workaround it seems to do the job.

[urmelchen]

thank you for your post kuni bertus. it is inspiring.
i can’t test it because i went back to cu202. i’m not good with linux but i would not dnat from tunnel to lo or green and i would not listen on red0 as long as it is not necessary. for me i would change config.yaml as follows because i internally use unencrypted dns:
network:
listen:

• interface: lo
  kind: dns
• interface: green0
  kind: dns
• interface: tun0
  kind: dns

for wireguard the interface name is probably wg0.

[kuni (kuni bertus)]

@urmelchen

but i would not dnat from tunnel to lo or green and i would not listen on red0 as long as it is not necessary

Yeah, this is crossed out in that posting, so dont do that.

@urmelchen

for wireguard the interface name is probably wg0

At first, i also thought, i had to put in the wg0- and tun0-interfaces in config.yaml. But this is not necessary. You only have to put in the green ip-adress (not the ipfire tunnel endpoint adress) in your VPN dns configuration and ipfire will do its job resolving domain names for all interface you want to. I had to check if this is true for orange network because originally ipfire is blocking dns/dhcp access from orange network. From security point it should be better to omit orange0 from listen-section in config.yaml.

[kuni (kuni bertus)]

@urmelchen

and i would not listen on red0 as long as it is not necessary.

Yes, i wasn’t sure if this is necessary because Core 203 config.yaml says 0.0.0.0@53 - so knot-resolver is listening on all interfaces i guess.

And: knot-resolver is doing a two-part job, dns-client for external name resolution and dns-resolver for the internal network. So i was unsure with red interface.

But perhaps you are right and i think: lo, green0 and blue0 (if used) should be enough, but i didn’t test it yet.

[kuni (kuni bertus)]

@kuni

I had to check if this is true for orange network because originally ipfire is blocking dns/dhcp access from orange network.

Ok checked that and you can safely omit orange0 from config. There is still a default fw block rule.

Edit:

@kuni

lo, green0 and blue0 (if used) should be enough

Ok, omited red0 too and all still seems to work.

Edit2:

Ok, i discovered one problem with that workaround/fix: If you do a reboot, ipfire will not fire up knot-resolver correctly and name resolution is not working at first. In service overview name resolution service stays off, although

/etc/rc.d/init.d/knot-resolver status

says it is up. You have to manually stop/start knot-resolver and it’s working again.

If i revert to 0.0.0.0@53 ipfire will boot up knot-resolver just fine, but name resolution via vpn is not working :x.

[d0cx1989 (d0cX)]

Core 203: Knot Resolver fails to answer DNS queries coming through WireGuard and OpenVPN tunnels (reply from unexpected source)

Hello everyone, After updating to Core 203 I ran into a DNS problem that also seems to affect other users with OpenVPN, so I want to document it properly here with the analysis and a working fix. Setup My Green network is 192.168.99.0/28 and the firewall itself is 192.168.99.1. Clients connecting over WireGuard use 192.168.99.1 as their DNS server. This worked perfectly before Core 203. Symptom After the update, name resolution over the tunnel stopped working. Resolving raw IP addresses was…

[urmelchen]

@kuni bertus
are you shure you formated config.yaml properly? I heard it does not like tabstops just blanks for the indents. the original file has 2 blanks per indent.

[kuni (kuni bertus)]

Yes, I learned this the hard way (i have to copy the code from above posting with blanks and then it works). If you use tab stops, knot-resolver always throws errors and never starts, regardless if you do a clean boot or start/stop/restart the service manually.

Actually, my workaround now is not using ipfire’s green ip-adress for vpn dns-configuration and put in the windows dns-servers as dns-resolver. Only my home network has ipfire as the only option for dns-resolving, so the problem here stays. But my network is very small, so I will use ip-adresses til this problem is fixed on official site.

[urmelchen]

same results here.
after changing interfaces in config.yaml and restart of knot-resolver dns through openvpn works, but when restarting ipfire knot-resolver fails to start.
i’ll stick with cu202 until the rebooting problem is solved.

[bonnietwin (Adolf Belka)]

For information @ms and I discussed this, after I had verified the effect with my android phone and the OpenVPN for Android app but interestingly enough my linux laptop with Network Manager was able to resolve everything with both wireguard and openvpn.

Unfortunately my testing with CU203 used my linux laptop when I did the vpn evaluations for ipsec, openvpn and wireguard and so I did not see this effect and it looks like no-one else involved in the Testing phase did either.

@ms has also been able to duplicate the effect and will look at how to patch knot so it will make sure the correct IP is used for the response.

Once a correctly working patch has been created/evaluated then it will also be submitted upstream.

[alexand (Alexander)]

When a VPN tunnel is set up to IPFire (remote access), both Wireguard and OpenVPN with the IP address of the Green network specified as the resolver work correctly, but it does not take into account the DNS firewall.

So it behaves just like IPFirewall itself when querying names. In my opinion, it’s correct. It would be a good idea to add the option to select remote access VPNs in the DNS firewall configuration.

[pscar13]

If you don’t select any network on this page, the DNS Firewall will also apply to OpenVPN clients.

If you select one or more networks (GREEN, BLUE, ORANGE), you must add the OpenVPN subnet to Custom source.

I haven’t tested this with WireGuard.

[kuni (kuni bertus)]

I want to summon my prerequisites for wg/ovpn dns resolving not working:

• split tunnel configuration
• ipfire’s green ip adress in vpn dns-configuration (no other dns resolver)
• dns firewall categories activated with NO interface selected

I’m not sure, if all are necessary prerequisites, but this is how it’s not working (and worked with unbound without problems).

@d0cx1989 states here, that the answer is coming from the red interface and so the client rejects the answer. Perhaps it helps finding the fault.

[pscar13]

Personally, I use a DNS redirection rule to the firewall, as described here, for each of my networks (GREEN, BLUE, OpenVPN):
https://www.ipfire.org/docs/configuration/firewall/rules/redirect-dns

(Adding TCP 853 to DNS services group for DoT)

After upgrading to CU203, I don’t have any DNS issues with OpenVPN.

Hope this helps.