pfSense English Support > Firewalling

Unexpected "Default deny rule IPv4 (1000000103)"

(1/1)

deeepdish:
Hello

Seeming strange “Default deny rule IPv4 (1000000103)” behavior.   Poured over mentioned forum posts / FAQs, however haven’t been able to pin this down.

Topology:

              INTERNET
                   |
DMZ --- PFSENSE
                   | (LAN)
              ROUTER

DMZ = 10.1.4.0/24
LAN NETWORK = 10.1.255.0/24
PFSENSE LAN IP =  10.1.255.1
ROUTER IP = 10.1.255.254
ROUTER NETs = 10.1.[1,2,3,10,20,30,etc].0/24  -- basically every 10.1.x.0/24 subnet except 10.1.4.0/24 (DMZ)

PFSENSE has a static route entry for 10.1.0.0/16 pointing to 10.1.255.254.
ROUTER has a default gateway pointing at PFSENSE.

Using latest v2.4.2.

We have one VMware host in DMZ and one within our trusted network (10.1.1.0/24) behind the ROUTER.   

The hosts are trying to connect to each other via Vmware’s NFC protocol (no, not NFS) TCP/902 and TCP/443.

TCP/443 and TCP/902 transit works fine from DMZ to trusted VMWare host.   However the trusted ESX host can’t initiate connections to the DMZ host.   

Assume Any/Any allow rules on all interfaces (wide open).

So in summary:

SRC:10.1.4.1 -> DST 10.1.1.1 TCP443 & TCP902   WORKS
SRC:10.1.1.1 -> DST 10.1.4.1 TCP443 & TCP902   DOESN’T WORK

We’re seeing “Default deny rule IPv4 (1000000103)” for traffic from trusted (LAN) sources. 

I tried the “Bypass firewall rules for traffic on the same interface” in advanced settings, however didn’t seem to help.   

PFSENSE is deployed as a CARP cluster, however the above behavior still persists with secondary node shutdown.

I read / understand out of state rationale given in past responses, and from IPFilter FAQ that out of state packets are generally harmless, however in the above in my case is causing an app from not working.   Bypassing the firewall in the middle resolves connectivity issues (obviously not desired security posture).

Unintuitive behavior considering wide open rules.   

Any assistance is appreciated. 

Grimson:

--- Quote from: deeepdish on December 08, 2017, 05:56:03 am ---So in summary:

SRC:10.1.4.1 -> DST 10.1.1.1 TCP443 & TCP902   WORKS
SRC:10.1.1.1 -> DST 10.1.4.1 TCP443 & TCP902   DOESN’T WORK

--- End quote ---

And the second rule is placed where? Remember rules only work on the interface where the traffic enters the firewall.

deeepdish:

--- Quote from: Grimson on December 08, 2017, 07:13:09 am ---
--- Quote from: deeepdish on December 08, 2017, 05:56:03 am ---So in summary:

SRC:10.1.4.1 -> DST 10.1.1.1 TCP443 & TCP902   WORKS
SRC:10.1.1.1 -> DST 10.1.4.1 TCP443 & TCP902   DOESN’T WORK

--- End quote ---

And the second rule is placed where? Remember rules only work on the interface where the traffic enters the firewall.

--- End quote ---

ANY / ANY rules on all interfaces.   Quote above is intended to summarize which flows work / don’t work.   Seems to be some strange TCP flag issue going on..   Deny rule specifies TCP:RA and TCP:A packets.   As far as I can tell there is only symmetrical routing here.   As per prior comment, I understand some packets states may close due to FW timeouts and should be ignored, in this my case it’s affecting legit app behaviour.   

peter808:
Same here since we updated to 2.41 .

We also have tons of “Default deny rule IPv4 (1000000103)”-log-entries on the LAN-interface, multiple Websites are not reachable.

gryest:
Hi, just want to confirm I have same problem. Cannot explain some packets rejected by the same "rule". I have too Primary LAN and DMZ sub LAN with Pure NAT forwarding. pfSense is WAN gateway and firewall with snort. Those rejected packets are passed by snort as I see.

Navigation

[0] Message Index

Go to full version