OPNsense rejecting ipv4 RESPONSES from public servers with host unreachable

[sja1440]

I have OPNsense 25.10.

This problem has me completely stumped. It only occurs when the the ipv4 request (eg TCP SYN, ICMP..) originates from any VM on my Fedora workstation. It does not happen when the request originates from my workstation or from a VM in a PRoxmox server.

I have taken captures from the workstation and the LAN and WAN interfaces on OPNsense.

This is what I see on the WAN interface:
* If I execute 'wget 142.251.209.46' from my workstation I see the traffic you would expect.
* If I execute 'wget 142.251.209.46' from the Debian VM I see an incoming SYN,ACK followed immediately by OPNSENSE sending out an icmp Host Unavailable.

I can see no discernible difference between the two ipv4 requests.

The issue is clearly being caused from within OPNSense, but where and why?

Why should OPNSense reject a protocol response when the firewall has already let the outgoing ipv4 message pass?

Anybody have some ideas on how I can diagnose this?

 

[sja1440]

I've now understood what happend and why.

OPNSense rejected the incoming responses on WAN, because there was no ARP entry for the VM's ip address so it really couldnt find the host. I checked because I noticed that the (ISC) DHCP lease table had a red plug symbol (offline) against it.

Why didnt the ARP table have and entry for the VM's ip address? Ah, well, in an attempt to dissuade the childrens' friends from connecting their PC's to the LAN (I prefer them to use wifi where they automatically get put onto their own vlan) I set to true within the ISC DHCP server the two flags:
* Deny unknown clients
* Enable Static ARP entries
It seems that something has changed within OPNSense because at one time, when I added a new ipv4, the static arp entry was created, now it isnt. So I unchecked the flags, restarted the DHCP server, checked the flags again, restarted the server and did a reboot for good measure. Hey presto, the arp entry was created and everything worked as should.