VPN doesn't work with opensnitchd most of the time [wireguard, iptables]

[chicagoo17]

Hi there, only started my journey in linux and maybe just don't understand something.

My wireguard vpn doesn't work sometimes (sometimes if I turn on vpn after opensnitchd it works, around 30% cases) when opensnitchd runs.

That seems to be because of an iptables rule:
-A INPUT -p udp -m udp --sport 53 -j NFQUEUE --queue-num 0 --queue-bypass

If I delete this rule everything works fine, but I didn't manage to fully understand what it does.
If it matters, my wireguard .conf uses "DNS = 10.0.0.1" (and IPv6 address).
I don't quite understand where to see logs of wireguard or opensnitch for this (I couldn't find this) so just asking.

Questions:
1. What is the purpose of this iptables rule above?
2. Is it safe for my safety and privacy to delete this rule?
3. Do I need to configure my vpn to bypass this?
4. By the way what do these lines mean? It's from /var/log/opensnitchd.log
Error while pinging UI service: rpc error: code = DeadlineExceeded desc = context deadline exceeded, state: READY
[date and time] ERR getting notifications: rpc error: code = Unavailable desc = transport is closing
[date and time]] WAR Error while pinging UI service: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /tmp/osui.sock: connect: connection refused", state: TRANSIENT_FAILURE

[chicagoo17]

@gustavo-iniguez-goya Could help me please? Answerting first three questions.

[gustavo-iniguez-goya]

Hi @chicagoo17 !

First things firsts, could you tell us the opensnitch version and GNU/Linux distribution you're using?
Also post the output of iptables -V please.

I don't quite understand where to see logs of wireguard or opensnitch for this (I couldn't find this) so just asking.

You can set log level to DEBUG (GUI -> Preferences -> Nodes) and monitor the log file /var/log/opensnitchd.log. It'd be useful to take a look at it.

1. What is the purpose of this iptables rule above?

To intercept DNS responses, so we can keep a cache of known IP-host list. If a new process tries to establish a connection to an IP and it's in the cache, we display the host instead of the IP (which is anyway shown on the popups).

2. Is it safe for my safety and privacy to delete this rule?

Yes, you can delete the rule, it won't affect the interception of outbound connections. But we check every 30s if that rule is added, and if it's not present we add it again (it's pretty common to disable fw rules once you get access to a system).

3. Do I need to configure my vpn to bypass this?

Actually, this is the first time I see this problem, so I can't tell you for now.

4. By the way what do these lines mean? It's from /var/log/opensnitchd.log
   Error while dialing dial unix /tmp/osui.sock: connect: connection refused"

It seems that the daemon cannot connect to the GUI. Could you verify that the file /tmp/osui.sockexists? Do you have any services that clean ups /tmp/periodically? (like tmpreaper)

[pizzadude]

I have the same problem with the latest release candidate. Fedora 34, which uses nftables & firewalld frontend. Default action on GUI is allow, default action in nodes is deny. I can't connect to my VPN with the firewall enabled.

Had to downgrade to 1.3.6.

Edit: By checking "Intercept Unknown Connections", I am able to allow the wireguard vpn connection with opensnitch.

[gustavo-iniguez-goya]

@pizzadude could you post the output of nft list ruleset?
Also, does opensnitch ask permission to allow the VPN or it doesn' event detect it?

[pizzadude]

nft-ruleset.txt

Attached is output of "nft list ruleset".

Without applying the workaround, latest opensnitch does not detect the VPN at all, and silently blocks it. It could be the fact that there is no process ID for wireguard, as it uses a kernel module.

I worked around this issue by checking "Intercept Unknown Connections" in opensnitch, and allowing the wireguard port 51820 in opensnitch.

[gustavo-iniguez-goya]

mm. I think that this issue is caused by 1) 21c6a91 and 2) da23c82, mainly by 1).

If the daemon and GUI default action is deny, then I think this is the correct behaviour.

By the way, I don't see our rules in the nft output. There should be 2 tables called opensnitch-filter and opensnitch-mangle for ip and ip6.

[pizzadude]

For some reason, opensnitch rules are not added. Maybe it's because Fedora uses firewalld on top?

[gustavo-iniguez-goya]

They should coexist I guess. I haven't tested it with firewalld.

With iptables everyone added the rules to the hardcoded tables nat, mangle, etc. But with nftables you can name the tables as you wish, what makes me wonder what table has priority if different firewalls create same chains (like opensnitch -> { mangle, nat, ...} and firewalld -> { mangle, nat, ... }) . Maybe it's checked in alphabetical order.

"Convention is though to use the iptables names by default", I'll change the tables for the next release, but I don't think firewalld is following that "convention".

Anyway, if the daemon is intercepting connections then our rules are added.

[pizzadude]

Opensnitch seems to be working, despite the VPN problem and the ICMP (can't ping) problem, even though the rules didn't show up.

Testing with "curl https://google.com" shows that opensnitch is intercepting connections fine.

[pizzadude]

I also have the iptables command.

If I do " sudo iptables --list-rules " I found a rule:

"-A INPUT -p udp -m udp --sport 53 -j NFQUEUE --queue-num 0 --queue-bypass"

is that the opensnitch rule?

[gustavo-iniguez-goya]

mm, yes, could you post the output of iptables -V ?

[pizzadude]

I figured out why the rules were showing up in iptables, and not nftables.

I had iptables-legacy installed. I uninstalled iptables-legacy, and the iptables command now points to "/usr/sbin/iptables-nft".

Now the opensnitch rules show up in nftables.

I still have the same issues though, but at least that mystery is solved.

[gustavo-iniguez-goya]

aah ok, I was also mixing up different issues.

[gustavo-iniguez-goya]

Confirmed that we don't intercept the process name that establishes the wireguard tunnel (nor even by using ebpf):

[2021-07-20 16:57:14]  DBG  new connection udp => 58726:192.168.1.78 -> 192.168.1.103:61000 uid: 4294967295
[2021-07-20 16:57:14]  DBG  [0/1] outgoing connection: 58726:192.168.1.78 -> 192.168.1.103:61000 || netlink response: 58726:0.0.0.0 -> 0.0.0.0:0 inode: 107253043 - loopback: false multicast: false unspecified: true linklocalunicast: false ifaceLocalMulticast: false GlobalUni: false 
[2021-07-20 16:57:14]  DBG  GetSocketInfo() invalid: 58726:0.0.0.0 -> 0.0.0.0:0
[2021-07-20 16:57:14]  DBG  netlink socket not found, adding entry:  58726:192.168.1.78 -> 192.168.1.103:61000 || 58726:0.0.0.0 -> 0.0.0.0:0 inode: 107253043 state: close
[2021-07-20 16:57:14]  DBG  [0/1] outgoing connection: 58726:192.168.1.78 -> 192.168.1.103:61000 || netlink response: 58726:0.0.0.0 -> 0.0.0.0:0 inode: 107253043 - loopback: false multicast: false unspecified: true linklocalunicast: false ifaceLocalMulticast: false GlobalUni: false 
[2021-07-20 16:57:14]  DBG  GetSocketInfo() invalid: 58726:0.0.0.0 -> 0.0.0.0:0
[2021-07-20 16:57:14]  DBG  netlink socket not found, adding entry:  58726:192.168.1.78 -> 192.168.1.103:61000 || 58726:0.0.0.0 -> 0.0.0.0:0 inode: 107253043 state: close
[2021-07-20 16:57:15]  DBG  new pid lookup took (-1): 331.090425ms

At least we're able to intercept the ougoing connection. @chicagoo17 see if activating the option "Unknown connections" you're prompted to allow the outgoing connection (Preferences -> Nodes)

[jdk32f2]

I'm having issues with Wireguard too, Opensnitch just blocks it without prompting for user action, I'm using the VPN provider custom app, OpenVPN works fine with Opensnitch but Wireguard does not.

• Opensnitch v1.4.0-rc.4
• iptables v1.8.7 (nf_tables)
• Ubuntu 21.04 64-bit

[gustavo-iniguez-goya]

Hi @jdk32f2 , did you enable [x] Debug invalid connections, under Preferences -> Nodes?

It should prompt you to allow an outgoing connection. If not, post your WireGuard configuration. By the way, using eBPF or proc monitor method?

[jdk32f2]

Hi, that worked, I got a prompt to the server IP and I allowed it, I'm using eBPF. I didn't realize the name was changed I was looking for "Unknown connections" based on your old comment and couldn't find it.

So I'm assuming it is safe now to disable the debug invalid connections option, since I see the IPs got whitelisted.

So why does this happen with Wireguard and not Openvpn?

Also off-topic but my opensnitch logs are being blasted nonstop with
WAR ebpf warning: eBPF packet with unknown source IP: 192.168.8.1any idea how to figure out what's going on?

[gustavo-iniguez-goya]

So why does this happen with Wireguard and not Openvpn?

The problem is that WireGuard connections are initiated from kernel-space, so there's no really a process that's initiating it (I haven't analyzed this but I guess that user-space tools will tell the kernel module to open the connection). OpenVPN on the other hand doesn't have a kernel module, so the connections are initiated from user-space.

WAR ebpf warning: eBPF packet with unknown source IP: 192.168.8.1any idea how to figure out what's going on?

That log indicates that the IP is not an IP of the system (as seen by ip a), usually those are connections that are traversing the box.

[gustavo-iniguez-goya]

I've added the solution of this issue to the FAQs https://github.com/evilsocket/opensnitch/wiki/FAQs

[Shadow505]

@gustavo-iniguez-goya

Hi,

the issue with this is that it makes it very difficult to create proper rules. For example, you need to whitelist every single IP of the VPN provider that you're connecting to since you cannot just whitelist the application (because opensnitch can not determine it).

If there is no way to fix this in a way that would make it possible for OpenSnitch to determine the actual process, it would be helpful to implement a "Comment" field so that you have at least an overview as to what IP belongs to what application. When the popup opens that asks you to Allow/Disallow the connection, there should be a "Comment" field. That field should afterwards be visible in the rules list.

[gustavo-iniguez-goya]

If there is no way to fix this in a way that would make it possible for OpenSnitch to determine the actual process, it would be helpful to implement a "Comment" field so that you have at least an overview as to what IP belongs to what application. When the popup opens that asks you to Allow/Disallow the connection, there should be a "Comment" field. That field should afterwards be visible in the rules list.

Yeah, for now there's no fix for this scenario. Adding a Description/Comment field to the rules was also suggested by NRGLine4Sec on another issue, and I think that it'd be useful. But I think that the pop-up dialog is already quite complex, so I'd prefer to leave it as it's now.

[gustavo-iniguez-goya]

By the way, I'm playing with a kernel module to initiate connections from kernel space, and at least in this scenario, we're able to intercept the process:

[jdk32f2]

By the way, I'm playing with a kernel module to initiate connections from kernel space, and at least in this scenario, we're able to intercept the process:
![image](

Interesting, did you modify something in opensnitch and it was able to intercept this module, or is this working on the current version of opensnitch?

[Shadow505]

By the way, I'm playing with a kernel module to initiate connections from kernel space, and at least in this scenario, we're able to intercept the process:

So, with that kernel module it would be possible to determine the actual process for wireguard connections?

[gustavo-iniguez-goya]

Interesting, did you modify something in opensnitch and it was able to intercept this module, or is this working on the current version of opensnitch?

It's working with latest RC. If you use the "proc" monitor method you'll see the "unknown process" pop-up, but if you use "ebpf" then we're able get the process in this particular case.

So, with that kernel module it would be possible to determine the actual process for wireguard connections?

No, no. I meant that we're able to intercept connections initiated from kernel space, including the name of the process that initiated them (it wasn't obvious if we were able to do this, or if the "unknown connections" + eBPF were always kernel connections).

Anyway, I think I've got something interesting.

I've realized that the WireGuard lkm uses setup_udp_tunnel_sock() and udp_socket_create4()
https://github.com/WireGuard/wireguard-linux/blob/e4f8712df32a756712f36aeb32eafd3d8a6a43a1/drivers/net/wireguard/socket.c#L386
https://github.com/WireGuard/wireguard-linux/blob/e4f8712df32a756712f36aeb32eafd3d8a6a43a1/drivers/net/wireguard/socket.c#L407

I've modified the script udplife.bt to intercept those functions, and now when setting up a WireGuard tunnel it intercepts the PID and COMM of the process that initiates the tunnel.

# bpftrace /tmp/udplife.bt 
Attaching 10 probes...
PID   COMM       LADDR           LPORT RADDR           RPORT   TX_B   RX_B MS
  >>> udp_sock_create4, pid: 1027733, comm: ip, parent comm: wg-quick
  +++ setup_udp_tunnel_sock: 1027733, comm: ip
  +++ setup_udp_tunnel_sock: 1027733, comm: ip
^C

hooking udp_tunnel_xmit_skb reveals that the connection is being processed by a kernel thread:

udp_tunnel_xmit_skb: 1073889, kworker/u16:0

All other procfs fields are empty (cmdline, environ, fd/*, etc)

I can also see that there's a process with the following comm

# cat /proc/1027739/comm 
wg-crypt-wg0

however I've been unable yet to relate it with any connection. @themighty1 what do you think, could we add these functions to the ebpf module? udp_socket_create4(), udp_socket_create6().

[themighty1]

@gustavo-iniguez-goya , hi, I don't think, I'll have the time to work on this but generally, I think it is a direction worth researching.

[gustavo-iniguez-goya]

There's some progress on this:

#493

[mcilloni]

Sorry, I noticed that I forgot to update my /etc/opensnitchd/opensnitch.o to the latest version - after building and copying the new binary and restarting opensnitchd kernel connections finally started showing up correctly. Thanks anyway for your reply!

[gustavo-iniguez-goya]

I guess I should put a note somewhere :)

[chriscz]

I seem to be running into a similar issue. It started happening recently, possibly after an update to Fedora 36.

After enabling "Debug invalid connections" I also see the KIPI Plugins pop-up whenever I try to connect with Mullvad.

I have tried completely removing opensnitch (checked no /etc/opensnitchd/*.o) and re-installing via the rpm packages.

The last print-out of my logs show the following when the connection starts with mullvad

[2022-09-07 13:31:41]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:42]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:44]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:48]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8

Then whenever I click always allow for this executable I see the error with the rule:

[2022-09-07 13:31:50]  WAR  Error while asking for rule: rpc error: code = Internal desc = Failed to serialize response! -  (0) -> 146.70.132.226:14709 (proto:udp uid:0)
[2022-09-07 13:31:50]  ERR  Invalid rule received, applying default action
[2022-09-07 13:31:51]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:52]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:54]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:31:58]  WAR  ebpf warning: eBPF packet with unknown source IP: 8.8.8.8
[2022-09-07 13:32:02]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:32:03]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:32:05]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:32:09]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1

When I allow just for the port, instead of the executable then I see:

[2022-09-07 13:37:51]  IMP  Added new rule: allow if dest.port is '35049'
[2022-09-07 13:37:52]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:37:53]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:37:55]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1
[2022-09-07 13:37:59]  WAR  ebpf warning: eBPF packet with unknown source IP: 192.168.50.1

@gustavo-iniguez-goya I can share my mullvad key if you want to try and reproduce it.

[chriscz]

I forgot to mention the system details, but I'm running the latest releases of everything:

• Fedora 36
• Mullvad VPN 2022.2 / 2022.4
• Kernel Linux 5.19.6-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 31 17:58:15 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
• Opensnitch 1.5.2

[chriscz]

Please, post the output of the following command: objdump -h /etc/opensnitchd/opensnitch.o | grep tunnel

  7 kprobe/iptunnel_xmit 00000408  0000000000000000  0000000000000000  00000e90  2**3

[pizzadude]

@chriscz
Try this ( like I mentioned in #731 )

Step 1. Set Mullvad Wireguard port to 51820

Step 2. Do what I did in this image:

Step 3. Edit /etc/opensnitchd/system-fw.json and change "tcp" to "udp" for the "wg udp" rule you just added.

[chriscz]

Brilliant, that worked for me. Thank you @pizzadude!

[gustavo-iniguez-goya]

🚀 @pizzadude I'll buy 1 month of mullvad to see if I can reproduce this behaviour and try to fix it.

[gustavo-iniguez-goya]

@pizzadude @chriscz what options do you have configured under Mullvad -> Advanced? and what tunnel protocol options (ipv4/ipv6, udp/tcp, port, etc)?

[pizzadude]

@gustavo-iniguez-goya
Mullvad -> Advanced:
Enable IPv6: Disabled
Always require VPN: Disabled
Tunnel protocol: WireGuard
Wireguard settings: Port 51820
IP version: Automatic (it uses IPv4)
Use custom DNS server: Enabled

Also Mullvad uses UDP by default.

Also, it should be worth noting that this only started happening after the kernel update in Fedora 36 to kernel version 5.19.x

In kernel 5.18.x and below I could just allow it via an opensnitch regular rule.

[gustavo-iniguez-goya]

ok, that's good to know. I'll try to reproduce it with kernel the 5.19

[gustavo-iniguez-goya]

ok, reproduced with kernel 5.19. I'll investigate why these connections are not intercepted.

[update] nice, the iptunnel_xmit hook is working (so we don't have to update the ebpf module):

+++ iptunnel_xmit: 3188, kworker/u2:3
	_saddr: 192.168.1.106, _daddr: 185.65.135.70, 

If you select Advanced -> Tunnel protocol -> openvpn, does it connect to their servers?

[pizzadude]

OpenVPN works fine, I get an opensnitch popup asking me to allow it and it works.

[gustavo-iniguez-goya]

ok, this problem can solved by recompiling the eBPF module against latest sources of your kernel, in this case 5.19.

Following these steps https://github.com/evilsocket/opensnitch/blob/master/ebpf_prog/README but changing 5.8 by 5.19

[pizzadude]

Recompiling the eBPF module against kernel 5.19.x fixed it, no need for my workaround anymore. Thanks!

[squalou]

Hi,

I'm jumping on this thread since I just discovered I'm facing the same issue with wireguard (custom hosted server) and kernel 5.19

I did try to compile as instructed buth then I'm getting this error when trying to start opensnitchd

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x6798c6]

goroutine 1 [running]:
github.com/evilsocket/opensnitch/daemon/vendor/github.com/iovisor/gobpf/elf.(*Module).UpdateElement.func1(0x0, 0xc0015d6030, 0xc0015d6038, 0x0, 0xc001411e30)
	github.com/evilsocket/opensnitch/daemon/vendor/github.com/iovisor/gobpf/elf/table.go:74 +0x26
github.com/evilsocket/opensnitch/daemon/vendor/github.com/iovisor/gobpf/elf.(*Module).UpdateElement(0xc00142c7e0, 0x0, 0xc0015d6030, 0xc0015d6038, 0x0, 0xc0014b53e0, 0xae3c60)

etc...

kernel is 5.19.0-76051900-generic
OS is pop OS 22.04

I did not try to completely reboot, only tried a systemctl stop then start (either with systemctl or sudo opensnitchd with suggested options)

Any idea what may be failing ?

[gustavo-iniguez-goya]

what opensnitch version are you using @squalou ? v1.5.2?

[squalou]

didn't check, apparently it's labeled 1.5.0.rc1 in the UI
I feel ashamed : I don't even remember how I installed it. Running popOS right now.
(I left my Arch linux for business reasons, I miss it so much, since then I'm lost in versioning and repos and updates not up to dates :-) )

I could probably build 1.5.2 locally if it is required

edit : I probably instaled it manually from a .deb somehow

opensnitch/now 1.5.0~rc1-1 amd64 [installed,local]
  GNU/Linux firewall application

python3-opensnitch-ui/now 1.5.1-1 all [installed,local]
  opensnitch application firewall GUI

edit 2
Just upgraded to 1.5.2

Still the same error after compile / cp to /etc

But, the workaround with InterceptUnknown : true works , provided I add a rule to authorize my wireguards servers (they have fixed IP so I can do it)

Don't bother, I bet there will be a working fix one day, until then the workaround seems fine

[gustavo-iniguez-goya]

I think that the segfault is caused for using v1.6.0 ebpf module with daemon v1.5.0, could you confirm that you compiled the ebpf module from v1.5.0 branch? https://github.com/evilsocket/opensnitch/tree/1.5.0/ebpf_prog

Or post the full stacktrace.

I'm trying to make it work for > 5.19 and <= 5.18, but no luck for now.

[squalou]

You're right : I did use master branch !
Works like a charm now. I feel ashamed,I should have paid attention.

Thank you again ! (for this answer and for the work on opensnitch in general)

And good luck... (maybe the best approach would be to set 5.19 as a prerequisite to version 1.6.0)

[gustavo-iniguez-goya]

no problem @squalou :)

The problem is something expected: we're reading sk_buff struct to extract tunnels parameters (vpn, nfs, smb, etc), but it's not a stable interface, so it may change from kernel to kernel, leading to these kind of errors.

If I'm not wrong, the (correct) way of solving this problem is by updating the ebpf module to be bpf CO:RE compatible. I've tried it but still it doesn't work, but probably I'm doing something wrong.

Other options:

• Create a package that compiles the ebpf module whenever a new kernel is installed, like what dkms does.
• Provide 2 ebpf precompiled modules, for < 5.19 and >= 5.19. The easiest and fastest workaround, but we may have the same problem in the future though.
  The packages could install the modules to /etc/opensnitchd/ebpf/, and link /etc/opensnitchd/opensnitch.o to the proper module for the running kernel.

[gustavo-iniguez-goya]

hey folks, @pizzadude

I've created a github action to compile the modules manually, or whenever a change to the modules is pushed.
The Action publishes the modules for several kernels and branches, so this task does not depend on me anymore (which is good for transparency, if you trust the CI environment, m$, etc).

I've reproduced the scenario where the VPN connections weren't intercepted, then downloaded the compiled module for 1.6.0rc2 + kernel 5.19, replaced it with the one installed, restart the daemon and the VPN connections were intercepted again.
So if this problem happens again, at least we can add the problematic kernel, download the module and give it a try.

The artifacts are at the bottom of the page:
https://github.com/evilsocket/opensnitch/actions/runs/3190645548

[pizzadude]

Nice.

[gustavo-iniguez-goya]

hey all,

I've changed the way we compile the ebpf modules: #942

Could you test the precompiled binaries (or compile them by yourself) and let me know if they work on your systems? As far as I can tell, they work fine intercepting VPNs/cifs/nfs/ksmbd/etc.

Thank you!

[pizzadude]

I compiled using the new method earlier and it works fine.

[gustavo-iniguez-goya]

thank you!

[ghost]

hello, i would like to know if there are any issues when using a kernel with lockdown=confidentiality enabled (which in effect disables bpf). I noticed that my wireguard tunnel gets blocked and no popup shows for the connection.

[gustavo-iniguez-goya]

Yes @schiavonedimitri , opensnitch needs ebpf to intercept the VPN outgoing connection.
See if by enabling [x] Debug invalid connections under Preferences -> Nodes prompts you to allow an outgoing connection. Then you can filter by IP+port.

Another option would be to add a nftables rule to exclude outgoing traffic to the VPN port (Firewall -> Allow service (out)).