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.
(Also, if the SIP clients and the gateway both support PEER then the
separate ports may not even be needed. The SIP clients can use PEER to
learn their external port so there is no issue of a conflict causing
unexpected port translation.)
In general, PCP clients can supply more information in their requests
than generic firewall traffic. So with the additional information you
may well want to issue ports to PCP clients that you would never issue
to a random client.
The additional information in a PEER request is the suggested external
IP and port, the mapping nonce and the requested mapping lifetime.
If the suggested external IP and port are not allowed then the request
is refused, but what they are has no apparent reason to affect what
they're authorized to be, and neither do the other two fields.
Is there a scenario where this information should be determinative?
Some relevant PCP option could come into existence in the future, but
that's entirely hypothetical and still wouldn't affect any request that
doesn't include it.
You might want to restrict the PCP clients to subsets of what you are
going to do generically.
Why refuse the PEER request if the client can get the same result by
initiating the connection normally?
So that "identical rules" thing is one heck of a limiting assumption.
It isn't a limitation. Even if there was a reason to accept some
specific PEER requests which wouldn't be allowed as a new connection,
it's still possible to implement that as an exception against a default
of treating all other PEER requests the same as normal connections.
That would even be relatively simple to implement. Add an early ACCEPT
rule matching on a particular connection mark, then if a PEER request is
an explicit exception to the normal rules, add that mark to its
connection tracking entry.
But the exceptions are just that.
--
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
