Floating Rules order
-
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.
