Unexpected "Default deny rule IPv4 (1000000103)"
-
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)
ROUTERDMZ = 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 WORKWe’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.
-
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 WORKAnd the second rule is placed where? Remember rules only work on the interface where the traffic enters the firewall.
-
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 WORKAnd the second rule is placed where? Remember rules only work on the interface where the traffic enters the firewall.
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.
-
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.
-
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.
-
Were you able to resolve this issue? I'm facing this same problem.
-
What issue exactly from 8 months ago... Getting denied RA and A, etc. Are signs of asymmetrical routing or loss of state..
https://www.netgate.com/docs/pfsense/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html
You also have downstream router from pfsense? I would suggest you lay out what issue your specifically seeing and draw up your network if you believe its not do to asymmetrical routing vs chiming in on an old 8 month old thread.
Yes the default deny will block out of state traffic - if your seeing blocks with A and or FA or RA, etc. See my above link.
-
So I'm facing the same problem with some packets being blocked by the Default IPv4 and IPv6 rules. Most websites load okay, I'm having some issues with a few different sites, specifically all of the major Internet Speed Tests are being blocked. (I'm trying to test the performance of pfSense before adopting it)
I'll try to lay out the network the best that I can. I have AT&T Fiber, unfortunately like others with AT&T I'm stuck with the Pace 5268AC device. Previously I was using a Netgear R7900 behind the Pace device. The Netgear router was assigned a public IP address from a block of 8 (xxx.xxx.xxx.113). The Pace device was set into DMZ+ mode which essentially disables the firewall. This setup worked well, I was able to achieve download/upload speeds of 920Mbps+.
I have a number of services hosted on a computer on my network, I was able Port Forward these services from the R7900 to the PC without issues.
I'm looking to replace the R7900 with a pfSense router. The router is running in a VM within XenServer. I have the WAN port on pfSense assigned to a different address in this block (xxx.xxx.xxx.115) and I've configured the Pace device to operate in DMZ+ mode for pfSense.
The firewall in pfSense is configured with the default rules. At this point I'm not sure if the issues I'm facing are due to a bug with the way the Pace 5268 / AT&T handles Static IP addresses or if there is something that I need to adjust in pfSense.
Are there any troubleshooting steps you'd suggest?
I've already reset the AT&T device to remove all the existing Static IP configurations and setup pfSense again.
Edit: A couple things to note
When I disabled the setting to prefer IPv4 I was able to run a Speed Test. It did stop working after around the third run however. The speeds were very slow with around 30Mbps down and around 1Mbps up. I'm also seeing the following entries in the firewall log during the test, the following connections are being blocked.
Aug 10 01:09:09 WAN Default deny rule IPv4 (1000000103) 184.105.148.83:443 xxx.xxx.xxx.115:26764 TCP:PA
Aug 10 01:09:10 ► LAN Default deny rule IPv4 (1000000104) 192.168.1.1:443 192.168.1.100:56861 TCP:FPA
Aug 10 01:09:11 ► LAN Default deny rule IPv4 (1000000104) 192.168.1.1:443 192.168.1.100:56527 TCP:FPA
Aug 10 01:09:13 WAN Default deny rule IPv4 (1000000103) 184.105.148.83:443 xxx.xxx.xxx.115:54299 TCP:PA -
Those are all out of state no SYN packets.. And you have ►on your lan means it was blocked on the outbound direction... Which sure and hell are not default rules.. Or the state was deleted?
You say this is a VM... You got something wrong that is for sure it how it is connected. You would not see default deny rule on outbound unless you maybe killed all your states.. Did you have a wan go do and have your states set to flush?
-
Solution to what? Your seeing Out of state blocks then see the link.. That other poster jumped onto an old thread that is not what he posted, etc..
If your blocks on traffic you feel should be allowed - see the link.. Or post up your details in your own thread.
Never mind this post person is a spammer... Purging his posts now..
-
D Dillio referenced this topic on
