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

Intercept forwarded rule not working with docker and local network #1079

Open
red-gecko27 opened this issue Jan 3, 2024 · 1 comment
Open

Comments

@red-gecko27
Copy link

Describe the bug
When I enable the system rule "Intercept forwarded connections (docker, etc)" I can no longer access my Docker containers on the local network even when it is in the "disabled" status on the graphical interface.

Include the following information:

  • OpenSnitch version: 1.6.4
  • OS: Archlinux
  • Version: 6.6.9
  • Window Manager: Kde
  • Kernel version: Linux Desktop27 6.6.9-arch1-1
  • Docker version: Docker version 24.0.7, build afdd53b4e3

To Reproduce

  • Run docker container like: docker run --rm -it -p 80:80 strm/helloworld-http

  • From the OpenSnitch GUI, switch the status from "Running" to "Disabled" to ensure that the issue is not related to rules.

  • Attempt to access your container from an external device on the same local network, for example, using http://192.168.1.18.

    • Result: It works, and I can access the container.
  • Enable the system rule "Intercept forwarded connections (docker, etc)."

  • Try to connect again using http://192.168.1.18, and it's impossible to access the container.

I am using eBPF, and there are no errors in /var/log/opensnitchd.log.

My iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy DROP)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DOCKER (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:http

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere 
@gustavo-iniguez-goya
Copy link
Collaborator

hey @red-gecko27 !

Thank you for the detailed report. I've reproduced the problem and there're 2 workarounds:

  1. Modify the forwarding rule to intercept connections originated only from your containers network (typically 172.17.0.0/16).

Double click on the fw rule -> change "Match conntrack state(s)" to "Source IP" and enter the network, then add a new condition by clicking on the [+] button and add "Match conntrack state(s)" -> new (like in the following image).

  1. Enable [x] Debug invalid connections under Preferences -> Nodes -> General
    You can create a rule then to allow connections to the container IP + port.

In this scenario, as it's an inbound connection, it doesn't belong to any app yet, thus the connection is discarded by default.

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

No branches or pull requests

2 participants