On 03/12/2018 11:32 PM, zrm wrote: > On 03/12/2018 05:58 AM, Robert White wrote: >> I provided several scenarios for why the PEER rules would be different >> than the firewall rules. >> >> Lets wanting to keep the default nat ranges away from your SIP traffic >> was one such example. > > That is an example of treating SIP traffic differently than non-SIP > traffic, not an example of treating PEER requests differently than other > connections. > > I still don't see why you should use different ports for SIP traffic > initiated with a PCP PEER request than the same SIP traffic initiated in > the traditional way. I was talking about treating SIP traffic differently than non-sip traffic. So I'll cut to the chase... you will never be able to "query the verdict for a hypothetical packet" in the current design. Get over it. That you don't understand why is obvious. That you don't want to listen to why is also obvious. That nobody else has jumped in and corrected my attempts to correct you should be something of a hint for you, but apparently it's not. If you don't understand why and how the PCP client has access to more information, and so can make different decisions than fire wall rules, then that is a lack of understanding on your part. Here's some hints, the PCP deamon runs in user space and so has access to all the things that a user-space program can do; while the firewall rules do not. And PEER requests are not time-critical for the entire flow of data while firewall rule execution is time sensitive for all traffic. That you can't imagine why the two systems would have different configuration goals is a lack of imagination on your part as well. Insisting that a limitation is not a limitation is just plain failure, no downright refusal, to learn. If you want the feature so bad, go code it... maybe _then_ you'll figure out why what you want to do is dogs bollocks. We are what, twenty years into iptables, and this sort of probing isn't in the system... gee, why might that be, you _should_ be asking yourself... So since you want the final word, go take it, and I'll do my best to ignore whatever baiting nonsense you post. But just know you are three-times wrong... -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
