-
-
Notifications
You must be signed in to change notification settings - Fork 493
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
[Feature Request] Monitoring traffic inside network namespaces #1010
Comments
Hi @bakamomi , Try adding a rule to redirect forwarded packets to the daemon: |
I added this rule. I also tried enabling the built-in "Intercept forwarded connections (docker, etc)". It didn't work. Correct me if I'm wrong, but the rule you suggested assumes that all traffic from a netns is sent unencrypted to the host where it's forwarded and sent out. But wireguard netns doesn't do this. |
Alright, I keep making this mistake 0:) so let's start over. Please, post the following information:
Usually there're firewall rules involved to forward traffic from namespaces to the host (docker for example), that's why I asked to add a rule for that. Do you have firewall rules to handle the wireguard connections?
mmh, I think that this is the expected behaviour, but I need more details. Debug logs will provide useful information, but maybe we'd need a firewall rule to intercept those connections before they're routed through the tunnel. Interesting use case!probably I'll need to reproduce it locally. |
The debug log turned out to be huge. I posted it on privatebin for convenience. Regardless, the ip address of the wg interface (192.168.3.5) isn't recorded there. These are the only lines directly related to wireguard:
I use a wireguard obfuscating proxy (swgp-go). It listens on 20222. Wireguard itself is on 47551. Further in the log you can find messages about trying to resolve discord.com. It happened exactly when I updated discord inside my wg netns. I have systemd-resolved resolving dns records for the wg netns. More importantly, the log didn't record any new connections even though they happened inside the netns. For reference, I have somewhat complicated setup. The firewall on my baremetal system blocks all outgoing traffic aside from LAN and my remote wg server. When I want to give a program access to the internet, I put it inside one of a netns with internet access. Specifically, I run Here is how my wg netns looks like:
My baremetal system has no interface connected to the wg netns. It's isolated.
Here are kprobe_events:
|
Thank you @bakamomi ! The problem is that we create the netfilter queue and the interception rules in the root namespace. After thinking a little bit about this, there're a couple of solutions (probably more and better):
|
Thanks for looking into this! What way you choose to implement this feature is of course up to you, but here are my 2 cents:
I think that this would break certain usecases, like when you want to isolate a netns from root completely, e.g., wg netns, or if you push a physical net interface into a netns.
This does sound like the simplest solution, and it won't break anything. eBPF might be the most robust choice, but I have no idea how hard it would be to implement in opensnitch. |
Hi, again! |
Sorry @bakamomi , I think the PoC is not practical. We should do it via ebpf. |
Some network namespaces forward to the host only encrypted traffic. In particular, wireguard supports this by pushing its interface into a netns https://www.wireguard.com/netns/
Because of this the current method of intercepting netns traffic at the Mangle table doesn't work. Nothing gets intercepted. OpenSnitch sees only encrypted wireguard traffic.
As a stopgap, I considered monitoring traffic inside netns via a new OpenSnitch node by launching an additional instance of the daemon inside this netns. But it seems the UI can connect to "remote" nodes only via tcp. My wireguard netns doesn't even have a bridge to the host. There is no direct tcp link. Instead, I wanted to connect to the node via a unix socket, but the UI supports only one socket connection.
Summary
Please add the ability to monitor traffic inside netns. One possible solution is by allowing "remote" nodes to connect via additional unix sockets like the local one.
The text was updated successfully, but these errors were encountered: