Re: new netfilter target - DNETMAP

Re: new netfilter target - DNETMAP

[Jan Engelhardt]

On Friday 2011-01-07 00:02, Marek Kierdelewicz wrote:

>Hi,
>
>The DNETMAP target allows dynamic two-way 1:1 mapping of IPv4 subnets.
>Single rule can map private subnet to shorter public subnet creating
>and maintaining unambigeous private-public ip bindings. Second rule can
>be used to map new flows to private subnet according to maintained
>bindings. Target allows efficient public IPv4 space usage and
>unambigeous NAT at the same time.
>
>DNETMAP is available as patched xtables-addons-1.31 package and as a
>patch for xtables-addons-1.31 package.
>
>http://cat.piasta.pl/dnetmap/

Have you considered updating the NETMAP target inside the linux
kernel instead?

Your idea looks interesting in that I could envision it superseding
DNAT, SNAT and NETMAP altogether.


>Polite request to Jan Engelhardt for inclusion of the target into
>xtables-addons.

It would be nice if you could

 * resolve the inconsistencies in indentation. Specifically, use tabs to 
indent statements. If in doubt, use scripts/Lindent 
and scripts/checkpatch.pl from linux.

 * wrap lines at 80 cols in xt_DNETMAP.man 


Things I have noticed while spending a quick look:

The manpage mentions "If host 192.168.0.10 generates some traffic, it 
gets bound to first free IP in subnet - 20.0.0.0.". However,
20.0.0.0 can be a network address and thus lead to problems.
Is there a way for the user to specify that the range to use
should be 20.0.0.1-20.255.255.254 rather than 20.0.0.0-20.255.255.255?

Re: new netfilter target - DNETMAP

[Marek Kierdelewicz]

>Hi,

Hi,

>Have you considered updating the NETMAP target inside the linux
>kernel instead?

Nope, I haven't thought about it. It's doable. Classic NETMAP
functionality could be available through some rule option.

>Your idea looks interesting in that I could envision it superseding
>DNAT, SNAT and NETMAP altogether.

Thanks :-).

>>Polite request to Jan Engelhardt for inclusion of the target into
>>xtables-addons.
>It would be nice if you could
> * resolve the inconsistencies in indentation. Specifically, use tabs
>...
> * wrap lines at 80 cols in xt_DNETMAP.man 

Will do.

>The manpage mentions "If host 192.168.0.10 generates some traffic, it 
>gets bound to first free IP in subnet - 20.0.0.0.". However,
>20.0.0.0 can be a network address and thus lead to problems.

Usage of network and broadcast addresses for NAT shouldn't pose
any kind of problems. I tested such setups in my networks. If you use
classic NETMAP to map wider address space to shorter one, you can also
have flows NATed to network and broadcast address of subnet specified
as a parameter of the NETMAP rule.

>Is there a way for the user to specify that the range to use
>should be 20.0.0.1-20.255.255.254 rather than 20.0.0.0-20.255.255.255?

Not yet, but module option could do a trick as long as it's really
necessary.

Best regards,
Marek Kierdelewicz

Re: new netfilter target - DNETMAP

[Marek Kierdelewicz]

Hi,

>It would be nice if you could
> * resolve the inconsistencies in indentation. Specifically, use tabs
>   to indent statements. If in doubt, use scripts/Lindent 
>and scripts/checkpatch.pl from linux.

Done. Patch passes checkpatch.pl except for:
- nf_conntrack_tuple.h and nf_nat.h in include/net/netfilter/;
  these two files are copied frome kernel tree;
- lack of signed-off which AFAIK is used for kernel patches only;

I hope it's ok.

> * wrap lines at 80 cols in xt_DNETMAP.man 

Done.

Updated versions are located here:
http://cat.piasta.pl/dnetmap/xtables-addons-1.31-dnetmap-1.0.tar.bz2
http://cat.piasta.pl/dnetmap/xtables-addons-1.31-dnetmap-1.0.patch.bz2

>Things I have noticed while spending a quick look:
>The manpage mentions "If host 192.168.0.10 generates some traffic, it 
>gets bound to first free IP in subnet - 20.0.0.0.". However,
>20.0.0.0 can be a network address and thus lead to problems.
>Is there a way for the user to specify that the range to use
>should be 20.0.0.1-20.255.255.254 rather than 20.0.0.0-20.255.255.255?

To address your concerns I've added new module parameter:

whole_prefix: use network and broadcast addresses of specified prefix
for bindings (default: 1) (uint)

Implementing this as target parameter would be messy because data
structures for a given prefix are created on addition of the first
rule for a given prefix.

best regards,
Marek Kierdelewicz