View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000384||AlmaLinux-9||-OTHER||public||2023-04-14 13:41||2023-04-25 19:04|
|Summary||0000384: wireguard fails to start due to DNS failure when Endpoint is FQDN|
|Description||AL9.1 minimal installed on a VirtualBox VM, with a few extra packages. All updates installed.|
When the wireguard config file Endpoint is a FQDN, starting wireguard fails with a line like this in /var/log/messages :
> Apr 15 01:09:01 al9-01a wg-quick: Name or service not known: `<FQDN>:51820'
When config FQDN is replaced by the endpoint's IP address then startup succeeds.
The FQDN resolves on the command line.
When FQDN is used, wireshark shows that no DNS query is generated.
FQDN startup fails with initial AL9.1 kernel version, and the latest 9.1 kernel.
wireguard-tools version is the same as for AL9.0
Problem first detected on an AL9.1 VM that's been used for development purposes.
Same behaviour on the initial install VM that it was cloned from.
With an AL9.0 VM and the same wireguard config, with Endpoint = <FQDN>, startup succeeds.
As expected, wireshark shows that a DNS query is generated.
Succeeds with both the initial AL9.0 kernel version and the last 9.0 kernel
|Steps To Reproduce||As detailed above.|
|Additional Information||Also no problem with wireguard FQDN on an AL8 VM.|
Nothing relevant found on the RHEL bug tracker.
Don't have access to RHEL.
|Tags||No tags attached.|
Just curious. The AL8 kernel does not have in-kernel module for wireguard. What did you use to enable it?
he cause appears to be the following SELinux:Enforcing denials for /usr/bin/wg
getattr & read for /etc/resolv.conf
read for /etc/hosts
create for tclass=udp_socket
After doing setenforce 0 the startuo succeeds, and doing setenforce 1 once it's running doesn't affect it.
Don't have access to RHEL, but Rocky Linux 9.1 has the same problem
Cause is obvious with an RL9.1 desktop. Not obvious with AL9.1 minimal.
Regarding the above question from toracat, for EL8 the EPEL 8 repo has the necessary packages, but watch out for delays in its update appearing following a kernel upgrade.
> Regarding the above question from toracat, for EL8 the EPEL 8 repo has the necessary packages
Did you actually mean ELRepo, not EPEL?