AF_PACKET IPS mode NOT copy tcp ack packet to another I/F

Hello !

I have trouble with Suricata IPS in Af-packet mode. It looks like Sricata does not copy received tcp ack packet to corresponding I/F.
So Tcp connection is time out!

I’s working on Ubuntu 22.04 with 2 NIC and using Af-Packet, and this issue reproduce on other machine on 20.04.

  • My network layout is:
    Server(192.168.0.138.2222) ----- (I/F: enp2s0f0)Suricata(I/F: enx788cb5abe8fa) ----- Client(192.168.0.183)

■UDP packets and ICMP have no problem like below.
$ sudo tcpdump port 123 -i enp2s0f0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:23:25.403129 IP 192.168.0.183.49100 > time3.google.com.ntp: NTPv4, Client, length 48
20:23:25.444371 IP time3.google.com.ntp > 192.168.0.183.49100: NTPv4, Server, length 48

$ sudo tcpdump port 123 -i enx788cb5abe8fa
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enx788cb5abe8fa, link-type EN10MB (Ethernet), capture size 262144 bytes

20:23:25.402862 IP 192.168.0.183.49100 > time3.google.com.ntp: NTPv4, Client, length 48
20:23:25.444650 IP time3.google.com.ntp > 192.168.0.183.49100: NTPv4, Server, length 48

■Tcp syn/ack packets are not copied to corresponding I/F like below:
$ sudo tcpdump port 2222 -i enp2s0f0 ←Outbound I/F received ack packet
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:20:55.425096 IP 192.168.0.183.webmin > 192.168.0.138.2222: Flags [S], seq 4063061034, win 1024, options [mss 1460], length 0
20:20:55.425537 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0
20:20:55.520644 IP 192.168.0.183.webmin > 192.168.0.138.2222: Flags [S], seq 4062995499, win 1024, options [mss 1460], length 0
20:20:55.521026 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [.], ack 1, win 29200, length 0
20:20:56.423926 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0
20:20:58.423939 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0
20:21:02.423871 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0
20:21:10.423875 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0
20:21:26.423893 IP 192.168.0.138.2222 > 192.168.0.183.webmin: Flags [S.], seq 820533115, ack 4063061035, win 29200, options [mss 1460], length 0

$ sudo tcpdump port 2222 -i enx788cb5abe8fa ←Inbound I/F does not seem copying ack packet and sending back to client.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enx788cb5abe8fa, link-type EN10MB (Ethernet), capture size 262144 bytes
20:20:55.424768 IP 192.168.0.183.webmin > 192.168.0.138.2222: Flags [S], seq 4063061034, win 1024, options [mss 1460], length 0
20:20:55.520377 IP 192.168.0.183.webmin > 192.168.0.138.2222: Flags [S], seq 4062995499, win 1024, options [mss 1460], length 0

■I will upload following commands output to assist troubleshooting.
$ suricata --build-info
$ sudo systemctl status suricata
$ sudo cat /etc/suricata/suricata.yaml
$ sudo less /var/log/suricata/suricata.log
$ ip addr
$ sudo tail /var/log/suricata/fast.log

Any idea how I could solve this problem?
command_output.log (116.5 KB)

Hi @Troy ! Welcome to our forum! :slight_smile:
Looking at your logs, I saw several exception policy logs. Are those intentional?
If not, please check out https://forum.suricata.io/t/my-traffic-gets-blocked-after-upgrading-to-suricata-7
Could you please try this and see if any issue is happening due to these policies being applied?

1 Like

Hi @sbhardwaj .

Looking at your logs, I saw several exception policy logs. Are those intentional?
No, not intentional.

Thanks to your advice, enabling drop logs showed “flow drop” and “stream midstream”.
So exception policies setting to ignore works for me for now!

Thanks a lot and have a nice day !

3 Likes