[Feature Request] Allow Minecraft broadcast announcements through

[petterreinholdtsen]

Summary:

On my test box, after activating opensnitch, my Minecraft installation was no longer able to host LAN servers. I had to disable opensnitch to get this working. The Minecraft LAN server system uses broadcast packages to announce its presence on the net, as far as I know.

[gustavo-iniguez-goya]

Enable [x] Debug invalid connections on the Preferences -> Nodes , and see if it prompts you to allow an "outgoing connection".
I'm sure I've talked about this with someone else, but I don't find any related issues right now.

[petterreinholdtsen]

[Gustavo Iñiguez Goia]

Enable `[x] Debug invalid connections` on the Preferences -> Nodes , and see if it prompts you to allow an "outgoing connection".

Did not really happen much different when enabling this one.

…

-- Happy hacking Petter Reinholdtsen

[gustavo-iniguez-goya]

ok, let's see if we can identify what we're discarding: Set log level to DEBUG in Preferences -> Nodes.

Then filter the log as follow:

~ $ tail -f /var/log/opensnitchd.log | grep -B 5 "no inodes found"

You should see messages like this one:

[2023-01-22 22:32:30]  DBG  new connection udp => 42730:192.168.160.1 -> 239.255.255.250:3702 uid: 103
[2023-01-22 22:32:30]  DBG  netlink socket error: Warning, no message nor error from netlink, or no connections found - 42730:192.168.160.1 -> 239.255.255.250:3702
[2023-01-22 22:32:30]  DBG  Searching for udp6 netstat entry instead of udp
[2023-01-22 22:32:30]  DBG  <== no inodes found for this connection.

If you identify the destination protocol:ip:port, you can add a rule to the fw to bypass that connection in /etc/opensnitchd/system-fw.json:

            "Rule": {
                "Description": "Allow minecraft", 
                "Table": "mangle",
                "Chain": "OUTPUT",
                "Parameters": "-d 224.0.2.0/24",
                "Target": "ACCEPT", 
                "TargetParameters": ""
            }

[petterreinholdtsen]

[Gustavo Iñiguez Goia]

If you identify the destination protocol:ip:port, you can add a rule to the fw to bypass that connection in `/etc/opensnitchd/system-fw.json`:

I used tcpdump and wireshark to identify what I believe is the announcement. It is a UDP package to 224.0.2.60 port 4445. Any idea why this do not show up as a interactive popup?

…

-- Happy hacking Petter Reinholdtsen

[gustavo-iniguez-goya]

If it's UDP, then probably because you are using "proc" monitor method.

Get the eBPF modules from here: https://github.com/evilsocket/opensnitch/actions/runs/3859316337

For kernels >= 5.19, 1.5.0 branch: https://github.com/evilsocket/opensnitch/suites/10231001363/artifacts/501509878
For kernels < 5.19, 1.5.0 branch: https://github.com/evilsocket/opensnitch/suites/10231001363/artifacts/501509880

And change proc monitor method to eBPF.

[gustavo-iniguez-goya]

ops, btw, the modules goes under /etc/opensnitchd/ directory (for example /etc/opensnitchd/opensnitch.o).

[petterreinholdtsen]

[Gustavo Iñiguez Goia]

If it's UDP, then probably because you are using "proc" monitor method.

I am, because we were so far unable to get the build for the eBPF to work when building the Debian package. Why is the proc monitor method ignoring and blocking UDP packages?

Get the eBPF modules from here: https://github.com/evilsocket/opensnitch/actions/runs/3859316337 For kernels >= 5.19, 1.5.0 branch: https://github.com/evilsocket/opensnitch/suites/10231001363/artifacts/501509878 For kernels < 5.19, 1.5.0 branch: https://github.com/evilsocket/opensnitch/suites/10231001363/artifacts/501509880 And change proc monitor method to eBPF.

I prefer to build such binaries from source. I guess it is time to focus on the eBPF build for the Debian package, then. :)

…

-- Happy hacking Petter Reinholdtsen

[gustavo-iniguez-goya]

I am, because we were so far unable to get the build for the eBPF to
work when building the Debian package. Why is the proc monitor method
ignoring and blocking UDP packages?

Usually because we're not able to obtain the path of the process. But being a UDP connection, enabling [x] Debug invalid connections should display a pop-up to allow/deny it.

If you can reproduce again the problem with log level in DEBUG , post the file /var/log/opensnitchd.log so I can analyze it.

Look for logs like: new connection.*445

[petterreinholdtsen]

[Gustavo Iñiguez Goia]

Usually because we're not able to obtain the path of the process. But being a UDP connection, enabling `[x] Debug invalid connections` should display a pop-up to allow/deny it.

Sadly it does not change anything.

If you can reproduce again the problem with log level in DEBUG , post the file /var/log/opensnitchd.log so I can analyze it. Look for logs like: `new connection.*445`

Switching to log level DEBUG did not cause any relevant messages to show up in /var/log/opensnitchd.log. Not sure why. The only message I got in that file when changing log level was telling that it failed to find the ebpf object file.

…

-- Happy hacking Petter Reinholdtsen

[gustavo-iniguez-goya]

fixed in v1.5.5

[petterreinholdtsen]

[Gustavo Iñiguez Goia]

fixed in v1.5.5

Is the fix in a9ce0d4? Will there be a popup in the default case, or do one need to enable the rather strange [x] Debug invalid connections option to be able to get this working? I had to set "InterceptUnknown": true in /etc/opensnitchd/default-config.json too to get the popup. During testing. Is this still needed? Will the 'proc' and 'ebpf' type behave differently here?

…

-- Happy hacking Petter Reinholdtsen

[gustavo-iniguez-goya]

Yes, eBPF detects those connections. As minecraft will be running when it sends the requests, we'll be able to get the path of the process.

In order to see these short-lived connections users will have to enable that option. Just changing it from the GUI is enough, no need to change the .json manually. We've never had a report stating that the GUI didn't update the configuration.

Enabling by default that option has undesired effects, because sometimes there're spurious packets that confuse users. In fact the option was named "Intercept unknown connections" (because the process path was unknown), making the things worse, because some users thought that something bad was happening.

This particular problem (short-lived connections/processes) was improved on 1.6.x versions with eBPF.