[RFC PATCH v2 0/1] netfilter: nat: restore default DNAT behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

We have noticed what appears to be a regression from v4.4 in the DNAT port
selection logic in nf_nat_core.c.  Specifically, we're expecting an iptables
command like

    iptables -t nat -A PREROUTING -p tcp -d 10.0.0.2 -m tcp --dport 32000:32010
    -j DNAT --to-destination 192.168.0.10:21000-21010

to DNAT traffic sent to 10.0.0.2:32000-32010 to 192.168.0.10:21000-21010.  We
use the range on the LAN side to handle tuple collisions that might occur with
a single port specified via --to-destination.

The behavior we're seeing currently, however, is the behavior we'd expect if we
were passing --random to iptables (except without passing --random): the DNAT'd
port is random within the range.

Through my naive debugging, I've arrived at this RFC patch and have included it
mostly to illustrate the behavior our userspace is expecting with the above
iptables command.  The hope is that I can be educated with what other
folks expect the behavior to be, or what I can change in our iptables
command to get the behavior we're expecting.

Thanks so much for your time,
Kyle

--
v1 -> v2:
- Restrict to NF_NAT_MANIP_DST so that we don't have predictable source
  port conflict resolution, without changing the --range and --random
  override behavior.





[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux