System hangs at login when Default Action set to Deny

[SimpleTechGuy]

Daemon related issues:

• Run opensnitchd -check-requirements to see if your kernel is compatible.
  ALL PASSED

Describe the bug
System hangs for 2 minutes after login. This was working fine until recent arch linux updates that came out near the end of October.

Include the following information:

• OpenSnitch version. -- 1.6.6-2
• OS: [Arch Linux x86_64]
• Version [n/a]
• Window Manager: [compiz (also tested with xfwm4 & openbox)]
• Kernel version: 6.11.7-arch1-1

To Reproduce

Steps to reproduce the behavior:
Set Preferences / Nodes / Default action when the GUI is disconnected / deny
Reboot
Login with a standard user
system hangs with delay for 2 minutes before desktop loads

Post error logs:
No errors logged, I was able to diagnose the issue after enabling debug mode and realized that localhost was getting blocked to itself early in the boot process.

If the daemon doesn't start or doesn't intercept connections:
N/A

If the deb or rpm packages fail to install:
N/A

Expected behavior (optional)
Desktop should load normally without 2 minute delay.

Screenshots
N/A

Additional context
N/A

[gustavo-iniguez-goya]

Maybe something related with latest changes hmm, I'll try to reproduce it.

[gustavo-iniguez-goya]

I've been unable to reproduce this issue. Not tested in Arch but in Manjaro with systemd 256-8-2, kde, xfce/xfwm and openbox.

Before login, truncate the log (~ $ sudo truncate -s0 /var/log/opensnitchd.log) and after the 2' delay copy the log and post it here.

These delays are usually caused by some binaries like dimngr or xbrlapi that establish connections to localhost.

You can also add a new rule to allow connections to localhost (or two, for ipv4 and ipv6) to see if that helps.

Note: v1.6.0 branch has received changes for on-exit events or functionality related to text fields. They should not affect in this scenario.

[SimpleTechGuy]

Thank you for following up. Unfortunately I am still experiencing the issue, however I was able to confirm that adding a rule (regular rule, not firewall rule) to allow localhost to itself did circumvent the 2 minute delay. Although it does remove the 2 minute delay, it still doesn't explain why it was unnecessary to have that rule prior to Octobers updates, which makes me wonder.....

Anyway, This is the only line from the log after login with the truncate. Note I had enabled default log level of IMPORTANT in Nodes Preferences.

[2024-12-05 00:21:26] IMP UI connected, dispathing queued alerts: 0

Notice the time is after the system resumes from 2 minute delay as referenced from journal entry below:

Dec 04 18:19:15 systemd-logind[2531]: Removed session 1.
Dec 04 18:21:18 systemd[3190]: Starting Virtual filesystem service...

Also maybe important and I forgot to mention in the original post but I am using ebpf module, however I did test with proc and had the same results.

[Eq1nimity]

Sorry, not entirely relevant, but throwing this out there since you are still having this issue in hopes by chance it helps resolve your issue.

I found this issue when I had the same thing a few weeks ago on my debian 12 system - a solid 2 minute hangup after login before loading the desktop environment.

Did you happen to do any other configurations with other firewall type programs? I realize this is a stretch, I was carelessly playing around with (not verifying system stability through restarts) a few different firewall type tools and what I incorrectly thought was OpenSnitch was actually a ufw config that I setup that was crippling my system in the same way you are describing.

When I removed the ufw misconfiguration, my system with OpenSnitch functioned fine; of course, not after a few hours of trying to figure out how OpenSnitch was causing the problem.

I subbed to follow back then, and since you are still having this issue, as silly as it is, I figured I would at-least throw it out there. In any case, good luck.

[SimpleTechGuy]

Hi @Eq1nimity, thank you for the suggestion! I do actually have other security applications on the system, but I've already gone through the process of checking those applications individually. I'm fairly confident at this point the issue is relevant here, however I'm also confident that it happened because of another applications update, just not sure which one. Currently going through the process of downgrading each application one at a time until I find the culprit. lol Hopefully it's just one.

Do you happen to remember what you did to the ufw config that caused the issue there? Since OpenSnitch is now using nftables then it may be relevant...

Also, At this point I'm pretty sure it's only affecting pure arch, which makes me wonder if it has something to do with a patch from the aur package specifically. It's strange that it affects Arch only though, but not Manjaro. I tested on EndeavourOS as well and it is not affected there either. Would be interested to know if it happens on other arch based distros.

[SimpleTechGuy]

Well now I'm really stumped. I installed a clean arch linux virtual machine and only installed opensnitch and it's not affected. So whatever is causing this problem must be some third party application I have installed on all my computers that is making localhost calls at user login.

Either way I'm going to keep hunting.

[Eq1nimity]

@SimpleTechGuy Hey, hope you are not losing too many hairs over there.

I just did ufw reset and uninstalled it. I don't recall what settings I had on with the issue.

The only other thing that I can think of that I did was I removed all the opensnitch rules I had set, reinstalled it, and I believe I left permissive "auto accept" on with a short timer, at-least through the first reboot, to make sure nothing was getting denied (as suggested in FAQ https://github.com/evilsocket/opensnitch/wiki/Known-problems )

I'm also on a debian 12 system, so I don't have any input for arch.

Good luck making some progress.

[SimpleTechGuy]

Thanks for the info @Eq1nimity -

I remember browsing through that article and thinking that it didn't apply to me because my system was able to boot normally with the option set to deny, but then it suddenly stopped working. I've gone through several of the 100 or so applications that were updated in October with no luck so far.

For now I guess the localhost rules are going to have suffice, but I'm going to keep troubleshooting this. Would like to keep the ticket open for a bit longer just in case I can pinpoint the issue specifically.

[gustavo-iniguez-goya]

hey @SimpleTechGuy , if you go to the Rules tab -> double click on the localhost rule and review the events, it should reveal the binary/app that is causing the problem.