Wireguard on UDP 51820 accessible without rule => Wrong

[nextcloudfan]

Hi,

I installed a wiregaurd docker container which is running on UDP 51820:51820. Without any rule with ufw-docker the container and the wiregaurd connection are available.

Thats not intended and my understanding is that ufw-docker blocks all docker traffic which has not been allowed. But in my case it doesn`t.

Please advice.

[ElectricityMachine]

Can confirm this on my install, running Docker Engine 20.10.12, Debian 11 Bullseye, + Portainer Happens to any container I have, making this script unfortunately useless

[FlamingFlowair]

Sme thing for me Debian 11 Bullseye, + Portainer started through docker-compose --> accessible by any computer on my network

[chaifeng]

We should choose UDP ports less than 32767 which are blocked and managed by the firewall. If we change the firewall rules that block more UDP ports, we may meet the issue of DNS resolving inside containers.

For UDP protocol, all accesses to ports which is less then 32767 are blocked. Why is this port? Since the UDP protocol is stateless, it is not possible to block the handshake signal that initiates the connection request as TCP does. For GNU/Linux we can find the local port range in the file /proc/sys/net/ipv4/ip_local_port_range. The default range is 32768 60999. When accessing a UDP protocol service from a running container, the local port will be randomly selected one from the port range, and the server will return the data to this random port. Therefore, we can assume that the listening port of the UDP protocol inside all containers are less then 32768. This is the reason that we don't want public networks to access the UDP ports that less then 32768.

[FlamingFlowair]

After investigation some more and taking time to better understand, the bug I encountered is not a bug but a feature.

The rules installed by this tools allow connections from the local networks 192.168.x.x which is not something I want.

I simply removed the lines corresponding to this network from the script, reran it and it's working fine now. I did not try to add the allow rule for the one service I want to expose. I will try this later.