Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker bypasses ufw firewall rules #690

Open
2 of 3 tasks
binaryfire opened this issue Jun 5, 2019 · 73 comments
Open
2 of 3 tasks

Docker bypasses ufw firewall rules #690

binaryfire opened this issue Jun 5, 2019 · 73 comments

Comments

@binaryfire
Copy link

@binaryfire binaryfire commented Jun 5, 2019

  • This is a bug report
  • This is a feature request
  • I searched existing issues before opening this one

Expected behavior

Hi all!

ufw in ubuntu should be treated as the "master" when it comes to low level firewall rules (like firewalld in rhel). However docker bypasses ufw completely and does it's own thing with iptables. It was only by chance (luckily!) we discovered this. Example:

ufw deny 8080 (blocks all external access to port 8080)
docker run jboss/keycloak

Expected behaviour: the Keycloak container should be available at port 8080 on localhost/127.0.0.1, but not from the outside world.

Actual behavior

UFW reports port 8080 as blocked but the keycloak docker container is still accessible externally on port 8080.

There is a workaround (https://www.techrepublic.com/article/how-to-fix-the-docker-and-ufw-security-flaw/) however I think techrepublic are correct when then describe it as a "security flaw", and it's a pretty serious one. Most people using ubuntu user ufw. I imagine a large number of them are unaware their UFW rules are being bypassed and all their containers are exposed.

Is this something that can be addressed in the next update? That article was published in Jan 2018.

@binaryfire binaryfire changed the title Docker --net=host bypasses ufw firewall rules Docker bypasses ufw firewall rules Jun 5, 2019
@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Jun 5, 2019

The problem is ufw does it's own thing here. The best thing to do here would be to insert a jump rule into the DOCKER-USER chain which will forward to the ufw chain.
There is a pretty lengthy discussion on this in github.com/moby/moby, though (search is failing me, unfortunately).

Note that in your example, docker is not doing anything with iptables OR networking since it's using --net=host.

@binaryfire
Copy link
Author

@binaryfire binaryfire commented Jun 5, 2019

@cpuguy83 Thanks for the quick reply.

With --net=host specified docker (latest version) is still opening the port via iptables, at least on my ubuntu 18.04 fresh install. If that's not supposed to be happening, maybe it's a bug? I agree it definitely shouldn't be doing anything with iptables or networking if --net=host is specified.

I'll see if I can find the thread you mentioned. Perhaps the docker install process could automatically add DOCKER_OPTS="--iptables=false" if ufw is enabled?

@Nutomic
Copy link

@Nutomic Nutomic commented Jul 1, 2019

I just came across the same article myself, and I am very surprised by this behaviour. I dont know all the details about Linux networking, but is there any reason to be doing it? I never heard of any other program that goes around the firewall. If this is some kind of feature, it should definitely disabled by default because it opens up the entire server.

@binaryfire
Copy link
Author

@binaryfire binaryfire commented Jul 2, 2019

@Nutomic I agree. I don't think looking at this as a "UFW problem" is the right approach. The way UFW manages the firewall is quite elegant, which is why the majority of Ubuntu users are using it over firewalld.

I really think the docker devs need to add UFW compatibility ASAP as it's a serious security issue. Or include a clear warning on install letting users know their UFW rules will be ignored and instructions on a workaround.

@lonix1
Copy link

@lonix1 lonix1 commented Sep 6, 2019

@Nutomic ...which is why the majority of Ubuntu users are using it...

+100 All of us are using ufw.

This is an exploit waiting to be exploited.

This should be considered a security risk. Why is it not given priority?

@lonix1
Copy link

@lonix1 lonix1 commented Sep 7, 2019

Does someone know how to report security risks?

In other projects there is usually an email address (or some other mechanism) to report exploits directly to management.

If a server is compromised and docker can be blamed somehow, it would be a major PR headache (at best) for docker management, so I'm sure they'd want to know about this immediately. And if it cannot be fixed, I'm also sure they'd quickly update the docs with major warnings about this problem to let users know about it and legally pass the blame onto us. We should not discover this problem by accident, it should be made clear in the docs - and how best to work around it.

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 7, 2019

There is a SECURITY.md in the moby repo explaining it.
This is not an exploit, however it is easy to misconfigure.

I don't think the desired outcome should be to default to iptables=false but rather have a way to have docker insert its jump rule into ufw.

@binaryfire
Copy link
Author

@binaryfire binaryfire commented Sep 7, 2019

@cpuguy83 IMHO the fact that it's so easy to misconfigure makes it a pretty serious security risk. Other than third party firewall software, I don't know of any other packages that bypass UFW rules. It's such a low-level OS function that most users, even advanced ones, wouldn't think to check.

Definitely agree re: implementation though. Getting Docker to insert its jump rule into UFW would be great.

@lonix1
Copy link

@lonix1 lonix1 commented Sep 7, 2019

Thanks to @cpuguy83, it's:

security @ docker . com

I recommend we all send a message there.

@binaryfire
Copy link
Author

@binaryfire binaryfire commented Sep 7, 2019

I just had a look at the multiple UFW-related issues for moby and they've all been closed... :/ Does anyone know if podman has the same problem? If not, might be a viable alternative

@lonix1
Copy link

@lonix1 lonix1 commented Sep 7, 2019

That is very surprising! More reason for us to message the security team. This is crazy - how many users don't know they have gaping holes in their security because of this???

For anyone arriving here from google in the future, please do two things:

  • +1 the OP's issue
  • email security @ docker . com

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 7, 2019

btw, I'm think all that's needed is to insert a jump rule from DOCKER-USER to ufw-user-forward

e.g.

sudo iptables -A DOCKER-USER -j ufw-user-forward

@kaysond
Copy link

@kaysond kaysond commented Sep 9, 2019

Adding some info per @menathor request

See:

Most of these recommend disabling iptables manipulation with --iptables=false and manually configuring the rules as necessary. (i.e. add the following to /etc/ufw/before.rules)

      *nat
      :POSTROUTING ACCEPT [0:0]
      -A POSTROUTING ! -o docker0 -s 172.16.0.0/12 -j MASQUERADE
      COMMIT

More recently, two other workarounds have surfaced which do not use this flag and seem to be more robust:

@lonix1
Copy link

@lonix1 lonix1 commented Sep 9, 2019

Someone from the docker team please tell us the official and secure way to deal with this problem?

I don't want to become an iptables expert just so I can use docker.

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 9, 2019

@lonix1 Did you try sudo iptables -A DOCKER-USER -j ufw-user-forward?

@lonix1
Copy link

@lonix1 lonix1 commented Sep 9, 2019

There are about a dozen approaches starting from 2013/2014, and changing with each major version of docker. At this point I have no understanding which to use, and why. I know ufw well, but not iptables.

I'm hesitant to use the mindless copy-paste approach as I'm afraid to blow up my servers's security. That's why I would be grateful for official guidance, and explanation.

The code you posted seems good, but I have no idea what it does 😃 Would you mind telling us in your opinion which is the best way (I assume it's what you posted above), and why/how it works?

(The simplest approach I've found is not to change anything, but use 127.0.0.1:8080:80 and expose the 8080 via nginx, but even then I'm not sure if that's the best approach, though it seems "cleanest".)

Thanks for helping us out!

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 9, 2019

TMK nothing has changed in a very long time.
I do not expect the default handling of this to change either as it effects many many users.

Docker creates an iptables chain called DOCKER-USER, this is where users can add their own filtering logic, this gets run before port forwarding rules.
The above command puts a jump rule fro, DOCKER-USER to ufw-user-input, which means anything that hits DOCKER-USER (which should be anything Docker related) will get passed along to the ufw-user-forward chain which is where ufw rules should go.

@lonix1
Copy link

@lonix1 lonix1 commented Sep 9, 2019

@cpuguy83 So if I understand correctly, if I implement your approach, thereafter I can continue to use ufw to open/close ports, and never need to mess around with iptables at all? That sounds perfect.

On another note, since you are obviously an expert in this matter, how do you feel this approach compares to the one I posted above (127.0.0.1:8080:80 + nginx) - do you feel one is better/safer/ whatever than the other?

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 9, 2019

@kaysond
Copy link

@kaysond kaysond commented Sep 10, 2019

I do not expect the default handling of this to change either as it effects many many users.

@cpuguy83 I think its less about a change in behavior and more about a documented best practice to make things work securely.

I say this realizing that you can be explicit about which interface/ip to listen on. But if the expected behavior of UFW is that it blocks all incoming traffic except where specified, then to avoid mistakes, it should do so for Docker as well. Even if it takes some extra configuration.

Also your jump rule sudo iptables -A DOCKER-USER -j ufw-user-forward doesn't work. The first rule in the DOCKER-USER chain is a RETURN (at least in my setup), so it never hits the appended rule. Changing to an insert (sudo iptables -I DOCKER-USER -j ufw-user-forward) fixes that problem but still doesn't seem to work.

@lonix1
Copy link

@lonix1 lonix1 commented Sep 10, 2019

@kaysond What workaround are you using at the moment?

@binaryfire
Copy link
Author

@binaryfire binaryfire commented Sep 10, 2019

EDIT: just fixed my docker / ufw example - the first one didn't make any sense. It's late over here :P

💯 x this:

I think its less about a change in behavior and more about a documented best practice to make things work securely.

Any solution that requires sysadmin knowledge / reconfiguration every time new ports are involved isn't a viable solution. The whole idea behind ufw and docker is ease of use. So taking a step back and breaking it down into super simplistic (i.e. developer) terms:

docker run -p 9000:9000 imnotasysadmin makes imnotasysadmin available on port 9000

I then proxy port 9000 to be behind an oauth gateway on port 443

ufw deny all then ufw allow from 192.168.1.2 to any port 443 means imnotasysadmin should not be accessible on port 9000, and should only be able accessible from 192.168.1.2 via the oauth proxy on 443.

The only reasonable solutions for users like me are:

  1. Docker adds a way of handling this out of the box
  2. Docker provides an official workaroud for ubuntu in their docs (eg. a fixed set of iptables rules) which will handle this in the background and not require modification again after they're set up.

I can't speak for all Ubuntu's users, but I'm a developer, not a sysadmin. I have reasonable linux skills and could implement either of the above solutions no probs. But I no longer feel comfortable using docker on ubuntu in production if my network security is based on hacks from third party sites that may or may not work in certain situations, or may break with future updates.

How can I run things like keycloak, rundeck or other sensitive apps that I'm proxying to 443 and putting behind an oauth proxy if there's any chance docker is going to completely ignore my deny rules and happily expose the original port?

Sorry if this is sounds a bit harsh and peace and love to everyone here, but this has already turned into another "try workaround x" and "workaround x doesn't work when x+y=z" thread. Every one of those on the moby repo have been closed, dating back years.

Developers using Ubuntu (the linux distro with the biggest market share) need an official, supported and documented way of setting docker up so that we can happily docker run and ufw allow / ufw deny all day and everything works as expected.

Or alternatively, official clarification from Docker that "docker does not work with Ubuntu's default firewall". That would be better than silence.

TLDR: https://tenor.com/view/developers-gif-13292051

☮️❤️

@lonix1
Copy link

@lonix1 lonix1 commented Sep 10, 2019

@menathor I'm in the same boat as you exactly. And I'm also wary of the copy-pasta approach.

So I decided to dump ufw and use iptables. Which annoys me, as I have to waste time learning it.

I'm still going through various tutorials. But what surprises me so far, is despite the widely-held belief that iptables is "low-level" and complicated.... it's not. It's simple.

I assume there are edge cases though that you wouldn't typically think of - icmp, specific ports, etc. But if you use a whitelist (rather than blacklist) then at the very worst, you'll make a mistake that'll lock you out of your own server. That's not a problem as you can log in via your hoster's web-based console and fix it, and importantly - the bad guys won't be able to get in either. This is the one and only downside to using iptables, and it's manageable.

Here are some tutorials I'm going through:

More theoretical:

I'll post my final config when I'm done in a few days, if others do the same then we can compare.

@kaysond
Copy link

@kaysond kaysond commented Sep 10, 2019

@kaysond What workaround are you using at the moment?

@lonix1 Right now, nothing. But I'm working on a larger scale deployment that needs a solution. For now I would suggest reading this: https://github.com/chaifeng/ufw-docker

It has a very descriptive readme, and once you have an idea of what its doing, I'd just run the script. This is a temporary solution until the Docker team comes up with something.

@cpuguy83
Copy link
Collaborator

@cpuguy83 cpuguy83 commented Sep 10, 2019

This is a temporary solution until the Docker team comes up with something

I would say that is the "fix".
At best we could add a flag to check ufw before running docker rules, but it's the same outcome: an iptables rule that jumps chains.
This is the purpose of the DOCKER-USER chain.

@kaysond
Copy link

@kaysond kaysond commented Sep 10, 2019

I would say that is the "fix".
At best we could add a flag to check ufw before running docker rules, but it's the same outcome: an iptables rule that jumps chains.
This is the purpose of the DOCKER-USER chain.

Well, yes. I think its reasonable to have a set of iptables rules be the "fix," and its easy enough to implement via UFW's config files. But what the community is looking for is something that has been thoughtfully considered by the Docker team and published in the documentation.

For example, the script I linked will allow all traffic from RFC 1918 ranges to reach the Docker network. This is not how UFW behaves by design. If I turn on a service on my Ubuntu host, but don't explicitly allow it in UFW, not even local traffic should reach it.

And maybe that difference is fine. But I, and probably most others, would be more comfortable taking the recommendation from the Docker documentation, and not some guy's github.

@kaysond
Copy link

@kaysond kaysond commented Sep 16, 2019

Bump. Anyone have any more input? Maybe we need to open an issue on the documentation repo...

@lonix1
Copy link

@lonix1 lonix1 commented Sep 17, 2019

Hey @kaysond Sorry I forgot about this thread. I've been using iptables for a week now and couldn't be happier. For anyone who arrives here, these two links will help you integrate iptables and docker very simply:

If you still want to integrate ufw and docker, then I think what @cpuguy83 wrote above is the way to go (or a variation on that idea). Any rules in the DOCKER-USER chain will be run before docker's own rules, so if there's a jump from there to one of ufw's chains then it MUST work. The question is what order to use, and which one of ufw's many chains to jump to. You'll need to experiment.

Of course the ideal is for the docker team to provide clear guidance of a tested/supported rule, because this isn't something most ufw users know how to do.

@n-stone
Copy link

@n-stone n-stone commented Nov 3, 2020

Wow that's really upsetting that their is no official guide or what ever from the docker team. After reading through most of the posts (here and on Stack Overflow) for me personally the best method will be to set the default binding IP of docker to 127.0.0.1:

$ sudo nano /etc/docker/daemon.json 
{
    "ip" : "127.0.0.1"
}
$ sudo service docker restart

And configure UFW only for non docker services.
This way you need to explicite bind to your external IP e.g. 192.168.1.1:8080:80
Still I would rather like docker to honor UFW rules, but with this approach you don't need to mess around with iptable or ufw rules.

Edit:
Oh man this is frustrating, Docker-Compose does not honor the docker daemon.json settings: docker/compose#2999

So in docker-compose files you still have either to explicitly bind the ports to localhost or set network_mode: default

@lepe
Copy link

@lepe lepe commented Nov 14, 2020

I have a few months since I learned how to deploy services with docker (as I usually use LXD, I didn't have this security issue before). We deployed an Elastic Search database (docker) service in a customer's server, which was intended to be accessed only by another server in the local network. The server in which ES was installed had only SSH port exposed (using UFW) to the outside for maintenance. After few days the ES data was gone and instead a domain was showing in the data (good that was only testing data). It was mind blowing!. We thought the server was hacked. We spend so much time looking for clues which lead to nothing. Finally we tested accessing the service directly with the global IP address and that is how I ended here.
We have tried most of the recommendations without success (either everyone have access or no one). Some cases seemed to work, but after rebooting, things went back to the same. Dropping UFW and use only iptables will take time as neither of us is confident with it. So I came with another alternative using one of my favorite tools: rinetd (a TCP/UDP port redirector):
This method doesn't require any changes in iptables or ufw. You need to bind the ports in your containers to 127.0.0.1 (instead of 0.0.0.0 or empty). If you can't remove and re-run the container, then stop docker service, modify the hostconfig.json file (which is under /var/lib/docker/containers/<HASH>/) and replace/add the value of HostIp, just after PortBindings to 127.0.0.1). Start docker again. With that change, the service must be only accessible from localhost.
Then, install rinetd and add this rule in /etc/rinetd.conf:

# HOST_IP         HOST_PORT  FWD_TO_IP    FWD_TO_PORT
xxx.xxx.xxx.xxx   9200       127.0.0.1    9200

in which xxx... is the IP to bind the service (either local network IP or global IP depending on your needs).
After that, UFW rules will be respected (e.g. ufw allow from yyy.yyy.yyy.yyy to any port 9200 proto tcp)
It worked for me so far and it works after reboots, so I hope this helps in any way. I'm not sure if it may have side effects, so make your own tests before trusting this method.
I really hope the docker team can address this situation so no hacks are required to make it safe to use by anyone.

I had the same idea as you but it didn't work. I will retry that.

I tried it again but it seems UFW is not applied on rinetd too?
xxx.xxx.xxx.xxx 9200 127.0.0.1 9200

when adding the above config to rinetd, port 9200 seems to be open to everyone although there is no allow rule in UFW (everything is rejected by default on my UFW)

Why is not working? These are two things you should check:

  1. You are not binding your docker containers to "127.0.0.1". For example: docker run -p 127.0.0.1:9200:9200 elastic. If you are binding to 127.0.0.1 it should never be open to the outside as it is only listening in the local port. So I think you missed this part.
  2. If you are sure you did the previous step, check try to flush the existing iptable rules (perhaps some rule was left from your previous attempts).

I have used this method in several severs now and I can tell it has worked 100% of the times (all ports are closed to the outside world unless I specify them in rinetd).

@nnthuanegany
Copy link

@nnthuanegany nnthuanegany commented Dec 7, 2020

I have a similar problem. Tried some of the ways on google. However, it doesn't work.
So I decided to use the cloud firewall service. I think that's a good solution.

However, I still expect this error to be fixed so that the developers can run docker swarm and ufw allow and ufw deny work as expected.

Thanks.

@pySilver
Copy link

@pySilver pySilver commented Jan 25, 2021

@preciz
Copy link

@preciz preciz commented Feb 2, 2021

When I used docker run -p [ipv6address]:port:port and enabled ufw the port got blocked properly even on that ipv6 address.
Until this issue is solved I assume it's a more obscure option to bind the port to an IPv6 address.

@lllibailll
Copy link

@lllibailll lllibailll commented Feb 13, 2021

The only thing that helped me: https://p1ngouin.com/posts/how-to-manage-iptables-rules-with-ufw-and-docker

It worked for me too.

@jhgehrs
Copy link

@jhgehrs jhgehrs commented Feb 15, 2021

The only thing that helped me: https://p1ngouin.com/posts/how-to-manage-iptables-rules-with-ufw-and-docker

thank you, worked for me too

@huggge
Copy link

@huggge huggge commented Feb 24, 2021

The only thing that helped me: https://p1ngouin.com/posts/how-to-manage-iptables-rules-with-ufw-and-docker

thank you, worked for me too

Note that the $INTERFACE variable must be replaced with the name of the primary host interface used by Docker (such as eth0 or eno1).

How do I find out what primary host interface Docker is using?

@art-dambrine
Copy link

@art-dambrine art-dambrine commented Mar 24, 2021

Is there any official/best practice/whatever approach to get pass this problem?

Another option, which is what I usually do, is bind exposed container ports to 127.0.0.1 (by default they're bound to any IP address - 0.0.0.0), which makes them inaccessible outside the local system. I then run a reverse proxy and route traffic to the containers in that way.

Worked like a charm in my case thank you ! Didn't think of it the first time I was facing this problem 👍
(I might have to go deeper for more complex cases but it suits my needs for now using a nginx reverse proxy)

@Gaulomatic
Copy link

@Gaulomatic Gaulomatic commented Mar 25, 2021

This issue will be addressed shortly after the Vulcans land in Bozeman, Montana.

@peterthehermit
Copy link

@peterthehermit peterthehermit commented Mar 26, 2021

This is ridiculous, get yer house in order docker.

@ninobaldo
Copy link

@ninobaldo ninobaldo commented Apr 1, 2021

After a long time I found the must simple way do to this. Just follow https://github.com/chaifeng/ufw-docker#solving-ufw-and-docker-issues

@Cryotize
Copy link

@Cryotize Cryotize commented Apr 10, 2021

Its been nearly 2 years now, any update on this?

@Gaulomatic
Copy link

@Gaulomatic Gaulomatic commented Apr 10, 2021

Docker gives a crap about this issue (among others). I switched over to Podman for everything I can. This might not be the a solution in all cases, but in production is most certainly is. Podman works quite well with firewalld, which is more flexible anyway. It took me a couple of days to work around the differences between Docker and Podman, but I don't look back.

Container orchestration is not quite there yet, but it is worth taking a look at. For me it seems like Docker is on the Nokia type track.

@mr-karan
Copy link

@mr-karan mr-karan commented Jun 24, 2021

Another company who got seriously impacted by this: https://news.ycombinator.com/item?id=27613661

@Pimmelton
Copy link

@Pimmelton Pimmelton commented Jun 24, 2021

Thanks, @mr-karan . This is a great example of how even non-novice Docker users can easily be bitten by this problem because it blatantly violates the principle of least surprise. Silently bypassing security measures set up by a primary system security tool on an officially supported (https://docs.docker.com/engine/install/) distribution is not what people expect. This almost meets the definition of backdoor: "A backdoor is a means to access a computer system or encrypted data that bypasses the system's customary security mechanisms.". Maybe this is an accidental backdoor created in the name of convenience rather than a deliberate one intended for malicious purposes, but the results are the same.

Unbelievable.

@matthewblott
Copy link

@matthewblott matthewblott commented Jul 17, 2021

Excellent solution provided here. It's the instructions (reasonably straightforward) to create an alternative ufw-docker to use instead of ufw for creating rules. It has over a thousand stars and I'm surprised it's not been flagged already in this thread but I'm using it now and it seems okay so far.

@g4z
Copy link

@g4z g4z commented Jul 20, 2021

it's been mentioned multiple times in this thread. for example, kaysond commented on 10 Sep 2019 above. personally, i cannot get it to block the incoming traffic to container ports over tun0 :(

@dada513
Copy link

@dada513 dada513 commented Aug 4, 2021

It's sad this issue is so old yet is still putting servers at risk.
If I hadn't tested my firewall rules using the Tor network my security measures would be useless. Ufw-docker is a good workaround

@jdqw210
Copy link

@jdqw210 jdqw210 commented Aug 18, 2021

How is something like this even possible????

@dada513
Copy link

@dada513 dada513 commented Aug 18, 2021

How is something like this even possible????

I don’t know, it’s sad that docker bypasses it

@oonqt
Copy link

@oonqt oonqt commented Oct 10, 2021

The fact that his has gone completely ignored for years is extremely pathetic. Another reason for me not being a fan of Docker.

@J4gQBqqR
Copy link

@J4gQBqqR J4gQBqqR commented Oct 27, 2021

I come across the news today and it surprises me. I never thought that I opened my server's ports to the public internet because Docker circumvent UFW!

It gives me a sudden rise of blood pressure and keeps it high for the rest of the day until I shut my ports off behind a physical firewall.

This is really BAD.

I would not blame UFW for not handling docker but the opposite.
If I installed Chrome on my machine and Chrome opened my firewall ports, I will hold Chrome for responsibility. The same hold for Docker.

According to my reading, this issue has been reported in the 2014.
The team member closed that issue by asking everyone to not use UFW but to use IPTABLES instead (if I am reading it correctly).

It is pathetic.
7 years, nothing done. Not even a significant warning in the documentation.
I am now seriously starting to consider other containerization tools.

@dada513
Copy link

@dada513 dada513 commented Oct 27, 2021

It has been 3 years. Even more from older closed issues. Why has NOTHING been done to fix this? Why is this issue completely ignored from docker maintainers? There are workarounds, but come on, this is not okay

@benjamir
Copy link

@benjamir benjamir commented Oct 27, 2021

Honestly: I was complaining like everybody else here. In the meantime I switched to firewalld which works excellent on Ubuntu on Debian:

  • can be used quite easily once you get your head around zones (and runtime config vs permanent config -- which is a great feature in itself)
  • works flawless with docker and podman

Do yourself a favour: ditch UFW. Either go iptables (hardcore), or enjoy firewalld (comfy).

@matthewblott
Copy link

@matthewblott matthewblott commented Oct 27, 2021

FWIW I've switched to using rootless docker and the problem has gone away.

@yeahman45
Copy link

@yeahman45 yeahman45 commented Oct 27, 2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet