Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Casstg :


    That would be great! Thanks for your support.

    What is the port you are running your wireguard on. I assume sume <= 32767. I used the 51820 because it is the standard port. But I have no problems in changing it, if this would solve the problem.

    I tested all other containers, one by one, an now other is reachable.


    Again, many thanks!!

    Nope


    Im running on the standard port, Test by changing the firewall rule to go upto 51821for that .19 network only and restart UFW or change the listening port to one unused in the existing range covered by the firewall rule already


    And obviously dont forget to add a forwarding rule to UFW to the docker thats hosting wireguard

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!

    Edited 2 times, last by Casstg ().

    When you are running on the standard port, why is is working on your side and not working on mine...?


    What do you mean with that?

    "And obviously dont forget to add a forwarding rule to UFW to the docker thats hosting wireguard".


    That`s not described in this ufw-docker documentation, is it? Or did is missed that?

    Hi


    Firstly UDP ports responds different to TCP in port scans i.e they shouldn't respond. Wireguard on a UDP Port wont start a connection unless the correct keys are issued, so there is no issue with this port bypassing UFW for a start. Its a non issue.


    I have not really tested my setup for the reason above as i am not concerned so if i implied otherwise than apologies for that


    Now onto your last question:


    If you are that concerned on the port my advise still stands:


    Change

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.19.0.0/12

    To

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:51821 -d 172.19.0.0/12

    Or change your Wireguard port to one covered by the existing firewall port range i.e below 32767



    It does not mention it in the guide at all because there is no real need for it, and i am only guessing that the mods abovel block access until you add a forward firewall rule


    Also i think you mentioned you run UFW in a docker? I run it at OS level as why wouldnt you, so our setups are different and cannot be directly compared,

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!

    Thanks

    No , my ufw runs on OS Level. I only use the tool ufw docker to solve the problems between ufw and docker.

    Understand

    Change

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.19.0.0/12

    To

    Code

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:51821 -d 172.19.0.0/12

    Or change your Wireguard port to one covered by the existing firewall port range i.e below 32767


    What I do not understand or what confuses me is what you mean with "And obviously dont forget to add a forwarding rule to UFW to the docker thats hosting wireguard"

    If you achieve what you want to achieve i.e stop docker bypassing the firewall, then like all the other dockers and as written in the github guide you have to add a forwarding / routing rule otherwise how will your vpn ever connect?


    I.e amended from the github repo


    Code
    ufw route allow proto udp from any to 172.19.0.2 port 51820

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!

    Edited once, last by Casstg ().

    See I found 2 possible things, which could have caused the problem:


    My initial configuration was:


    172.16.0.0/12 is the IP range from 172.16.0.0 till 172.31.255.255. So all my internal subnets are included. I was only seeing this 172.16.0.0/12 when executing "iptables -L --line-numbers".

    Think this was mistake 1.


    I changed it to "/16" subnets and for the Wireguard subnet also the port range:


    Now it works as expected. Without a firewall rules, no connection possbile. May be changing the subnets to "/16" might be enough, because I did not change any port ranges on the old system. But it seems to work with the port range change, too. So I will go ahead with this and will check carefully the next days again.


    To all firewall professionals in the forum: Do you think this "/12" - "/16" subnet mistake could have caused the problem?