source IP 8.8.8.8 in OUTPUT chain

[themighty1]

@gustavo-iniguez-goya , I noticed occasionally there are connections in func newConnectionImpl
like this:

new connection tcp => 50410:10.70.155.65 -> 8.8.8.8:53

followed by this problematic connection:

new connection tcp => 53:8.8.8.8 -> 10.70.155.65:50410

coming from /usr/lib/systemd/systemd-resolved

How can the source be 8.8.8.8 ?

Note that this is TCP, not UDP, so it's definitely NOT coming from our iptables rule

INPUT --protocol udp --sport 53 -j NFQUEUE --queue-num 0 --queue-bypass

This connection is also present when I parse netlink.SocketsDump

&{2 2 1 0 {50410 53 10.70.155.65 8.8.8.8 0 [3314 0]} 1000 0 1 101 10496165}

Any thought are appreciated.

[gustavo-iniguez-goya]

Maybe due to intercept RELATED packages. Remove it from firewall/rules.go:
https://github.com/evilsocket/opensnitch/blob/master/daemon/firewall/rules.go#L102

and see if you reproduce it.

Anyway, there're many packets that we intercept even without RELATED. TCP_FIN states, etc... no idea why (for example when connecting/reconnecting from a WIFI, or when coming back from suspend state)

[themighty1]

I now know what was going on there, I was getting DNS responses from out INPUT rule in onPacket()
For some reason they were misformatted, so
dns.TrackAnswers(packet.Packet)
was not recognizing them and returning false and so those packets made their way into conman.Parse()

I think we should avoid any similar confusion in the future and have 2 netfilter queues - 1 for DNS responses, another one for all OUTPUT connections.

[gustavo-iniguez-goya]

This is worth debugging. If you can reproduce it easily you can sniff traffic to/from that port and analyze the response, and strace /usr/lib/systemd/systemd-resolved, besides adding some Println() in TrackAnswers()

Did you try to add an additional rule for TCP packets coming from port 53? iptables -I INPUT -p tcp --sport 53 -j NFQUEUE --queue-num 0 --queue-bypass

systemd-resolved seems to be common on ubuntu and derivatives.

[themighty1]

strace()ing helped. Turns out resolved starts a TCP Fast Open connection
tcp => 50410:10.70.155.65 -> 8.8.8.8:53
and gets a response
tcp => 53:8.8.8.8 -> 10.70.155.65:50410

But neither of those packets are shown in wireshark. Which I assume to mean that the packet never leaves the machine. I also assume that the response is crafted inside the kernel with a spoofed IP.