On 03/07/2018 08:26 PM, zrm wrote: > You want to override the default address and port translation, but only > if that would have been possible given the configuration. No, not quite. You want to reestablish the connection. SO: (1) The connection you are _reestablishing_ was previously _established_. That means, in the past iteration... (1.a) The connection was automatically established via the default rules. (1.b) The connection was previously established via a specific PCP request. It would be normal and desirable for the automatic NAT pools for ports and addresses to be "kept away from" the likely PCP requests ports. For example, if I know my SIP clients use PCP and will always want to use ports from 10,000 to 12,000 then a good design would exclude those ports from the SNAT port range so that that the SIP connections will not have a contentious relationship with the rest of the traffic. Additionally I might _also_ want to reject traffic for port 25 if-and-only-if it it wasn't allocated by the PCP system. See the PCP service is configured by it's rules/files to create ranges that are wholly immaterial compared to the firewall rules for non-PCP participants. There's a saying from a book I read once: "Always forbidden, but on occasion mandatory". So if you put in an invalid external IP address the PCP daemon _should_ reject it based on being unable to find an matching interface. But if it _doesn't_ then the matching rule injected into the firewall will become noise. It will never match because you'll never get packets with those traits. Go look at miniupnpd it does all its configuration stuff, but then it goes in an packs rules into the firewall with iptables, one or two for each mapping. The go into a separate table/chain that gets invoked _before_ the regular explicit rules. It's not necessary or useful to see "what would the firewall rules do to this connection", it's only useful to see "does PCP think this mapping matches it's limitations". You're trying to put _way_ too much horse in front of that cart... > For example, > suppose the system administrator has the following rules: > > iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > iptables -A FORWARD -o inet0 -p tcp --dport 25 -j REJECT > iptables -A FORWARD -i lan0 -j ACCEPT > iptables -A FORWARD -j REJECT > iptables -t nat -A POSTROUTING -o inet0 -j SNAT --to-source 1.2.3.4 > > Now we get a PCP PEER request that asks for tcp src 192.168.1.5:2345 dst > 5.6.7.8:25 to be translated to external src 9.10.11.12:1024. So let's say someone maps port 25 with PCP. Well when the first packet comes through the forwarding rule then the connection is not yet ESTABLISHED, so the reject rule would stop the packet anyway. This is why we _DONT_ manhandle the connection tracking state. But the PCP daemon should have _already_ not allowed that connection. Meanwhile if we don't want _normal_ connections to succeed but we want PCP controlled sessions on port 25, then we can use packet marking or SNAT/DNAT match status (see conntrac --ctstate DNAT etc) to bypass the restriction. You are building a novel and complex system, but you've _got_ to rely on the user to do some of the work otherwise you've built an inflexible system. In your example both your existing post-routing SNAT rule and your PCP config should _already_ restrict the connections to not use port 25 anyway. --Rob. -- 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
