pfSense

SKIP (type 39) has been deprecated:
https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml#icmp-parameters-codes-39
https://tools.ietf.org/html/rfc6918

I will guess that it is no longer a valid name of an icmp-type to pf.

Is there a reason you (or anyone) need to particularly filter on that icmp-type?

The easy fix is to remove it from the icmp-types available for filtering.

No reason for me, just found the bug and reporting it.

Hmmm - pf seems to know about "skip":
https://github.com/pfsense/FreeBSD-src/blob/devel/sbin/pfctl/pfctl_parser.c#L85

But also "SKIP" is a keyword/token used in lines like:

set skip on lo0

https://github.com/pfsense/FreeBSD-src/blob/devel/sbin/pfctl/parse.y#L5757

So I will guess that the parser is not smart enough to know its context, and sees "skip" as a keyword when it should understand that it is looking for an ICMP type word as the next token after "icmptype" in a rule.

If nobody cares about icmp-type skip, then the easy "fix" in pfSense is to remove "skip" from the ICMP types listed in the GUI.

I figured it was likely a parser issue when I was narrowing it down to SKIP - I initially tried the types with parentheses before getting to SKIP. I'd say the workaround is not really needed given that it's such a rarely used and insignificant feature. However, I would say that it may be worth improving the parser, since who knows what other issues could come up in the future due to un-escaped input.

Phillip Davis wrote:

SKIP (type 39) has been deprecated:
Is there a reason you (or anyone) need to particularly filter on that icmp-type?

Well, the only reason I can imagine is precisely that: you take the list of deprecated types and filter it, since it's not something that should be floating around. Someone take it to https://bugs.freebsd.org/bugzilla/ perhaps, though I can imagine the only fix will be renaming ICMP_SKIP

If you want to block all "dodgy" ICMP types, then you should probably block ICMP type numbers that do not have a defined name, as well as deprecated ones. Since there is no way to explicitly specify/select "undefined type codes", you would do this by 2 rules:
1) Pass ICMP types that you know are good/wanted
2) Block all others

So in that case you do not need explicit codes for the deprecated ICMP types.

But I suppose you might want to do something different for deprecated types (log them or not log them...) vs "undefined type codes".

In any case, pfSense could easily modify its own pfctl_parser.c to rename "skip" to something else unique, then use that something else when it turns the config value into the written pf rule.

An easier way to keep it would be to use the type number (39) instead of the name. The rule loads fine with 39 instead of skip

pass  in  quick  on $WAN reply-to ( igb1 198.51.100.1 ) inet proto icmp  from any to any icmp-type 39 tracker 1489080712 keep state  label "USER_RULE" 

: pfctl -sr | grep skip
pass in quick on igb1 reply-to (igb1 198.51.100.1) inet proto icmp all icmp-type skip keep state label "USER_RULE"