Problem setting up nftables dnat : dport set to 0 instead of requested value (22)

Hi,

I'm trying to redirect incoming tcp connections for port 222 to local port 22 (because I will dnat incoming connections for port 22 to another destination).

@Arturo: Could you add documentation for your 'redirect' support to ?

Quoted 5 lines · leroy christophe

Hi,

I'm trying to redirect incoming tcp connections for port 222 to local port 22 (because I will dnat incoming connections for port 22 to another destination).

Then you have to use "redirect" instead of "dnat". "redirect" will be available since the upcoming 3.19-rc.

Cc'ing Arturo, he has worked on the redirect support.

@Arturo: Could you add documentation for your 'redirect' support to ?

http://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_%28NAT%29

Thanks.

Quoted 9 lines · Pablo Neira Ayuso

Quoted 5 lines · leroy christophe

Hi,

I'm trying to redirect incoming tcp connections for port 222 to local port 22 (because I will dnat incoming connections for port 22 to another destination).

Then you have to use "redirect" instead of "dnat". "redirect" will be available since the upcoming 3.19-rc.

Quoted 9 lines

Cc'ing Arturo, he has worked on the redirect support.

@Arturo: Could you add documentation for your 'redirect' support to ?

http://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_%28NAT%29

Thanks.

Thanks for the information.

I have now applied patches 8d13edd, 9de920e and e9105f1 on my 3.18 kernel, so now the redirect rule is accepted, but I still get the same issue: dport gets value 0 instead of 22 after the redirect, see below

Is there any other patch to apply ?

Christophe

[  932.304106] redir IN=eth0 OUT= MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37 DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22863 DF PROTO=TCP SPT=55116 DPT=222 WINDOW=14600 RES=0x00 SYN URGP=0
[  932.304523] rejected IN=eth0 OUT= MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37 DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22863 DF PROTO=TCP SPT=55116 DPT=0 WINDOW=14600 RES=0x00 SYN URGP=0

Hi,

table ip nat {
        chain prerouting {
                 type nat hook prerouting priority 0;
                 tcp dport 222 redirect :22
        }
        chain postrouting {
                 type nat hook postrouting priority 0;
        }
}

With the above rules, data[priv->sreg_proto_min].data[0] has value 0x160000 instead of 0x16 on powerpc (Big Endian byte order)

Due to this, mr.range[0].min.all gets assigned value 0 instead of 22.

Below patch fixes it, but it is maybe not the proper way to fix it, so I let it up to you.

Christophe

net/ipv4/netfilter/nft_redir_ipv4.c +2 -2

index 643c596..554bb32 100644
@@ -28,9 +28,9 @@ static void nft_redir_ipv4_eval(const struct nft_expr
 *expr,
        memset(&mr, 0, sizeof(mr));
        if (priv->sreg_proto_min) {
                mr.range[0].min.all = (__force __be16)
-                                       data[priv->sreg_proto_min].data[0];
+
 *(__be16*)&data[priv->sreg_proto_min].data[0];
                mr.range[0].max.all = (__force __be16)
-                                       data[priv->sreg_proto_max].data[0];
+
 *(__be16*)&data[priv->sreg_proto_max].data[0];

                mr.range[0].flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
        }

With nft_nat and nft_redir_ipv6, the three code are almost the same:

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/netfilter/nft_nat.c
http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/ipv6/netfilter/nft_redir_ipv6.c

Since it seems the same issue may appear, would you like to patch all of them?

regards.

Quoted 11 lines · Arturo Borrero Gonzalez

With nft_nat and nft_redir_ipv6, the three code are almost the same:

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/netfilter/nft_nat.c

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/ipv6/netfilter/nft_redir_ipv6.c

Since it seems the same issue may appear, would you like to patch all of them?

Quoted 1 line

regards.

Hi,

Yes the issue is most likely the same, so I believe it should also be fixed there.

Quoted 8 lines · leroy christophe

Quoted 7 lines · Arturo Borrero Gonzalez

With nft_nat and nft_redir_ipv6, the three code are almost the same:

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/netfilter/nft_nat.c

http://git.kernel.org/cgit/linux/kernel/git/pablo/nf-next.git/tree/net/ipv6/netfilter/nft_redir_ipv6.c

Quoted 9 lines

Quoted 4 lines

Since it seems the same issue may appear, would you like to patch all of them?

regards.

Hi,

Yes the issue is most likely the same, so I believe it should also be fixed there.

BTW, please send your patches to netfilter-devel. No need to CC [email protected].
Patches should include the Signed-off-by line (please be sure they apply with git am).

Thanks, regards.

Quoted 1 line · Arturo Borrero Gonzalez

On 12 December 2014 at 12:07, leroy christophe <[email protected]> wrote:

I'm not sure what I proposed it the correct patch, maybe it shall be fixed earlier in the chain, I don't know.

Quoted 4 lines · leroy christophe

Quoted 1 line · Arturo Borrero Gonzalez

On 12 December 2014 at 12:07, leroy christophe <[email protected]> wrote:

I'm not sure what I proposed it the correct patch, maybe it shall be fixed earlier in the chain, I don't know.

Yeah, I'm not so sure myself.

Could you please try what happens if you do:

... tcp dport 222 redir :tcp dport

Which should redirect to the same port, but I'm interested if it actually does that.

Quoted 5 lines · Patrick McHardy

Quoted 4 lines · leroy christophe

Quoted 1 line · Arturo Borrero Gonzalez

On 12 December 2014 at 12:07, leroy christophe <[email protected]> wrote:

I'm not sure what I proposed it the correct patch, maybe it shall be fixed earlier in the chain, I don't know.

Quoted 9 lines

Yeah, I'm not so sure myself.

Could you please try what happens if you do:

... tcp dport 222 redir :tcp dport

Which should redirect to the same port, but I'm interested if it actually does that.

Without my patch, I get the following. Note the strange value in the DPT on the second line.

[   61.377273] redirIN=eth0 OUT=
MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37
DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29122 DF PROTO=TCP
SPT=55626 DPT=222 WINDOW=14600 RES=0x00 SYN URGP=0
[   61.377816] rejected IN=eth0 OUT=

MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37 DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=29122 DF PROTO=TCP SPT=55626 DPT=20 WINDOW=14600 RES=0x00 SYN URGP=0

With my patch, I get correct port.

[  511.994597] redirIN=eth0 OUT=
MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37
DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21300 DF PROTO=TCP
SPT=55622 DPT=222 WINDOW=14600 RES=0x00 SYN URGP=0
[  511.994999] rejected IN=eth0 OUT=

MAC=08:00:51:20:44:5b:08:00:27:fe:42:1e:08:00 SRC=172.25.231.37 DST=172.25.231.5 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=21300 DF PROTO=TCP SPT=55622 DPT=222 WINDOW=14600 RES=0x00 SYN URGP=0

Hi,

table ip nat {
        chain prerouting {
                 type nat hook prerouting priority 0;
                 tcp dport 222 redirect :22
        }
        chain postrouting {
                 type nat hook postrouting priority 0;
        }
}

With the above rules, data[priv->sreg_proto_min].data[0] has value 0x160000 instead of 0x16 on powerpc (Big Endian byte order)

Due to this, mr.range[0].min.all gets assigned value 0 instead of 22.

Below patch fixes it, but it is maybe not the proper way to fix it, so I let it up to you.

Christophe

net/ipv4/netfilter/nft_redir_ipv4.c +0 -0

index 643c596..554bb32 100644
@@ -28,9 +28,9 @@ static void nft_redir_ipv4_eval(const struct
 nft_expr *expr,

Quoted 29 lines

Hi,

table ip nat {
        chain prerouting {
                 type nat hook prerouting priority 0;
                 tcp dport 222 redirect :22
        }
        chain postrouting {
                 type nat hook postrouting priority 0;
        }
}

With the above rules, data[priv->sreg_proto_min].data[0] has value 0x160000 instead of 0x16 on powerpc (Big Endian byte order)

Due to this, mr.range[0].min.all gets assigned value 0 instead of 22.

Below patch fixes it, but it is maybe not the proper way to fix it, so I let it up to you.

Christophe

net/ipv4/netfilter/nft_redir_ipv4.c +0 -0

index 643c596..554bb32 100644
@@ -28,9 +28,9 @@ static void nft_redir_ipv4_eval(const struct
 nft_expr *expr,

net/ipv4/netfilter/nft_redir_ipv4.c static void nft_redir_ipv4_eval(const struct · line 36

Quoted 10 lines

net/ipv4/netfilter/nft_redir_ipv4.c +2 -2

 	memset(&mr, 0, sizeof(mr));
 	if (priv->sreg_proto_min) {
 		mr.range[0].min.all = (__force __be16)
-					data[priv->sreg_proto_min].data[0];
+					*(__be16*)&data[priv->sreg_proto_min].data[0];
 		mr.range[0].max.all = (__force __be16)
-					data[priv->sreg_proto_max].data[0];
+					*(__be16*)&data[priv->sreg_proto_max].data[0];
 		mr.range[0].flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
 	}

It seems userspace was generating the wrong bytecode, so your workaround was reversing the again the port values.

Please, test the userspace fix I sent you and get back to us.

Thanks for diagnosing!

Am 22. Dezember 2014 12:54:48 MEZ, schrieb Pablo Neira Ayuso <[email protected]>:

Quoted 44 lines · leroy christophe

Quoted 29 lines

Hi,

table ip nat {
        chain prerouting {
                 type nat hook prerouting priority 0;
                 tcp dport 222 redirect :22
        }
        chain postrouting {
                 type nat hook postrouting priority 0;
        }
}

With the above rules, data[priv->sreg_proto_min].data[0] has value 0x160000 instead of 0x16 on powerpc (Big Endian byte order)

Due to this, mr.range[0].min.all gets assigned value 0 instead of 22.

Below patch fixes it, but it is maybe not the proper way to fix it, so I let it up to you.

Christophe

net/ipv4/netfilter/nft_redir_ipv4.c +0 -0

index 643c596..554bb32 100644
@@ -28,9 +28,9 @@ static void nft_redir_ipv4_eval(const struct
 nft_expr *expr,

net/ipv4/netfilter/nft_redir_ipv4.c static void nft_redir_ipv4_eval(const struct · line 36

Quoted 10 lines

net/ipv4/netfilter/nft_redir_ipv4.c +2 -2

 	memset(&mr, 0, sizeof(mr));
 	if (priv->sreg_proto_min) {
 		mr.range[0].min.all = (__force __be16)
-					data[priv->sreg_proto_min].data[0];
+					*(__be16*)&data[priv->sreg_proto_min].data[0];
 		mr.range[0].max.all = (__force __be16)
-					data[priv->sreg_proto_max].data[0];
+					*(__be16*)&data[priv->sreg_proto_max].data[0];
 		mr.range[0].flags |= NF_NAT_RANGE_PROTO_SPECIFIED;
 	}

It seems userspace was generating the wrong bytecode, so your workaround was reversing the again the port values.

Quoted 1 line

Please, test the userspace fix I sent you and get back to us.

I actually think this is exactly what needs to be done since it also matches what we're doing for runtime gathered data.