Can't connect to NFS share while enabled

[Natrinicle]

Hi there, love the project so far but I seem to have hit a bug that's a show stopper for me.

While OpenSnitch is enabled I'm unable to connect to my NFSv4 server. If I have a previously open connection before I start OpenSnitch it seems to mark it as related and doesn't block it but if I start OpenSnitch before connecting it's unable and times out. This is despite having a rule for all traffic to that host as allowed.

1. Create an NFSv4 server on the network, mount this NFS share locally.

2. This is my sanitized /etc/systemd/system/mnt-tank.mount that I use to mount on my local machine.

[Unit]
Description=<hostname>:/mnt/tank nfs mount script
After=network-online.service
Wants=network-online.service

[Mount]
What=<hostname>:/mnt/tank
Where=/mnt/tank
Options=rw,vers=4.2,rsize=1048576,wsize=1048576,timeo=3,retrans=5
Type=nfs
TimeoutSec=30

[Install]
WantedBy=multi-user.target

3. The OpenSnitch rule is allow to forever.

4. To bring up the mount, run systemctl start mnt-tank.mount

OS (please complete the following information):

• OS: Debian GNU/Linux
• Window Manager: KDE
• Kernel version: 5.10.0-8-amd64
• Version: Testing (Bookworm)

Client & Server:
nfs-kernel-server: 1:1.3.4-6

[gustavo-iniguez-goya]

Thank you for reporting this issue @Natrinicle , I'll try to reproduce it.

Do you have the option Debug invalid connections checked under Preferences->Nodes? If not, check it please and let me know if opensnitch prompts you to allow or deny an "Outgoing connection".

[Natrinicle]

I did not originally, went in and turned Debug invalid connections on, unmounted the NFS share with OpenSnitch disabled, then remounted with OpenSnitch enabled and there are no additional connection prompts nor denied events in the events tab.

[gustavo-iniguez-goya]

Ok, thank you.

I've got good news and bad news:

• The good news:

The change #493 to intercept WireGuard connections #454 also allow us to intercept NFS connections (as well as ip tunnels #500):

Once allowed the share is mounted properly.

• The bad news:

It's something really new, not tested and only for x86_64. But as far as I can tell, it works well on 5.10.x kernels.

For now you'll have to exclude those connections by adding a system rule to /etc/opensnitchd/default-config.json:

        {
            "Rule": {
                "Description": "Allow nfs", 
                "Table": "mangle",
                "Chain": "OUTPUT",
                "Parameters": "-p tcp --dport 2049",
                "Target": "ACCEPT", 
                "TargetParameters": ""
            }
        },

[Natrinicle]

Woot! Thank you for the quick workaround! :)

[ahilwers]

Hi!

I have the same problem since the last update of opensnitch-git on arch (opensnitch-git 1.4.0.r3.c66d5d6-1). I used the workaround and it seemed to work very fine. But after a few minutes I wasn't able to access my nfs mounts anymore. I get no error in the log file even if I enable the "Debug invalid connections" checkbox. At the moment nfs only works for me when opensnitch is completely disabled. I would provide you with more information but unfortunately there is none - no error messages, no log entries - just a timeout while trying to mount.

[gustavo-iniguez-goya]

Hi @ahilwers,

Do you have a system rule like the one posted above added? If so, could you check if it's actually added?

iptables -t mangle -L opensnitch-filter-OUTPUT

[Natrinicle]

On my system I found the SystemRules in the file /etc/opensnitchd/system-fw.json instead of the file /etc/opensnitchd/default-config.json that @gustavo-iniguez-goya mentioned previously. Added the Rule to system-fw and restarted OpenSnitch which added the rule to iptables

$ iptables -t mangle -L opensnitch-filter-OUTPUT
Chain opensnitch-filter-OUTPUT (1 references)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:nfs

Once that happened I was able to un and re-mount the share.

I forgot about this caveat while I was thanking @gustavo-iniguez-goya earlier but since you're still having problems getting outbound connections I'm wondering if you added the rule to the other file @ahilwers?

[Zweihander-Main]

Same problem with CIFS. Workaround also works. Using the Arch package:

1. Edit /etc/opensnitchd/system-fw.json and add:

{
    "Rule": {
        "Description": "Allow cifs",
        "Table": "mangle",
        "Chain": "OUTPUT",
        "Parameters": "-p tcp --dport 445",
        "Target": "ACCEPT",
        "TargetParameters": ""
    }
}

2. Restart opensnitch:

# systemctl restart opensnitchd.service

3. Check iptables:

# iptables -t mangle -L opensnitch-filter-OUTPUT
...
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:microsoft-ds

[ahilwers]

After applying the changes to the system-fw.json like @Natrinicle mentioned, it works now! Thank you all for your help!

[3vi1]

I only recently (within the last month or so) updated my opensnitch and was pulling my hair out looking for an NFS problem until I figured this out by disabling opensnitch.

[gustavo-iniguez-goya]

do you mean @3vi1 that opensnitch doesn't ask you to allow or deny the NFS connection? With latest v1.5.0 it should ask you to allow a "Kernel connection" (with the new eBPF module).

I'm interested in knowing more about that problem, because I tested it and should work, but maybe there're other use cases that I didn't test.

The eBPF module should have this symbol:

$ objdump -h /etc/opensnitchd/opensnitch.o |grep iptunnel
  7 kprobe/iptunnel_xmit 00000408  0000000000000000  0000000000000000  00000e90  2**3

[3vi1]

@gustavo-iniguez-goya: It looks like I'm only running 1.5.0rc2 and probably need to update. I never got prompted to allow the NFS connection with my current version. I fixed NFS by adding the rule manually to system-fw.json, as others had done. After that it worked immediately. The next day I did get prompted to allow a "Kernel connection"... but I'm not sure if it was related.

[gustavo-iniguez-goya]

Thank you @3vi1 , yes, that "Kernel connection" probably would be the NFS connection. That means that at least you have the correct eBPF module.

If you delete the rule from system-fw.json should work as well, otherwise it's a bug. You can review what connections accepted that "Kernel connection" rule by going to the Rules tab and double clicking on it.