pfSense

Security Onion does not collect logs from firewall rules with action==match. The reason is the format of the syslog messages that pfsense generates for firewall rules with action=Match.
Here is what the syslog messages look like for rules with action==Block or action==Pass or action==Reject :
Firewall rule with action Pass:
163,,,1745940852,vtnet1.50,match,pass,in,4,0x0,,128,32369,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1804340
Firewall rule with action Reject:
163,,,1745940852,vtnet1.50,match,block,in,4,0x0,,128,32361,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1803240
Firewall rule with action Block:
163,,,1745940852,vtnet1.50,match,block,in,4,0x0,,128,32357,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1802840
And here how it look like for the rule with action==Match
Firewall rule with action Match:
163,,,1745940852,vtnet1.50,match,unkn(%u),in,4,0x0,,128,32365,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1803940

Security Onion pipeline pfsense integration contains a pattern that expects to see WORD characters in the 7th log field, but in the log from a firewall rule with action=Match it gets unkn(%u) which causes it to discard such logs.

I've generated a bug report on github for elastic integrations, but it seems more logical to fix the problem in pfsense log output than to add a parsing exception on the elastic integrations side.
A possible solution would be if a firewall rule with action Match generated a message like this one
163,,,1745940852,vtnet1.50,match,match,in,4,0x0,,128,32365,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1803940
or
163,,,1745940852,vtnet1.50,match,inspect,in,4,0x0,,128,32365,0,none,1,icmp,60,10.100.4.10,1.1.1.1,request,3,1803940

It would also be an additional small improvement if the logs from Firewall rule with action Reject contained reject instead of block.

Here is a link to the netgate forum with a description of the problem:
https://forum.netgate.com/topic/197304/security-onion-does-not-collect-logs-from-firewall-rules-with-action-match/3
and also a link to the issue in elastic integrations on github:
https://github.com/elastic/integrations/issues/13738