Messages

I already tried to deal with dns leaks. But at that time I wanted to redirect all my dns requests to wireguard gateway.
However I use now unbound and would like to know how to redirect all the dns traffic from unbound to the wireguard gateway in order to prevent dns leak.
But maybe this is not the right way to proceed ?

If you modify the rule in Step 8 to tunnel DNS traffic via wireguard, that should work.

However, I get the feeling that what you're trying to do is something entirely different. Can you please explain what exactly you're trying to achieve? I get the feeling that whatever you're trying to do could be achieved much easier (e.g. let unbound talk to a trusted DNS via DNS-over-TLS).

If you want to send any local DNS request to a local Unbound through wireguard to an upstream DNS, the easiest way is to use the documentation for wireguard selective routing (https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html) and modify it to only tunnel DNS traffic from any firewall IP to the upstream DNS IPs.

Are you referring to the section "Dealing with DNS Leaks"? If so, which of the 5 points/solutions would you recommend?

Tia.

No, I'm referring to the documentation as a whole. The only difference is that in Step 8 you only tunnel requests by unbound to UDP/53.

If you want to send any local DNS request to a local Unbound through wireguard to an upstream DNS, the easiest way is to use the documentation for wireguard selective routing (https://docs.opnsense.org/manual/how-tos/wireguard-selective-routing.html) and modify it to only tunnel DNS traffic from any firewall IP to the upstream DNS IPs.

Dear all,

we run two different captive portals on a single OPNsense 24.7.11_2 machine which are meant to retire two pfSense CPs. The CPs themselves run as expected, however, in RADIUS Access-Request packets, the NAS-IP-Address is the same for both CPs (the WAN address in our case). Is this the default behaviour? On pfSense, the router's IP address in each CP network was used as NAS-IP-Address. This matters in so far as we use different authorisation and authentication schemes for the different CPs and used NAS-IP-Address as the distinguishing attribute. Is this a bug? Or is there any way to properly set the NAS-IP-Address attribute for different CPs?

I love the DCO feature, it gives our users close to wire speed performance. It's rather strange, we have weeks of stable operations with hundreds of simultaneous users. But we're on to something. I'll let you know as soon as we found a reliable way to reproduce the issue.

I think that we found a way to maybe reproduce it. But we're still investigating. Does it make sense to open a new issue on github and supply information? Or is there already an open issue that we should refer to?

Correct. The process dies and there's a message "DCO interface closing".

BTW: I think I found a message in the logs which occurs right before the OpenVPN process crashes:

Code Select Expand

Failed to set key: No such file or directory (errno=2)

Yes, I'm using the new instances. I'll send feedback ASAP.

I can't reproduce the failure of the OpenVPN process but if it happens again, I'll give it a try. Thanks for the hint. I'll give feedback as soon as it happened again.

Quick question regarding the ID for restarting the process: it's the one that looks like a long hex UUID, right?

Hi Franco,

if

# /usr/local/sbin/pluginctl -s openvpn restart YOURIDHERE

is the same as restarting the OpenVPN service from the UI, it indeed doesn't work. The logs say that it can't be restarted because the device ovpns2 already exists. Thats the reason why we do an "ifconfig ovpns2 destroy" first. However, we're completely unsure what's actually going wrong. No logs indicate what the trouble is. The process basically dies without letting us know what's wrong.

Dear all,

I have some inexplicable occasional crashes of the OpenVPN service. Unfortunately it can't simply be reloaded via the web UI because the tunnel device is already existing (ovpnsX). I'm checking the process via Monit which works fine. I want to use a small shell script to remove the interface and restart the service:

Code Select Expand

#!/bin/sh
/sbin/ifconfig ovpns2 destroy
/usr/local/sbin/pluginctl -s openvpn start 2

However, it looks to me like the last command doesn't do anything. My question is: what's the correct command to stop / start an OpenVPN process?

Yes: Do it differently.  ;)

Joking aside, there're good reasons to not use "client-connect" scripts for OpenVPN. For one, OpenVPN is single-threaded and using a client-connect script will freeze traffic for all (!) connected clients until the script returns / terminates. The impact is low for up to 10 clients but for more clients the impact is 100% notable and gets really annoying for more than that, especially if the script runs for ~1s or more. Clients experience packet losses / interrupted streams etc..

A good approach that doesn't involve putting stuff on the OPNsense box itself is using the API: https://docs.opnsense.org/development/api/core/openvpn.html you can get all the information you need from the API and it's reasonably quick. I use the core/openvpn endpoint for a similar scenario and it works like a charme.

That's interesting. Is this a NAT issue by any chance so that a packet coming from a VPN client is not NAT'ed by the firewall (and in turn this would cause packets not being able to return to the client)?

EDIT: Can you post the firewall rules showing that all traffic going out to the internet is directed to the WANGWGROUP (or whatever name you gave it)? Maybe the VPN client network is missing?

I'm not a multi-WAN expert but I think it's unlikely that this is the issue if the routing itself is working for your local network because redirecting the gateway should simply tell the clients to tunnel everything to the gateway and the routing table on the gateway itself decides what to do with the packets. Have you checked the box's firewall logs to find out whether VPN traffic to the outside world is discarded? If the gateways are properly redirected, the firewall may be the culprit.