I’ve only used ufw and just now I had to run this command to fix an issue with docker.
sudo iptables -I INPUT -i docker0 -j ACCEPT
I don’t know why I had to run this to make curl work.

So, what did I exactly just do?
This is behind my house router which already has reject input from wan, so I’m guessing it’s fine, right?

I’m asking since the image I’m running at home I was previously running it in a VPS which has a public IP and this makes me wonder if I have something open there without knowing :/

ufw is configured to deny all incoming, but I learnt docker by passes this if you configure the ports like 8080:8080 instead of 127.0.0.1:8080:8080. And I confirmed it by accessing the ip and port.

  • pe1ucaOP
    1·
    5 months ago

    I only had to run this in my home server, behind my router which already has firewall to prevent outside traffic, so at least I’m a bit at ease for that.
    In the VPS everything worked without having to manually modify iptables.

    For some reason I wasn’t being able to make a curl call to the internet inside docker.
    I thought it could be DNS, but that was working properly trying nslookup tailscale.com
    The call to the same url wasn’t working at all. I don’t remember the exact details of the errors since the iptables modification fixed it.

    AFAIK the only difference between the two setups was ufw enabled in the VPS, but not at home.
    So I installed UFW at home and removed the rule from iptables and everything keeps working right now.

    I didn’t save the output of iptables before uwf, but right now there are almost 100 rules for it.

    For example since this is curl you’re probably going to connect to ports 80 and 443 so you can add --dport to restrict the ports to the OUTPUT rule. And you should specify the interface (in this case docker0) in almost all cases.

    Oh, that’s a good point!
    I’ll later try to replicate the issue and test this, since I don’t understand why OUTPUT should be solved by an INPUT rule.