@9(10001034383) Block drop in inet all label "Default deny rule IPV4"
-
Hi,
Hoping someone can shed some light on this issue that has suddenly started happening and I cannot find a solution. Have rebuilt PF Sense 3 x with no luck.
Used to work with no problem so I don't know why it has suddenly stopped.I have an internal FW that I am using to control traffic from my DMZ.
Based on other forum posts I have tried a number of things.I have a Voice and Data VLAN behind the Internal Firewall. The Voice Vlan is routed through my switch. I have no problems with my UDP traffic using SIP (trunks) works fine. TCP traffic is a different story.
For SIP clients I am using TCP. Traffic is getting to the PBX, but when it is trying to return, I see an error that the Default Deny rule IPv4 has been matched.
I will add that I am not using standard port 5060 TCP but instead using an alternate uncommon port instead. Either way the ports are defined as allowedI have seen a number of posts that it is because of Assymetric traffic, but that does not appear to be the case here. I have set to Bypass statically assigned addresses from Firewall checks, still no luck.
If I disable Firewall functionality it works fine, problem is that I do have some traffic that I am natting so that is not the solution.I even went so far as to enable an additional NIC on the PF Sense and placed it directly into the Voice Vlan and changed the routes fro them PBX to send all traffic direct to the PF Sense.. Still get the same errors.
I also tried the setting of the TCP flags in the advanced settings per the guide that discussed Assymetric routing, and that has not helped either.
I am at a loss at this point as what else to try. I have a rule in the Voice and Data VLAN that say allow All IPv4 traffic out. I have even gone so far as to create All all rules on the Floating and WAN Rule pages. It still blocks the traffic claiming to be a default deny rule..
-
You either have asymmetric traffic or you don't.
Drawing a network diagram complete with interface addresses and subnet masks should make it obvious.
If you do have asymmetric routing I would fix that with a redesign rather than trying to work around it with a bunch of special rules.
Is the reply traffic destined for the same port the outbound traffic is sourced from?
That is a strange tracker for the default IPv4 deny rule. It is usually 1000000103.
-
I don't believe I have asymmetric routing. I looked at the article and tried the settings to see if that possibly was the cause.. I was simply going over everything that I have tried
On my PFSense internal NIC, I have 192.168.162.254/24. My router between my Voice and Data VLAN is 192.168.162.253
My PBX IP is 192.168.2.5
I have a static route in the PFSense for 192.168.2.0/24 -> 192.168.2.253
My PBX has an IP route to the router and the router has an IP route to the PFSense.
UDP traffic on 5060 is working fine, so the routing is working no problem.
So would be A-B-C and C-B-A.So given that nothing else seemed to work I looked at the notes around Asymmetric settings to no avail.
I then decided to try activate a third NIC on the PF Sense directly in the Voice VLAN and updated all the routes to simply pass traffic direct to the PBX, so now it is A - B and B - A.
Same error..
So there is something else going on.
I even created a bunch of specific rules to allow the traffic, but gets hard when the source ports are dynamic.. either way that dod not work and I validated the originating port was included in the range.Just to add to the confusion to this entire error, when I look at the Firewall logs I see the outbound traffic from the PBX, but I never to see the inbound traffic passing through the Firewall… although there is no other way to get there, so may just be a log setting
-
I would packet capture on WAN using the public IP address of the SIP provider.
The SIP provider needs to specify what NAT settings they require or you have to capture and figure it out yourself by looking at the SIP/RTP traffic.
This is an inside PBX/Phones with the PBX trying to talk to outside SIP trunk(s) right?
If you make a change and it doesn't work, like everything you tried for asymmetric routing, delete or disable those changes.
-
I am seeing the same scenario after upgrading to the latest 2.3.3-RELEASE-p1? I do not have firewall logs previous to this period, but noted that I am blocking connections from the LAN network to the LAN network? If I put in individual rules for Source LAN IP to destination LAN IP, this is resolved? My issue is from a dual homed server which has a static route to the LAN gateway, and traffic from this IP (LAN) to other IP's (LAN) are being blocked. I even moved the Allow All rule 192.168.100.0/24 to 192.168.100.0/24 to the top and it is still blocking the traffic?
@9(1000000103) block drop in log inet all label "Default deny rule IPv4"
Any LAN traffic to the outbound WAN interface is passed with no issue?
Did something change to make this behave differently?
Thanks,
Jeffcsp -
Did something change to make this behave differently?
No.
-
I believe my issue was identified as routing to another virtual network, or as you like to remid everyone, it may have been an Asymmetric route. Just seems to have surfaced after a restart of the VM Host. Please disregard my comment.
Cheers,
Jeffcsp -
Just an Update
After completely reinstalling pfsense, instead of going ahead an setting the firewall rules, I waited for the firewall to block. Despite having static routes configured and having enabled Bypass static routes from firewall rules, traffic from my Voice Vlan was still being blocked.
Issue turned out to be that the "Default" Rule is to allow from Source "LAN NET", so I created a new outbound rule from the LAN interface for my Voice VLAN Subnet with allow All, and that seems to have resolved the issue.Can only assume that previously even though I had set Any / Any, somehow something had gotten messed up or corrupt.
My traffic is now flowing as it should.. but does look like there is something up in a recent release as everything had been working in the past.
-
If you need that sort of thing you have asymmetric routing and should redesign.
Glad it's working.