Service listening, no rules added

[Yamakasi]

Hi,

I encountered a problem that my rules are not added on a latest and updated Ubuntu 21.04 install.

The service is listening but and waiting but nothing added.

Any idea ?

Thanks!

[shinebayar-g]

Hi, do you have any logs? If you're unsure run the binary in a current shell to debug further. Something like

wget https://github.com/shinebayar-g/ufw-docker-automated/releases/download/v0.7.0/ufw-docker-automated
chmod +x ufw-docker-automated
./ufw-docker-automated

Also do containers have at least UFW_MANAGED=TRUE label and published ports?

[Yamakasi]

Thanks for the quick reply!

This happens when I start a container:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x68 pc=0x7b849c]

goroutine 10 [running]:
main.handleUfwRule(0xc000074600)
        /home/runner/work/ufw-docker-automated/ufw-docker-automated/main.go:49 +0x13c
created by main.main
        /home/runner/work/ufw-docker-automated/ufw-docker-automated/main.go:245 +0xb4

[shinebayar-g]

I see. That's definitely a program error. Could you let me know the reproducible steps? I'll try to to reproduce the error on my computer.

1. How do you run the container? Full docker run .. command or compose file. (remove sensitive information)
2. Docker version docker version, docker-compose version
3. Kernel version uname -a
4. Assuming you're using the latest version v0.7.0

[Yamakasi]

I run it using a docker compose file.

Client: Docker Engine - Community
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:53:57 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:52:06 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker-compose version 1.25.0, build unknown
docker-py version: 4.1.0
CPython version: 3.9.5
OpenSSL version: OpenSSL 1.1.1j  16 Feb 2021

Yes I use 0.7.0, same happens with lower versions.

[shinebayar-g]

Mhm. I also need docker-compose file content (remove sensitive contents).. to reproduce on my end.

[Yamakasi]

Mhm. I also need docker-compose file content (remove sensitive contents).. to reproduce on my end.

Can you give a working example from your side ? Here it doesn't matter much what I try.

[shinebayar-g]

Examples on the README are working examples.

[shinebayar-g]

I worked on multiple improvements. I highly recommend you try latest changes on main branch. If you have Go installed just clone the source code, then run go mod download && go run main.go

Then run docker run .. commands from README to verify. I also verified docker-compose example.

[Yamakasi]

OK thanks for the updates, good work! I'm trying to deploy a traefik container which gives me back the following:

This happens on host mode port

2021/12/26 14:40:58 ufw-docker-automated: Connecting to the Docker API. Listening for events..
2021/12/26 14:51:33 ufw-docker-automated: Couldn't detect the container IP address.

THis happens on natting the port:

2021/12/26 15:02:58 ufw-docker-automated: Container information not found
2021/12/26 16:48:07 ufw-docker-automated: Couldn't detect the container IP address.

[shinebayar-g]

I see, thanks for the updates.
First of all, docker's publish IP Address -p or --publish mode doesn't work on host network mode. Because container will simply share the same network as a host. Docker cannot do port manipulation in this case. -p will be ignored.

By natting if you mean docker's -p or --publish it should work. But without host mode. Container information not found is coming from delete handler. This message is printed on container stop event. It means program has no knowledge about container that's shutting down. So try running a ufw-docker-automated before starting the container.
It should grab the starting container then store the container information in the memory. Then it should be able to add & remove ufw rules accordingly.

Couldn't detect the container IP address. message is coming from docker-compose network handler on container start event. If it shows up all the time, try running a single container with docker run .. to test.

[shinebayar-g]

I just cut a new release for your convenience if you want to try.

[Yamakasi]

I just cut a new release for your convenience if you want to try.

Nice, thanks, testing out.

Small update so far:

2021/12/26 22:52:46 ufw-docker-automated: Deleting rule: ufw allow out on eth1 from 10.1.0.0/28 to 10.1.0.0/28
2021/12/26 22:52:46 ufw error: exit status 1 ERROR: Invalid syntax

[shinebayar-g]

That doesn't look right.

Deleting rule: ufw allow out on eth1 from 10.1.0.0/28 to 10.1.0.0/28

Currently ufw-docker doesn't do anything specific on network interface level. It doesn't support network interface level instructions.

[Yamakasi]

Small question: Would this be possible to use on overlay networks, so in swarm ?

[shinebayar-g]

I never tested this on swarm.

[Yamakasi]

I never tested this on swarm.

It doesn't seem to pickup then, I'm testing out but as far as I know it worked on the pre-go versions.

[shinebayar-g]

Original ufw-docker seems to support Docker swarm mode. I'll try to dome research on this topic later.

[Yamakasi]

It does indeed but I'm not sure about the agent it should/needs to start in that case.

Would be nice to help out where I can! Thanks!

[shinebayar-g]

I have 0 experience with docker swarm. If you could give me a brief and exact instructions to follow on the #42 issue it would be helpful. Like first do this, then do that, run this command etc stuff..

Btw is your original issue resolved? Or was it docker swarm issue all along?

[Yamakasi]

What kind of instructions are you looking for ?

I'm investigating, it seems to be docker/swarm related so far, "local" works fine it seems, thanks for that!