Messages

Seems fixed by restarting a couple of times.

Hi! I just upgraded to 25.1.1 but found that openVPN no longer works. Service exit with the following errors:

Code Select Expand

2025-02-12T14:25:55-06:00 Notice openvpn_client1 Exiting due to fatal error
2025-02-12T14:25:55-06:00 Error openvpn_client1 Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
2025-02-12T14:25:55-06:00 Notice openvpn_client1 TUN/TAP device ovpnc1 exists previously, keep at program end
2025-02-12T14:25:55-06:00 Error openvpn_client1 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:9: block-outside-dns (2.6.13)
2025-02-12T14:25:53-06:00 Notice openvpn_client1 [123.net] Peer Connection Initiated with [AF_INET]1.51.25.36:1194
2025-02-12T14:25:53-06:00 Warning openvpn_client1 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
I'm using "Clients (legacy)" under OpenVPN, Most of the error/warning existed prior to 25.1.1, the only new and fatal error is

Code Select Expand

openvpn_client1 Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16)
I was upgraded from 25.1 and OpenVPN worked well before the upgrade. Besides OpenVPN, Tailscale, Wireguard, and IPsec(VTI) tunnels are also running on the same server.

CrowdSec had problems with Appsec enabled since 24.7.12
Can workaround by reverting or removing appsec collections. But I didn't find a solution to fix the root cause.

Confirm the fix works.

Had the same problem here. The new version of Crowdsec seems to have problems with appsec function. Fix by logging in to the console then revert to the last version.
opnsense-revert -r 24.7.11 crowdsec
Then fix the tainted collections with the following commands:
cscli collections upgrade --force crowdsecurity/appsec-generic-rules
cscli collections upgrade --force crowdsecurity/appsec-virtual-patching

Ok, I guess I won't get any answer regarding the CNAMEs. So indeed seems like you will have 20+ entries in DynDNS. Or switch the backend to non-native.

Sorry.. I forgot about CNAME
but seems CNAME will cause more trouble for me, all those sub-domains are different sites, may cause problems with TLS and the ingress controller.

Cloudflare should fix their sh*t. Other than that, if CNAME is impossible, create 3 separate entries in DynDNS, this apparently doesn't work properly with multiple hostnames.

yep..I guess each config entry for each hostname is the only way to go for now, however, I have 10+ sub-domains, and I need to update both ipv4 and ipv6 :'(

although, if I choose "ddclient" as the backend instead of "native", then it can work as expected with the same configuration.
In the logs, it will process all hostnames one by one.
So, I think this also could be a bug with the "native" backend

I'm on OPNsense 24.7.1 and I have os-ddclient 1.23 installed.  I only have two hostnames that I'm checking with dd-client.

according to the Opnsense docs, ddclient as "backend" means the old original ddclient, and "native" means new ddclient rewritten by the Opnsense team.
Just like you, I don't have this issue with the old ddclient, only with the new or "native" one :'(

However, once the service runs, instead of updating the IP for 3 records, it will create a single recode like this:
aaa.example.com,bbb.example.com,ccc.example.com       1.2.3.4

Where? On Cloudflare? It's not even a valid hostname... Sounds like they are missing any validation whatsoever. Also, they cannot do CNAMEs so that you are updating one record instead of 3 -- or what's the grand idea here?

Thanks for your reply!

Yes, on the Cloudflare DNS settings. For example, there are 3 of A records on cf, and none of them are CNAME:
aaa.example.com       1.2.3.4       A
bbb.example.com       1.2.3.4       A
ccc.example.com        1.2.3.4       A

once my configuration runs, the "aaa.example.com" will be replaced by "aaa.example.com,bbb.example.com,ccc.example.com", the other two remain untouched, resulting in this:
aaa.example.com,bbb.example.com,ccc.example.com       4.3.2.1       A
bbb.example.com       1.2.3.4       A
ccc.example.com        1.2.3.4       A

I lost access to the aaa.example.com so I found this issue :o

Never mind the JSON strings, mine looks the same with multiple hostnames.  Yeah, I'm using ddclient also with cloudflare and mine are working fine.  I have multiple hostnames as well and it looks like yours.

Thanks for reply!
are you also using old ddclient as backend or native?

I am testing the ddclient plugin and found some unexpected behavior.

In my ddclient.json:
```
{
    "general": {
        "enabled": false,
        "verbose": false,
        "allowipv6": true,
        "daemon_delay": 300
    },
    "accounts": [
        {
            "id": "d9b8ec22-97b7-82e7-b133-971a4dcf3a7f",
            "service": "cloudflare",
            "protocol": "",
            "server": "",
            "resourceId": "",
            "username": '123@321.com",
            "password": "123456",
            "hostnames": "aaa.example.com,bbb.example.com,ccc.example.com",
            "wildcard": false,
            "zone": "example.com",
            "checkip": "web_ipify-ipv4",
            "interface": "hn0",
            "checkip_timeout": 10,
            "force_ssl": true,
            "ttl": "300",
            "description": "example.com cf"
        }
    ]
}
```

However, once the service runs, instead of updating the IP for 3 records, it will create a single recode like this:
aaa.example.com,bbb.example.com,ccc.example.com       1.2.3.4

If I switch the backend to the old ddclient, then it will process multiple hostnames properly but also makes ipv6 not work.
I assume the option "hostnames" means it can support multiple hostnames? so, how to properly set that?
Or, I have to set multiple configs for each hostname?

Thanks in advance!