# ICMP issue with non-default action order

**URL:** <https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680>\
**Category:** Help\
**Tags:** rules\
**Created:** [September 3, 2021, 8:11pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680 "2021-09-03T20:11:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![bravo\_bravo](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/bravo_bravo/32/530_2.png) [@bravo\_bravo](https://forum.suricata.io/u/bravo_bravo)\
**Post date:** [September 3, 2021, 8:11pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680/1 "2021-09-03T20:11:10Z")

</div>

It appears there may be an issue with the handling of ICMP flows when a non-standard action order is in use. Repro:

```auto
Runmode: af-packet
action-order: Drop, Pass, Reject, Alert

```

Rules:

```auto
drop icmp any any -> 8.8.8.8 any (msg:"Drop ICMP"; sid:10002;)
pass ip any any -> any any (msg:"Pass IP"; sid:1004;)
pass tcp any any -> any 22 (sid:1;)

```

If I run a ping to 8.8.8.8 the first packet is dropped, but the subsequent packets are allowed through.

---

<div class="post-metadata">

**Author:** ![Jeff\_Lucovsky](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/jeff_lucovsky/32/11_2.png) [@Jeff\_Lucovsky](https://forum.suricata.io/u/Jeff_Lucovsky)\
**Post date:** [September 5, 2021, 1:59pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680/2 "2021-09-05T13:59:13Z")

</div>

> drop icmp any any → 8.8.8.8 any (msg:“Drop ICMP”; sid:10002;)

Can you add a qualification to the rule and report what happens?

E.g., this adds `icode`

```auto
drop icmp any any -> 8.8.8.8 any (msg:"Drop ICMP"; icode:>0; sid:10002;)

```

---

<div class="post-metadata">

**Author:** ![bravo\_bravo](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/bravo_bravo/32/530_2.png) [@bravo\_bravo](https://forum.suricata.io/u/bravo_bravo)\
**Post date:** [September 7, 2021, 4:04pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680/3 "2021-09-07T16:04:15Z")

</div>

Hey Jeff, thank you for the reply.

We still see the same behavior with the icode condition as you suggested.

```auto
drop icmp any any -> 8.8.8.8 any (msg:"Drop ICMP"; icode:>0; sid:10002;)
pass icmp any any -> any any (msg:"Pass any"; sid:10004;)

```

```auto
action-order:
  - drop
  - pass
  - reject
  - alert

```

Continuing our investigation.

---

<div class="post-metadata">

**Author:** ![bravo\_bravo](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/bravo_bravo/32/530_2.png) [@bravo\_bravo](https://forum.suricata.io/u/bravo_bravo)\
**Post date:** [September 7, 2021, 6:51pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680/4 "2021-09-07T18:51:43Z")

</div>

Adding a flow condition to the pass icmp rule makes it behave. Both types rules below work as expected.

```auto
drop icmp any any -> 8.8.8.8 any (msg:"Drop ICMP"; sid:10002;)
pass icmp any any -> any any (msg:"Pass any"; flow:not_established; sid:10004;)

```

```auto
drop icmp any any -> 8.8.8.8 any (msg:"Drop ICMP"; sid:10002;)
pass icmp any any -> any any (msg:"Pass any"; flow:established; sid:10004;)

```

flow:to\_server and flow:to\_client conditions make it work as expected too

Continuing investigation.

---

<div class="post-metadata">

**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 10, 2021, 3:23pm UTC](https://forum.suricata.io/t/icmp-issue-with-non-default-action-order/1680/5 "2021-09-10T15:23:01Z")

</div>

thanks @bravo_bravo, I have created a ticket here [Bug #4670: rules: mix of drop and pass rules issues - Suricata - Open Information Security Foundation](https://redmine.openinfosecfoundation.org/issues/4670)

I’m proposing a fix here

> <https://github.com/OISF/suricata/pull/6368>
>
> https://redmine.openinfosecfoundation.org/issues/4670
> https://redmine.openinfos…ecfoundation.org/issues/4663
> 
> suricata-verify-pr: 536

Test cases I’ve been using are here

> <https://github.com/OISF/suricata-verify/pull/536>