REPLY or REQUEST logs are not appearing for ICMP in OPNSense

[sandson]

I have the following OPNSense log:

Code Select Expand

<134>1 2024-12-29T13:25:49-03:00 OPNsense.corp.local filterlog 85148 - [meta sequenceId="6004"] 75,,,f921acc799f56939126928358ef4f9bd,em1,match,pass,out,4,0x0,,127,21532,0,none,1,icmp,60,192.168.145.87,172.232.188.170,datalength=40
I have the following pfSense log:

Code Select Expand

<134>1 2024-12-29T11:57:28.879089-03:00 pfsense.xpto.local filterlog 59326 - - 78,,,1000004761,em0,match,pass,out,4,0x0,,127,63241,0,none,1,icmp,60,192.168.145.84,200.147.3.157,request,53157,51840
The "request" log does not exist in opnsense.
What does this mean? Is there some setting I did wrong or need to do?
Do you have any idea what it could be?

Appliance Specs:
Type   opnsense   
Version   24.7.11_2   
Architecture   amd64   
Commit   0761a96de   
Mirror   https://pkg.opnsense.org/FreeBSD:14:amd64/24.7   
Repositories   OPNsense (Priority: 11)   
Updated on   Sun Dec 22 16:06:35 -03 2024   
Checked on   Sun Dec 29 15:01:37 -03 2024

Installed Modules:
os-theme-cicada
os-acme-client
os-apcupsd
os-bind
os-c-icap
os-cache
os-caddy
os-chrony
os-clamav
os-collectd
os-cpu-microcode-amd
os-cpu-microcode-intel
os-crowdsec
os-ddclient
os-debug
os-dec-hw
os-dmidecode
os-dnscrypt-proxy
os-etpro-telemetry
os-freeradius
os-frr
os-ftp-proxy
os-git-backup
os-google-cloud-sdk
os-grid_example
os-haproxy
os-helloworld
os-hw-probe
os-igmp-proxy
os-intrusion-detection-content-et-open
os-intrusion-detection-content-et-pro
os-intrusion-detection-content-snort-vrt
os-iperf
os-lcdproc-sdeclcd
os-lldpd
os-maltrail
os-mdns-repeater
os-munin-node
os-ndproxy
os-net-snmp
os-netdata
os-nextcloud-backup
os-nginx
os-node_exporter
os-nrpe
os-ntopng
os-nut
os-openconnect
os-OPNProxy
os-postfix
os-puppet-agent
os-qemu-guest-agent
os-radsecproxy
os-realtek-re
os-redis
os-relayd
os-rfc2136
os-rspamd
os-shadowsocks
os-siproxd
os-smart
os-squid
os-sslh
os-stunnel
os-sunnyvalley
os-tailscale
os-tayga
os-telegraf
os-tftp
os-theme-advanced
os-theme-rebellion
os-theme-tukan
os-theme-vicuna
os-tinc
os-tor
os-udpbroadcastrelay
os-upnp
os-virtualbox
os-vmware
os-vnstat
os-wazuh-agent
os-web-proxy-sso
os-wol
os-xen
os-zabbix-agent
os-zabbix5-proxy
os-zabbix6-agent
os-zabbix6-proxy
os-zabbix7-agent
os-zabbix7-proxy
os-zabbix64-agent
os-zabbix64-proxy
os-zerotier

[EricPerl]

It's difficult to tell without details on interfaces and IP ranges.
em1,match,pass,out,4,0x0,,127,21532,0,none,1,icmp,60,192.168.145.87,172.232.188.170
I see ICMP traffic leaving (out) the FW on em1 with source 192.168.145.87 and destination 172.232.188.170. Both IP addresses are in private ranges.
You might be pinging something from the FW.
It could be the outbound request corresponding to an inbound (from the FW's perspective) request on another interface, with the same destination.

You don't see replies in the FW logs.
If you want to see all traffic, use network captures.

[pfry]

Interesting. ICMP type does not appear to be logged. Of course, you can match on it in your ruleset, and use the rule ID to determine type. As EricPerl said, you'll generally only see the session setup logged (assuming you have logging enabled)... But for ping, I see (in order, top to bottom):

2025-01-04T14:53:51-06:00    Informational    filterlog    82,,,5597b84ffa3f116e2fdaddd459a7f10a,bridge0,match,pass,in,4,0x0,,238,54321,0,none,1,icmp,40,18.209.209.2,47.190.83.197,datalength=20
2025-01-04T14:53:51-06:00    Informational    filterlog    68,,,1232f88e5fac29a32501e3f051020cac,bridge0,match,pass,out,4,0x0,,238,54321,0,none,1,icmp,40,18.209.209.2,47.190.83.197,datalength=20

...which corresponds to:

EDGE    ->    2025-01-04T14:53:51-06:00    18.209.209.2    47.190.83.197    icmp    EDGE: Pass Ping_v4 from any to any
EDGE    <-    2025-01-04T14:53:51-06:00    18.209.209.2    47.190.83.197    icmp    let out anything from firewall host itself   

The second log entry is... misleading. Apparently ICMP echo has a built-in fixup to allow echo replies.

[EricPerl]

Here's what I see (most recent up) when pinging quad9 from VLAN

Code Select Expand

2025-01-04T12:17:42-08:00 Informational filterlog 116,,,d732bf074e5af1431615bc5c20ab4d3c,vtnet0,match,pass,out,4,0x0,,127,2496,0,none,1,icmp,60,WAN_IP,9.9.9.9,datalength=40
2025-01-04T12:17:42-08:00 Informational filterlog 146,,,165dc270c4d92fafcedd0315358715cb,vlan0.10,match,pass,in,4,0x0,,128,2496,0,none,1,icmp,60,10.10.10.192,9.9.9.9,datalength=40
in on VLAN, out on WAN, requests only.

Are you sure your bridge is set up properly (tunables)?

[pfry]

[...]
Are you sure your bridge is set up properly (tunables)?

Heh. Deviating from the original poster's question a bit, but yes, while unusual, my bridge is working, with a couple caveats (posted eldewhere). It is both the incoming and outgoing interface, and the bridge sysctls have no effect (also posted elsewhere). Your log samples (in log format, with the first being at the bottom) are likely a better example than mine, where the bridge oddity might distract the reader.