Re: [PATCH nf-next 0/2] netfilter: autoload NAT support for non-builtin L4 protocols

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Oct 06, 2016 at 07:09:27PM +0200, Davide Caratti wrote:
> this series fixes SNAT/DNAT rules where port number translation is
> explicitly configured, but only the L3 address is translated:
> 
> # iptables -t nat -A POSTROUTING -o eth1 -p stcp -j SNAT --to-source 10.0.0.1:61000
> # tcpdump -s46 -tni eth1 sctp
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth1, link-type EN10MB (Ethernet), capture size 46 bytes
> IP 10.0.0.1.37788 > 10.0.0.2.2000: sctp
>             ^^^^^
> IP 10.0.0.2.2000 > 10.0.0.1.37788: sctp
> IP 10.0.0.1.37788 > 10.0.0.2.2000: sctp
> IP 10.0.0.2.2000 > 10.0.0.1.37788: sctp
> IP 10.0.0.2.2000 > 10.0.0.1.37788: sctp
> IP 10.0.0.1.37788 > 10.0.0.2.2000: sctp
> IP 10.0.0.2.2000 > 10.0.0.1.37788: sctp
> 
> This happens for all protocols that don't have L4 NAT support built into
> nf_nat.ko, such as DCCP, SCTP and UDPLite: unless the user modprobes
> nf_nat_proto_{dccp,sctp,udplite}.ko, port translation as specified in the
> above rule will not be done. 
> The first patch provides persistent and generic aliases for the above
> modules; the second patch autoloads nf_nat_proto_{dccp,sctp,udplite} when a
> SNAT/DNAT rule matching one of the above protocols is created.

I would really like to see DCCP, SCTP and UDPlite built-in, just like
other protocol trackers (TCP, UDP...). This may require a bit of
review work on your/our side, but it would greatly appreciated.

We discussed this during the last Netfilter Workshop, the current
situation is not good, we're in some way responsible for breaking the
deployment of new protocols on the Internet.

Many vendors rely on default configurations, not even looking into
modprobing things, so these protocols are hopeless in the current
situation since routers running Netfilter will likely not supported
them. This is worse since nf_conntrack drops packets for protocols
like SCTP and DCCP since the generic protocol can no longer be used.

Once these protocols are supported built-in, users can configure from
our control plane, ie. iptables/nft, if they explicitly don't want to
allow them by dropping protocols of this kind. But in that case we
would not be responsible anymore for the current situation at least.

Moreover, following this approach, we would also avoid the new
attribute in nft_nat to indicate the layer 4 protocol that you have
mentioned already.

Thanks!