the wireguard not listening on port after started

Solution 1:

I will assume that this is done on Linux, since not told otherwise and because of container context.

The description of lsof tells:

DESCRIPTION

Lsof revision 4.91 lists on its standard output file information about files opened by processes for the following UNIX dialects:

• Apple Darwin 9 and Mac OS X 10.[567]
• FreeBSD 8.[234], 9.0 and 1[012].0 for AMD64-based systems
• Linux 2.1.72 and above for x86-based systems
• Solaris 9, 10 and 11

On Linux, WireGuard is not a standard process, but a network driver handled by the kernel. Even if in the end this might create a kernel thread appearing in the process list, this "process" would be special and would not give any information available about its open file descriptors (if such concept makes any sense for a kernel thread anyway).

Thus lsof cannot find such information and will always return an empty result.

Yet a command like netstat -nul | grep -w 7456 or ss -nul sport = :7456 would still display it, where it was created (see later), because it's only querying kernel network APIs (resp. /proc/net/udp{,6} or netlink/sock_diag) to know about listening ports, rather than cross referencing informations from the kernel process API with thsoe from the network API.

That being said, this is only valid if the command wg-quick up wg0 was run in the specific container the interface is used in after. If it was run on the host, and after this the creation of a container "stole" it, all bets are off. That's because WireGuard is designed to work along network namespaces (ie containers). It's completely possible, and documented, to create the WireGuard interface in a network namespace (eg the initial host namespace), and move it to an other network namespace:

Ready for Containers

WireGuard sends and receives encrypted packets using the network namespace in which the WireGuard interface was originally created. This means that you can create the WireGuard interface in your main network namespace, which has access to the Internet, and then move it into a network namespace belonging to a Docker container as that container's only interface. This ensures that the only possible way that container is able to access the network is through a secure encrypted WireGuard tunnel.

That means if the interface is moved, the listening port will stay in the previous (probably initial host's) network namespace and will be invisible in the network namespace where the interface arrives. In such case the listening port 7456/UDP wouldn't be visible in the container, but would be on the host (or wherever it was initially created). Note also that WireGuard will listen (still only in the original network namespace) only if the interface is administratively up (ip link set wg0 up). Bringing it down removes temporarily the listening port.