Opensnitch doesn't let through ICMP ECHO packets if the UI is running

[markozajc]

Greetings! I've encountered a bug in opensnitch that can cause numerious issues, including filesystem hangs for NFS and
generally broken behaviour in anything networked. I have pinpointed it to opensnitch not letting through outbound ICMP ECHO packets, but it only occurs if the UI is running.

Describe the bug
Opensnitch 1.4.0 blocks all ICMP ECHO packets when the UI is running. They do not show up on the log.

To Reproduce
Steps to reproduce the behavior:

1. Install opensnitch 1.4.0
2. Start opensnitchd
3. Run opensnitch-ui
4. Attempt to ping any host

Post error logs:
N/A

Expected behavior (optional)
Outbound ICMP ECHO packets aren't filtered.

Screenshots
N/A

OS (please complete the following information):

• OS: Bedrock Linux, opensnitch installed on the Debian stratum
• Window Manager: KWin
• Kernel version: Linux [hostname] 5.13.0-15.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 5.13-13.1~bookworm (2021-09-08) x86_64 GNU/Linux
• Version Debian 12/Bookworm

Additional context
This bug was not present in 1.3.6, but stopped working in one of the 1.4.0 RC's (I think it was .3, tell me if you want me to pinpoint it to a specific version).

[markozajc]

My mistake, for some reason /etc/opensnitchd/system-fw.json wasn't installed. After manually installing it from the deb, ICMP ECHO works as expected.

[gustavo-iniguez-goya]

👍 😉

[markozajc]

@gustavo-iniguez-goya Actually, I'm getting the same issue for my IPv6 tunnel. Is there a known fix or should I reopen the issue.

[gustavo-iniguez-goya]

what's that issue about? ipv6 tunnel == VPN?

[markozajc]

The issue is really the same as previously; ICMP ECHO requests getting dropped, but this time for IPv6 only. It's not a VPN tunnel, it's a v4tunnel, with Tunnel Broker as the endpoint provider.

[gustavo-iniguez-goya]

yay, I see. Please, add this block to the system-fw.json file:

"Rule": {
                "Description": "Allow icmp",
                "Table": "mangle",
                "Chain": "OUTPUT",
                "Parameters": "-p ipv6-icmp",
                "Target": "ACCEPT",
                "TargetParameters": ""
            }

[markozajc]

Thanks a bunch, you're a real life saver! This did the trick.

[markozajc]

For some reason, this only worked half the time. After quite some logging and debugging, I figured out you also need this for a v4tunnel (on the ipv4 chain):

"Rule": {
   "Description": "Allow icmp",
   "Table": "mangle",
   "Chain": "OUTPUT",
   "Parameters": "-p 41",
   "Target": "ACCEPT",
   "TargetParameters": ""
}

[gustavo-iniguez-goya]

thank you @markozajc for debugging it! I'll add it to the SystemRules section on the wiki.

mmh, I've been testing for a couple of days this change #493 to intercept WireGuard VPNs

I'm wondering if the v4tunnel tunnels goes also through iptunnel_xmit() path. If it does you sould be prompted to allow or deny the connection, and you wouldn't need to add the system rule.

Could you test this script with bpftrace and let me know if it output anything when you establish the tunnel?
Rename it to .bt and launch it as follow: # bpftrace --unsafe /tmp/udp_tunnel_xmit.bt (--unsafe is for allowing read files under /proc using system())

udp_tunnel_xmit.bt.txt

If the tunnel is intercepted there should be logs similar to this:

 +++ iptunnel_xmit: 600713, kworker/u16:2
	lport: 38525, dport: 0 (0?)
	xport: 0
	jport: 38525 -> 61000
	saddr: 0.0.0.0, daddr: 0.0.0.0
	_saddr: 192.168.1.234, _daddr: 192.168.1.65, 
pid cmdline:kworker/u16:2-events_unbound
ppid cmdline:kthreadd

[markozajc]

This is what I get on Debian's kernel:

Attaching 7 probes...
cannot attach kprobe, probe entry may not exist
Error attaching probe: 'kretprobe:setup_udp_tunnel_sock'

[gustavo-iniguez-goya]

ok, comment out the kprobe for setup_udp_tunnel_sock and try again please. What version of Debian and kernel are you using?

[markozajc]

I'm not quite sure what you mean by comment out here. Removing just the kprobe part yields

ERROR: Unrecognized probe type

while removing the entire setup_udp_tunnel_sock function yields

/tmp/udp_tunnel_xmit.bt:26:12-58: ERROR: ntop() expects an integer or array argument, got none
        $saddr = ntop(AF_INET, $sk->__sk_common.skc_rcv_saddr);
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/udp_tunnel_xmit.bt:27:12-54: ERROR: ntop() expects an integer or array argument, got none
        $daddr = ntop(AF_INET, $sk->__sk_common.skc_daddr);
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/udp_tunnel_xmit.bt:30-31: ERROR: ntop() expects an integer or array argument, got none
/tmp/udp_tunnel_xmit.bt:32-33: ERROR: ntop() expects an integer or array argument, got none

I'm on Debian 12/Bookworm/testing with kernel 5.10.0-8-amd64.

[gustavo-iniguez-goya]

ok, try it out with this one instead please. There's only one kprobe for iptunnel_xmit()

udp_tunnel_xmit.bt2.txt

Anyway, I'll try to setup an IP tunnel at some point. Taking a look at the code of the modules ipip and ip_gre,
they end up calling ip_tunnel_xmit(), so I'm curious about if we'll intercept them with this hook.

[markozajc]

This one worked. I get entries like this:

 +++ iptunnel_xmit: 68, ksoftirqd/11
        ports: 22000 -> 443
        saddr: 192.168.1.2, daddr: 216.66.86.114, 
pid cmdline:ksoftirqd/11

ppid cmdline:kthreadd

(216.66.86.114 is Tunnel Broker's IPv4 endpoint)

[gustavo-iniguez-goya]

yeah! thank you very much. When #493 gets merged we'll be able to ask users to allow or deny the tunnels connections.
Probably for v1.5.0rc1, since it's working fine for me now.

[gustavo-iniguez-goya]

oh btw, if you enable in Preferences->Nodes->[x] Debug invalid connections, does opensnitch ask to allow or deny an Outgoing connection?

[markozajc]

Nope. I've tried it both without and with the -p 41 rule and it works as-if the option wasn't enabled.