search

evilsocket / opensnitch

OpenSnitch is a GNU/Linux interactive application firewall inspired by Little Snitch.
GNU General Public License v3.0
10.92k stars 509 forks source link

opensnitch's nft backend touches the iptables-nft table (cgproxy + v2ray) #885

Open unknowndevQwQ opened 1 year ago

unknowndevQwQ commented 1 year ago

Describe the bug When opensnitch's firewall backend is nft, the table used by nft for xt compatibility is changed, which causes applications using xt to behave abnormally......at least they don't work as expected due to missing xt rules.iptables will pass a prompt that nft should be used instead of the iptables management table.

Include the following information:

To Reproduce

Steps to reproduce the behavior:

  1. Set the Firewall to nftables in /etc/opensnitchd/default-config.json.
  2. Run systemctl enable --now opensnitsh
  3. Start GUI
  4. iptables prompts for rules that should be managed using the nft utility when displaying the filter and mangle tables.

Expected behavior (optional) opensnitch uses its own tables instead of the default five tables.

Additional context I'm still trying to avoid xtables, but there are a lot of things that still rely on xt. some of the more well-known examples I can come up with include cni-plugins, docker, libvirt, k8s, and a lot of tools I don't recognize. Adding chains unknown to xt to the default table may cause unpredictable behavior in tools that rely on xt.

gustavo-iniguez-goya commented 1 year ago

Hi @unknowndevQwQ ,

When opensnitch's firewall backend is nft, the table used by nft for xt compatibility is changed, which causes applications using xt to behave abnormally......at least they don't work as expected due to missing xt rules.

Could you expand on what's not working? If you could post a detailed example it would be useful.

What xt rules are missing?

I have no idea how we're interfering in this case. When using nftables we don't use the nft binary, we add the rules directly to the kernel. I mention it because in some systems iptables for example points to iptables-nft (lrwxrwxrwx. 1 root root 22 nov 16 2018 /etc/alternatives/iptables -> /usr/sbin/iptables-nft)

gustavo-iniguez-goya commented 1 year ago

Does it work if you use "Firewall": "nftables"?

unknowndevQwQ commented 1 year ago

Does it work if you use "Firewall": "nftables"?

I've set it up and that didn't solve the problem.

unknowndevQwQ commented 1 year ago

Could you expand on what's not working? If you could post a detailed example it would be useful.

What xt rules are missing?

I have no idea how we're interfering in this case. When using nftables we don't use the nft binary, we add the rules directly to the kernel. I mention it because in some systems iptables for example points to iptables-nft (lrwxrwxrwx. 1 root root 22 nov 16 2018 /etc/alternatives/iptables -> /usr/sbin/iptables-nft)

First, insert a rule into any chain of the filter and mangle tables of iptables-nft, start opensnitch, and then try to view the filter/mangle table iptables-nft will prompt Table 'filter' contains incompatible base-chains, use the 'nft' tool to list them. This causes any tool that uses iptables to no longer be able to write new rules. Existing rules are also rendered useless because of their priority.The rules work, but that prompt from iptables is rather annoying.

gustavo-iniguez-goya commented 1 year ago

Can you change the configuration field "Firewall" to "iptables" and see if it works as expected?

unknowndevQwQ commented 1 year ago

Can you change the configuration field "Firewall" to "iptables" and see if it works as expected?

There are no conflicts with other processes using iptables, but the nfqueue rule added by opensnitch seems to stop matching other rules once it passes?

gustavo-iniguez-goya commented 1 year ago

yes, that is expected. Once we receive an outbound connection via the nfqueue rule, we allow or deny it.

Think of it as any other rule with target DROP / ACCEPT, except that in this case the verdict is applied dynamically based on rules.

unknowndevQwQ commented 1 year ago

yes, that is expected. Once we receive an outbound connection via the nfqueue rule, we allow or deny it.

Think of it as any other rule with target DROP / ACCEPT, except that in this case the verdict is applied dynamically based on rules.

If the traffic will not continue to match the nft/xt rule after accept, I would want opensnitch to have a lower priority, since I am using a transparent proxy tool.

gustavo-iniguez-goya commented 1 year ago

Please, explain in great detail your setup:

unknowndevQwQ commented 1 year ago

Please, explain in great detail your setup:

  • name of the transparent proxy tool

cgproxy + qv2ray/v2ray

cgproxy is responsible for configuring iptables rules and putting specific applications into specific cgroup paths for proxying. qv2ray is responsible for configuring v2ray, and v2ray provides proxy capabilities.

My current use case has two v2rays, one controlled by qv2ray and the other v2ray provides the tproxy port and forwards traffic to the v2ray controlled by qv2ray.

  • What IPs and ports it makes use of.

By default, cgproxy expects v2ray to listen on the localhost:12345 tproxy port, but both cgproxy and v2ray can be configured for other ports. Export traffic? Depending on the proxy node used, there is no fixed list, and I have never denied any traffic when using opensnitch so far.

  • What other applications use the proxy.

cgroup v2 path /user.slice/user-1000.slice Exclude qv2ary and v2ray.

  • is opensnitch filtering connections passing throught the proxy?

Yes, but it will also somehow disconnect after allowing it.

  • etc.

v2ray has an unreachable problem when using the kcp protocol. I don't want to 「墙颜欢笑」 anymore.