How do requests to WAN IP behave from inside LAN?

[alto]

I've had http(s) ports open to access from WAN previously, exposing some services to the internet, and am now closing them as my needs have changed. What I had were rules on the WAN interface allowing ingress on the ports which were forwarded to hosts with reverse proxies.

But what I'm not understanding is that after disabling these ingress rules on the WAN interface I still get a response saying the ports are open when checking using netcat like `nc -zv my.public.ip 443` from local VLANs. Is there some other set of config that could still be providing the ingress, or is the WAN IP automatically routed with some kind of loopback behavior inside the LAN which gives me this result? I tried accessing one of the previously exposed services from my phone on mobile network, and at least from there I can't access the ports anymore, but I would like to understand how I'm getting this open port response internally when pointing to the same WAN IP from the LAN.

[Monviech (Cedrik)]

Your client sends the dst IP (WAN address) to the OPNsense.

The packet is received on the Firewall on LAN. If there is a rule that allows "Destination Any", then the packet is passed to the routing stack.

The OPNsense has a local route to your WAN address, and thus sends an answer back to your client.

If you do not want that, configure your LAN Firewall more restrictive.

[meyergru]

Also, it depends on how you allowed for the access in the first place: a. via NAT reflection or b. by creating local DNS aliases for those names that point to the local IP.

[Patrick M. Hausen]

Also, it depends on how you allowed for the access in the first place: a. via NAT reflection or b. by creating local DNS aliases for those names that point to the local IP.

They were asking about a setup with reverse proxies. So they connect directly to the WAN address from inside. No NAT reflection necessary.

@Monviech's answer is correct ;-)

[alto]

<deleted duplicate post>

[alto]

Thank you all for your replies, so it behaves like I was guessing, i.e. hitting the WAN address from inside the LAN. This makes complete sense for the behavior I'm observing and gives me peace to know that the ports aren't open to the internet anymore. It also simplifies some things for me as I can share some services to an isolated "work" VLAN which can look up public DNS records pointing to my WAN address and route them locally without having to set up anything more to make it work.