Messages

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.

Yes, that seems to be the case. You can't select an interface but only add an IP. As a workaround you can leave this empty and have it bind to all interfaces and set up firewall rules that only allow access via WAN. I'm not sure what the design decision is behind not being able to select an interface but I suspect it has something to do with dynamic IPs on interfaces (e. g. if there's no fixed WAN IP).

There's no way to set this option in a server instance and I also wouldn't recommend it. Can you share what you're trying to do with the script? Maybe there's an easy workaround.

From what I can tell, you can't set this. That being said, you can retrieve all of the data contained in the logs via the OPNsense API: https://docs.opnsense.org/development/api/core/openvpn.html
The API is very easy to use and can be accessed securely with a user that only has privileges to read the openvpn API. Can you let us know what data you need to access?