On 6 October 2016 at 19:09, Davide Caratti <dcaratti@xxxxxxxxxx> 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.
>
Since I can add the same rule in nftables, I wonder if the same problem happens:
chain postrouting {
type nat hook postrouting priority 0; policy accept;
ip protocol sctp snat 10.0.0.1:61000
}
--
Arturo Borrero González
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
