# Suricata on ipip tunneled packets **URL:** \ **Category:** Help\ **Created:** [September 10, 2024, 10:51am UTC](https://forum.suricata.io/t/suricata-on-ipip-tunneled-packets/4850 "2024-09-10T10:51:20Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![vseregin](https://avatars.discourse-cdn.com/v4/letter/v/35a633/32.png) [@vseregin](https://forum.suricata.io/u/vseregin)\ **Post date:** [September 10, 2024, 10:51am UTC](https://forum.suricata.io/t/suricata-on-ipip-tunneled-packets/4850/1 "2024-09-10T10:51:20Z")
Hi, team! We use suricata to catch packets on mirrored traffic. Due to service design packets in one direction encapsulated in ipip tunnel Frame 188: 984 bytes on wire (7872 bits), 984 bytes captured (7872 bits) Ethernet II, Src: 02:00:00:05:02:01 (02:00:00:04:02:01), Dst: MellanoxTech\_5d:ce:f2 (b8:ce:f6:5d:cb:f2) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100 Internet Protocol Version 4, Src: 10.0.200.7, Dst: 10.1.200.77 Internet Protocol Version 4, Src: 78.87.12.214, Dst: 15.73.19.77 Transmission Control Protocol, Src Port: 56152, Dst Port: 443, Seq: 1, Ack: 1, Len: 894 Transport Layer Security In reverse direction packets have no additional header Frame 202: 1498 bytes on wire (11984 bits), 1498 bytes captured (11984 bits) Ethernet II, Src: MellanoxTech\_5d:ce:f2 (b8:ce:f6:5d:cb:f2), Dst: 02:00:00:05:02:01 (02:00:00:04:02:01) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100 Internet Protocol Version 4, Src: 15.73.19.77, Dst: 8.87.12.214 Transmission Control Protocol, Src Port: 443, Dst Port: 4043, Seq: 1, Ack: 272, Len: 1428 So we need to strip first ip header for half packets for suricata be able to work with them. Can you, please, help me choose the right solution for such a scenario. I red there is an opportunity to use XDP in suricata. May be another options are available. Thnx! Suricata version 7.0.6 RELEASE Ubuntu 22.04.4 LTS ---
**Author:** ![vjulien](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/vjulien/32/4_2.png) [@vjulien](https://forum.suricata.io/u/vjulien)\ **Post date:** [September 11, 2024, 4:57am UTC](https://forum.suricata.io/t/suricata-on-ipip-tunneled-packets/4850/2 "2024-09-11T04:57:28Z")
I believe this PR might try to address a similar case: > > > If a Suricata inline IPS device is routing traffic over a non-encrypted tunnel, …like IPv6 tunnels, packets in a flow will be dropped and not be matched. e.g. > > The following example is a Suricata inline IPS with an IPv6 tunnel: > \`\`\` > request: IPv4\]ICMP\] -\> |IPS| -\> IPv6\]IPv4\]ICMP\] > reply: \<- |IPS| \<- IPv6\]IPv4\]ICMP\] > \`\`\` > Both the IPv4 request and IPv6 reply will be seen by Suricata on > ingress. The flows will not be matched due to flow recursion level. > > Optionally use pkt recursion level in flow hash. Excluding recursion level in flow hash allows matching of packet flows and defrag on an inline IPS Suricata scenario where the IPS device is a tunnel terminator. > > Bug: #6260 > > Make sure these boxes are signed before submitting your Pull Request -- thank you. > > \- \[✓\] I have read the contributing guide lines at https://docs.suricata.io/en/latest/devguide/codebase/contributing/contribution-process.html > \- \[✓\] I have signed the Open Information Security Foundation contribution agreement at https://suricata.io/about/contribution-agreement/ > \- \[✓\] I have updated the user guide (in doc/userguide/) to reflect the changes made (if applicable) > > Link to \[redmine\](https://redmine.openinfosecfoundation.org/projects/suricata/issues) ticket: > https://redmine.openinfosecfoundation.org/issues/6260 > > Describe changes: > Add config (decoder.recursion-level.use-for-tracking) to control the use of packet recursion level in flow matching. This is to support scenarios where Suricata inline IPS device is routing traffic over a non-encrypted tunnel, like IPv6 tunnels, packets in a flow will be dropped and not be matched. e.g. > > The following example is a Suricata inline IPS with an IPv6 tunnel: > request: IPv4\]ICMP\] -\> |IPS| -\> IPv6\]IPv4\]ICMP\] > reply: \<- |IPS| \<- IPv6\]IPv4\]ICMP\] > > Both the IPv4 request and IPv6 reply will be seen by Suricata on ingress. The flows will not be matched due to flow recursion level. > > \### Provide values to any of the below to override the defaults. > > To use a pull request use a branch name like \`pr/N\` where \`N\` is the > pull request number. > > Alternatively, \`SV\_BRANCH\` may also be a link to an > OISF/suricata-verify pull-request. > > https://github.com/OISF/suricata-verify/pull/1597 > > \`\`\` > SV\_BRANCH=pr/1597 > \`\`\` Currently Suricata will decode such packets just fine, but won’t match up both sides of the traffic in a flow due to the tunnel imbalance. ---
**Author:** ![vseregin](https://avatars.discourse-cdn.com/v4/letter/v/35a633/32.png) [@vseregin](https://forum.suricata.io/u/vseregin)\ **Post date:** [September 11, 2024, 7:47am UTC](https://forum.suricata.io/t/suricata-on-ipip-tunneled-packets/4850/3 "2024-09-11T07:47:05Z")
Victor, thnx for your response! May be i can use eBPF filter (with or without XDP) to find and change tunneled packets (strip upper ip header) before suricata will look to them? Is this the correct approach, will it work? You also say - suricata will decode such packets just fine. Can you please point which decoder from ~/suricata/src/ is applicable for ipip tunnel and how can i enable packet decapsulation in suricata to see events in log with internal ip header?