[SOLVED] flushing conntrack (Accept Verdict don't preserve original packet mark)

[themighty1]

opensnitch doesn't flush conntrack table when it starts.
Does that mean that an already-established connection will bypass opensnitch? I think so.

[gustavo-iniguez-goya]

Yes, I think so too.

In part, I think that's why we get "unknown connections" (packets in "bad" state, i.e.: not syn, syn-ack) when disconnecting/reconnecting from the network.

[gustavo-iniguez-goya]

By the way, related to conntrack lists.. I thought in adding a window to monitor active connections, it's as simple as :

package main

import (
	"fmt"

	"github.com/vishvananda/netlink"
	"golang.org/x/sys/unix"
)

func main() {
	t, err := netlink.ConntrackTableList(1, unix.AF_INET)
	fmt.Printf("%v - %v\n", t, err)
}

polling every n seconds. But now that we're commiting to evilsocket's repo I'm more conservative adding new features, otherwise it'd have already added it.

[themighty1]

When opensnitch is running and I run "sudo conntrack -F", my Mullvad VPN blocks the internet. Only restarting opensnitch unblocks it.

[gustavo-iniguez-goya]

That's strange. If you are able to establish the connection, once you flush the active connections, the VPN should try to connect again once the timeout fires.

What kind of VPN is it? ipsec, openvpn, .. ? If the DefaultAction of the daemon is Deny, we could be blocking some protocol (AH/ESP for IPSEC, GRE for pptp/l2tp, etc).

The place to debug it should be here: https://github.com/evilsocket/opensnitch/blob/master/daemon/conman/connection.go#L99

[themighty1]

To test it and rule out any code paths, I just put at the top of func onPacket() in main.go

packet.SetVerdict(netfilter.NF_ACCEPT)
return

and did like I said in the comment above. The internet blocks.
I tried it both with Mullvad app's OpenVPN and with their wireguard options. Same result.

[gustavo-iniguez-goya]

I don't understand why the daemon is interfering after flushing out the conntrack table.

I've tried it out with other type of traffic (http/ftp downloads, video streaming, and f5 vpn), and in all cases the connections are reestablished.

Could it be a deadlock maybe? If internet is blocked even allowing everything in onPacket(), then take a look at queue.c (go_callback) and queue.h (nf_callback)

[themighty1]

I wanted to dig into this issue but I cannot reproduce it anymore. Flushing conntrack doesnt block the VPN anymore. (I may have restarted my machine a few times between now and when I first saw that behaviour).

[gustavo-iniguez-goya]

good news then!

[themighty1]

Turns out mullvad puts an nfmark on those packets which it sends from the kernel to their wireguard servers. That is why doing

packet.SetVerdict(netfilter.NF_ACCEPT)
return

does not preserve the nfmark
we should preserve the nfmark from the packet by doing

packet.SetVerdictAndMark(netfilter.NF_ACCEPT, packet.Mark)
return

This is most likely the solution why people have to stop opensnitch in order to let their VPN connections to be re-established.

[gustavo-iniguez-goya]

good catch @themighty1 , if you have tested it and it works, submit a PR.

[themighty1]

Submitted evilsocket#340
I've been using that patch for the last 24 hours.

[gustavo-iniguez-goya]

great, testing it now. I guess it's inocuous, but just in case anything arises.

[gustavo-iniguez-goya]

merged!