Floating Rules order
-
Hi, i'am trying to understand why Floating rules are not working.
From what i've understood they comes first of pfBlockerNG's rules.
But is not working.
Can someone explain me how to solve it?
Settings under pfBlockerNG "Firewall 'Auto' Rule Order" is : | pfSense Pass/Match | pfB_Pass/Match | pfB_Block/Reject | pfSense Block/Reject |Regards
-
What do the created floating rules actually look like?
How are you testing them?
Steve
-
@Shan-lapierre For any pfB rules I don’t want first, I create them as Alias Native which just creates the alias. Then I create rules where desired.
-
Thanks guys for replies.
I almost found a solution but something still not working.
let me explain.
I've changed any pfB rules in Alias Type and then deleted auto rules created by pfB and then i crated newone based on alias.
Then created a floating rules (ones that they comes before pfB). Applied and reloded everything.
I've also created a NAT rules (see pictures) and very strange thing is that the second rule (nat) concerning port range 6000-6399 doesnt work at all. The one regarding port 5060 it working.
I cannot understand why
-
Is that RTP traffic actually arriving at the WAN? Try running a packet capture to confirm.
-
@stephenw10 Yes, is RTp traffic.
-
Yes but is it arriving at the WAN from the remote server?
-
@stephenw10 Sure! And also i can see dropped packets from firewall 's logs regarding destination ports 6xxx.
So RTP flow arrives to WAN interface and if I click on red x (on firewall logs dropped entry) I see that is dropped by pfB rule.
Maybe have I to restart firewall? -
If it's blocked there then it isn't matching the floating pass rule. What do the blocks show?
-
@stephenw10 ,Here what's say blocked rule:
-
That looks like it's hitting the WAN address? Unless the VoIP device has a public IP (routed) I expect a NAT rule to be forwarding that to some internal address.
What is in the Audiocodes_MP112 alias?
-
@stephenw10 exactly. AudiocodesMP alias is 192.168.1.20. So what's wrong in my configuration?
-
Whatever port forward you have is not catching the incoming RTP traffic.
But the forward you have for SIP is.
-
@stephenw10 Ok ..that is clear
. I cannot understand why SIP port is matching and RTP not. Rules are done in same way . Is there some specific log to understand better ? And is there such a way to see a matched rule in some logs? -
Show us your NAT rules for that traffic.
-
@stephenw10
IP_Audiocodes_ACS = src public IP
Audiocodes_MP112 = internal device where RTP flow should be redirected -
Hmm, I'd expect that to match assuming the source and destination addresses match what's redacted above.
Especially since the SIP forward appears to work. I'd check the states though and make sure it actually is.
-
@stephenw10 Sorry but "it actually is" what?
-
Make sure the NAT rule for SIP is actually working. The states will show the translation.
