Internal LANs do not reach published sites with NAT Port Forward in DMZ

8pENG

Greetings to all

We are preparing a firewall structure on pfSense with two HA servers and we are running aground on a problem that we can't understand.

We have a WAN with 16 IP addresses, we used one for CARP and two more for the interfaces, we added two more public IPs as IP Alias of the CARP interface. Internally we have about 30 LANs all mounted as VLan of a 10GB interface. We have made the NATs and firewall rules, one to block private IPs RFC 1918 (we don't want open routes between the various LANs) followed by one with any origin and destination. The result is that all internal LANs regularly navigate the internet.
We then have a DMZ on which we have published a simple Test site. The Port Forward NAT has as its destination address an IP Alias of the CARP interface. On the WAN firewall rules we have the rule with any origin and destination private IP of the web server.
The result we get is that from the internet the test site is perfectly reachable while only from ONE of the 30 internal LANs it is reachable, from all the others the browser shows an ERR_CONNECTION_REFUSED and the page is not reachable.
In the advanced settings -> firewall and NAT we have activated the NAT reflectio as Pure NAT and enabled automatic outbound NAT for reflection, otherwise calling the test site the DNS Rebind attack detected warning arrived.
We really don't understand what generated this anomaly, any help is certainly appreciated

thank you so much for any help and for the time you can dedicate to us

8pENG

Update....

we have seen that on the master firewall shell many strings appear: pfr_update_state: assertion failed.
every time we call the test site from a network that does not reach it, lines of this error are added, which does not happen if we call the site from the only network that reaches it and returns the welcome page.
we will try to understand this better but any help from you is precious.
thank you very much

stephenw10

What's different about the subnet/interface that can reach it?

When you try to reach it from the working subnet check the states that are created.

Compare that with states created when trying from a failing subnet. Check the firewall logs.

Connection refused instantly implies something is responding that it's blocked. The default pfSense block rule doesn't do that. So it may be incorrectly routed or denied at the target device.

Your block 1918 destinations would block this connection since NAT happens before firewall rules. The NAT reflection rules should translate the destination from the CARP/IPAlias VIP to the internal server IP and that would be blocked.

Are you trying to connect using an FQDN? Does that resolve to the public VIP?

Steve