Posts by Casstg

  • Oster-Aktion 2025

    Just grabbed another deal, is there a backlog of order processing or will they be delivered from tomorrow, sitting here patiently waiting to set up lol I may just go eat some more chocolate until its added to my account lol

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    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,

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Okay, so your config looks OKISH except possibly one thing. Now im no UFW expert at all but the only thing that stands out is the following:

    Quote


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

    Now i could be wrong, but if i am right the answer is staring us in the face. Again im not an expert on UFW so others feel free to call me an idiot but if im understanding that line correctly it is applying to anything going to the docker network 172.19.0.0/12. However if i am reading it right it is only applying that rule to:

    Code
    --dport 0:32767

    However Wireguard runs on:

    Code
        ports:
      - 51820:51820/udp

    Therefore if my assumption is correct that UDP port is not blocked by that rule

    I would have a backup and do a test to see if that is an issue by changing 32767 to 51821

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Quote from Interessent

    Thats my config:

    Okay without seeing all of your config files can you answer the following:

    • Why are you running so many different docker networks? If its for additional isolation then so be it fair enough but you are making life a bit more difficult for yourself
    • Did you update your UFW file to add in another additional network as on the original example i gave you the following subnet was not mentioned -172.19.0.0/16.
    • If not then you need to update that file to include the additional lines to include this network as well, then you need to forward the UDP port to the docker container as per the original guide.

    I always have one bridge network all behind a proxy which is simple to manager without issue.

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Without seeing your docker config for wireguard it is hard to diagnose, but i run Wireguard with wireguard UI docker in the same setup as i previously posted and i have to publish the forward ports for the UDP. However i could be wrong but reading up i would not be overly concerned as it is a UDP port and unless someone gets hold of the wireguard keys theres nothing they could do anyway as the docker wont respond unless the keys are correct and UDP doesent respond in the same way as TCP ports for probing, again could be wrong but thats what i understood when reading up many moons ago

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Quote from Interessent

    Casstg

    Thanks for your input. Makes sense, try that later today.

    I maybe wrong but there was no instruction on the GitHub page to modify these entries.

    I agree it does not mention anything about modifying , but i noted his use of 192.168 being a home network default so i just amended it as that line is pointless on most cloud setups, so i always changed it to my custom docker network, may make no difference but worth a try

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Hiya

    You appear to have copied the github contents verbatim and have not amended them, not sure if it makes a difference but i always ammend my to also include my custom docker networks

    From your quote you have:

    And especially these lines:

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

    Now i could be wrong however anything out side of those docker networks will still bypass UFW.

    Looking at your firewall rules

    Code
    [ 3] 172.18.0.2 51820/udp       ALLOW FWD   Anywhere                   # allow wireguard 51820/udp wireguard-server_default
[ 4] 172.17.0.3 9001/tcp        ALLOW FWD   Anywhere                   # allow portainer_agent 9001/tcp bridge

    You have containers on a 172.18 and 172.17 network, these are not declared in the docker UFW rules

    I never use the default network of 172.16 however i do leave that rule in, but i change the other example 192.168 to match my docker network as thats just an example.

    Change the line

    Code
    -A DOCKER-USER -j RETURN -s 192.168.0.0/16

    to

    Code
    -A DOCKER-USER -j RETURN -s 172.18.0.0/12

    And do the same for :

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16

    to

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.18.0.0/12
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.18.0.0/12

    Then duplicate each line for each network you have running on docker i.e your other 172.17.0.0/12

    And try that

    So it should look like this:

    It may not make a difference but its how i have mine setup on Debian 12 and none of my containers are visible but i also have them on one network behind a proxy

  • Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    I run docker / portainer / ufw on all my setups and do not face this issue.

    However, I use UFW on the root server and not in docker. I make the amendments listed in the github listed above (changing the IP's to match my custom docker network i.e 172.20.0.0/12 and then use forward rules to point to my proxy docker container (either Swag or NPM). However that works for my setup and not knowing how you have yours setup, wethere you have a proxy container etc it is hard to pin point the issue. As i am using a proxy i do not have to publish any ports publically for the containers so that also assists.

    My Setup

    • Debian 12 with UFW and Crowdsec installed
    • UFW ammended with the changes listed in Github Link
    • Custom Docker Network so all containers can talk to each other without issue (also assigndocker network Static IP's to each container)
    • NPM/SWAG as Proxy managing traffic to the correct containers
    • Apart from the proxy container no other containers have ports published
    • UFW Forward rules for Port 80/443 are sent to the Proxy container static ip only following the github guide

    That results in 2 forward rules for TCP traffic and then i have a SSH rule obviously as normal.

    I occasionally have published ports for portainer as i forget to remove it after initial setup however, NMAP scan only ever shows the 3 ports as being open as expected.

  • Docker auf RootServer

    Im not sure on the OP UFW setup but the first thing is do is lock down UFW so docker ports do not bypass the firwall. This is security 101 with regards to docker.

    Follow this guide below and amend the lines to match your docker network IP. i.e lets say you set a custom network on 172.20.0.0/12 then ammend any lines that say 192.168.x.x with this ip instead

    Lock down Docker Ports with UFW

    Now rather than open port 80 443 to the whole server, further down the guide they explain how to use forward rules to the docker chain.

    I Have servers with either SWAG or NPM so it works with either. so lets Say you have given a fixed docker IP of 172.20.0.100 to NPM, the forward rules would then be:

    Code
    ufw route allow proto tcp from any to 172.20.0.100 port 80
ufw route allow proto tcp from any to 172.20.0.100 port 443
ufw route allow proto tcp from any to 172.20.0.100 port 81

    This will now forward those ports directly to NPM and no where else on your server.

    Whatever ports you publish now will only be reachable if you add a forwad rule like above otherwise they gain no access

    Regarding Port 81, you only need this for initial setup, what you should do is set up a proxy host in NPM for NPM itself, add the SSL then access via the domain name. You can then remove the forward rule for 81.

    With regards to Wireguard, i use a Wireguard and Wireguard-UI Stack and this works perfectly. i can give you the docker run command to see how they link, but basically the UI container actually connects to the Wireguard docker and its UI ports are published there. You then add a proxy host in NPM for the webui so its secured and add another forward rule like below

    Lets say you have given the Wireguard Docker IP 172.20.0.50 and UDP port 51820, you would then publish a forward port as follows

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

    Obviously you can change"any" to a specific IP only if that suits.

    If you want to add an extra layer of security then throw all your WEBUI dockers that dont need to be accessed from anyone else behind Authelia Docker 2FA. That locks it down nice and tight but is a pain to setup for the first time, and is a lot easier to setup with the SWAG proxy container than NPM

  • Konfiguration Wireguard

    Wireguard can be a right pain, however i use two docker containers and it became a breeze and you can throw up instances really quickly. To be fair i run 4 dockers as i use NPM for SSL certs and proxying and 1 Authelia Docker to put the webui behind 2FA) however technically you can spin up the 2 dockers for Wireguard and Wireguard UI, do all your config in the ui (including downloading the connection files or scanning QR codes if mobile) and then just stop the wireguard UI docker until you need to add delete or make other changes. Doing it the latter way would take no time at all (up and running in less than 5 mins) and i can post the working docker run commands if any one is interested.

  • Question regarding ARM Traffic Management Discrepancy

    Hi

    Have several roots servers and a few ARM servers elsewhere, looking at your ARM servers i wanted to clarify the Actual Bandwith

    On the details page it states if the traffic averages 1000MBits/s in 24 hours then it will be temporarily reduced to 200Mbps

    However if you add the item to cart, the agreement becomes "if the traffic averages 200Mbits/s in 24 hours then it will be temporarily reduced to 200Mbps"

  • Backbone/Routing Probleme

    I was wondering if something was up, Backups are at a crawl going out of the server, and my speed test to the server is seeing a fraction of the normal speed with high ping times

    Code
    traceroute google.com
traceroute to google.com (142.250.186.142), 30 hops max, 60 byte packets
 1  202.61.xxx.x (202.61.xxx.x)  0.487 ms  0.459 ms  0.434 ms
 2  ae3-4019.bbr02.anx84.nue.de.anexia-it.net (144.208.211.10)  58.835 ms  58.819 ms  58.804 ms
 3  ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139)  62.090 ms  62.112 ms  62.097 ms
 4  ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141)  118.603 ms  118.584 ms  118.890 ms
 5  209.85.149.86 (209.85.149.86)  61.905 ms  61.981 ms  61.965 ms
 6  * * *
 7  fra24s07-in-f14.1e100.net (142.250.186.142)  62.330 ms 142.250.62.150 (142.250.62.150)  62.600 ms fra24s07-in-f14.1e100.net (142.250.186.142)  62.669 ms