Topics

Looking at 20-openvpn there it looks like two variables are expected, where the 2nd one is either MASTER or BACKUP, presumably passed to each script in this directory just when carp switches status. The first variable gets read as "subsystem," presumably something about the identity of what triggered the carp status change. I also see
https://docs.opnsense.org/development/backend/autorun.html as reference.

Several questions then:

What are the possible (sane) subsystems for this context? Are there known problem cases to beware of here in the context of taking action, or is it generally safe to ignore this value beyond perhaps logging it?

Are scripts in carp run on initial system startup, just if the system starts up as MASTER?

Thanks!

This is a new thread based on "OpenVPN from Linux client -- also server fails to start with tun1 error".

In summary, WireGuard starts tunnels using tun devices, renaming them to wg0, wg1 ... wgN. OpenVPN also uses tun devices. In a system with existing wg0, wg1 and wg2 devices, the OpenVPN server startup currently tries to use tun1, which is not available, as already in use as wg1. So OpenVPN simply fails.

Presumably this would not result if only a single wgN device were running based on a renamed tun0, and it's doable in WireGuard to have multiple tunnels based on a single wgN device. But the current OPNsense setup requires each remote endpoint have its own tunN (wgN) device on OPNsense, so that's not a viable workaround when multiple WireGuard tunnels are required.

It's possible that starting OpenVPN before WireGuard would avoid this. Haven't tested that. The system where this has become evident is in production, and the WireGuard tunnels are of higher value to us than OpenVPN access. In any case, the current setup is clearly a bug in the OpenVPN startup, which should be smart enough, on failing to use tun1, to increment N until tunN is found available to it.

[Ah I see now]

I'm getting this in Ubuntu Linux, after starting the openvpn client from a shell:

Password entry required for 'Enter Auth Username:' (PID 12642).
Please enter password with the systemd-tty-ask-password-agent tool!

What seems wrong is that happens even after I've changed OPNsense's OpenVPN server config to be Remote Access (SSL/TLS) -- without "+ User Auth". So why is it asking for user auth? I've got the certificates installed, and the paths added to the .ovpn file so they're found. I'm starting the client with:

/usr/sbin/openvpn --config /etc/openvpn/openvpn_myid.ovpn

which is quite standard and how I start the client for other OpenVPN servers I run.

I'll grant that systemd is an atrocity, and I've no immediate interest in figuring out how to get the systemd-tty-ask-password-agent tool to work. Why is the OPNsense OpenVPN server asking for user auth though? How do I have it merely accept the certificate? The client log was presenting this as:

Fri Sep 20 15:12:13 2019 ERROR: could not read Auth username from stdin
Fri Sep 20 15:12:13 2019 Exiting due to fatal error

Now, I at first had had "+ User Auth" in the setup. Do I need to take extra action to bounce the OPNsense OpenVPN server process?

Ah I see now, the user config file has a line: auth-user-pass. I was assuming authorization method was controlled solely from the server.

A more serious problem: when I do a "ps aux" or "top" on the server, I don't see any openvpn process. And in /var/log/openvpn.log I see:
Sep 20 15:12:53 OPNsenseFL1 openvpn[44056]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
Sep 20 15:12:53 OPNsenseFL1 openvpn[44056]: Exiting due to fatal error

follows by many repeats of ^@^@ etc. Not good. An ifconfig shows no device tun1 (or any tun at all -- usually this would start from tun0). So what's with OPNsense that it can't work tun1 here?

root@OPNsenseFL1:/var/log # ifconfig tun0
ifconfig: interface tun0 does not exist
root@OPNsenseFL1:/var/log # ifconfig tun1
ifconfig: interface tun1 does not exist

This is OPNsense as installed on Deciso appliances. How do I add the tun devices that should be there? This isn't how:

oot@OPNsenseFL1:/var/log # ifconfig tun0 create
ifconfig: SIOCIFCREATE2: File exists
root@OPNsenseFL1:/var/log # ifconfig tun1 create
ifconfig: SIOCIFCREATE2: File exists
root@OPNsenseFL1:/var/log # ifconfig tun0
ifconfig: interface tun0 does not exist
root@OPNsenseFL1:/var/log # ifconfig tun1
ifconfig: interface tun1 does not exist


Thanks,
Whit

What is the most correct way to add arbitrary commands to start or stop services, or execute other actions, when there are CARP status changes? I'm used to doing this in Linux using UCARP, so have the general hang of it. But I'm unacquainted with how BSD, and particularly OPNsense, are set up for this. I'm especially interested in doing it so as to coordinate with, but not get clobbered by, configuration actions taken through the OPNsense web UI. There's likely to be a clean and proper way to do this. Has anyone explored it?

This is both in Firefox and Chrome. There should be a button there for the export to function, shouldn't there?

Thanks,
Whit

After success with two tunnels, trying to add a third, but while ifconfig shows wg0 and wg1, there's no wg2 as there should be now. Is this a limitation in the current implementation here, or have I missed something?

Is there a way to tie WireGuard to CARP takeover? Obviously I can't just have it already running on both systems, with the same remote connections. On the DR system, once running it should connect to the remote systems at their IPs even if it's not coming from the expected IP on the OPNsense end; that's a feature of WireGuard. I'm guessing this will take scripting tie it to CARP, so that it only starts when CARP triggers it. If so, where should that be tied in?

Apologies if this is documented somewhere I haven't found yet. Thanks for any pointers.

Whit

I'm at this point because I'm blocked from accessing via the public IP because adding two other IPs to the WAN interface cut that off from being connected to by HTTPS or ping. And my way in now is via a WireGuard tunnel, which in turn I'm trying to access through an xinetd port forwarder set up on the other end of that tunnel. The system on the other end is a remote Linux server without a GUI desktop.

From that system directly I can do w3m and get the login screen on the OPNsense box. But from my desktop remote to that, when I go to the xinetd port forwarding set up there, I get:

The HTTP_REFERER "https://172.17.10.1:444/" does not match the predefined settings. You can disable this check if needed under System: Settings: Administration.

What? I never predefined any setting for this. I've not enabled ssh access. How do I get control back here?

I just added two IPs to a WAN interface, beyond its primary one. When I pressed the button to apply them, the interface got cut off. It can't be pinged on any of the three addresses. And I lost the remote web access to it.

Is this a known thing?

Fortunately I have a WireGuard tunnel to the device which has stayed connected, so I should be able to get to it through that -- although it's from another remote location, so first I need to set up a relaying system there. But what am I looking for here, in terms of what's gone wrong and why?

Unbound is not good for us because it's failing to return listings for one of the domains we run the authoritative servers for. Each of those servers returns those listings fine. Google's 8.8.8.8 and 8.8.4.4 do too. But Unbound fails without even providing an excuse.

Found that the problem is "rebind" protection. Yes, we have a public domain we use for some private IPs, for diverse VPN connections. With DNSmasq, that requires adding "rebind-domain-ok=/that.domain/" in the Advanced box, which we now hope is not going away in the future, despite the notice. Is there a similar way to configure Unbound?

After setting up Wireguard between a new OPNsense appliance and a Linux server that's rock-solid with Wireguard connections to other Linux devices, it only intermittently works. Strangely, it will work to allow connections from the Linux end both to the Wireguard IP on the OPNsense box, and to the LAN behind it, but only for a while. After it fails for both, if I then go to the VPN:Wireguard > Endpoints page and simply press "Save" it starts working again. But after a few minutes it sometimes fails. The "List Configuration" tab however shows it as active nonetheless. Sometimes it does seem to recover on its own.

I've not seen the like between Linux Wireguard machines flake in this way. Both ends are on public IPs, and configured explicitly with those IPs.