[PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Add nf_nat_bridge_ops to do nat in the bridge family

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 include/net/netfilter/nf_nat.h |  3 ++
 net/netfilter/nf_nat_proto.c   | 63 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 66 insertions(+)

diff --git a/include/net/netfilter/nf_nat.h b/include/net/netfilter/nf_nat.h
index 423cda2..0c2d326 100644
--- a/include/net/netfilter/nf_nat.h
+++ b/include/net/netfilter/nf_nat.h
@@ -101,6 +101,9 @@ int nf_nat_icmpv6_reply_translation(struct sk_buff *skb, struct nf_conn *ct,
 int nf_nat_inet_register_fn(struct net *net, const struct nf_hook_ops *ops);
 void nf_nat_inet_unregister_fn(struct net *net, const struct nf_hook_ops *ops);
 
+int nf_nat_bridge_register_fn(struct net *net, const struct nf_hook_ops *ops);
+void nf_nat_bridge_unregister_fn(struct net *net, const struct nf_hook_ops *ops);
+
 unsigned int
 nf_nat_inet_fn(void *priv, struct sk_buff *skb,
 	       const struct nf_hook_state *state);
diff --git a/net/netfilter/nf_nat_proto.c b/net/netfilter/nf_nat_proto.c
index 888292e..652a71e 100644
--- a/net/netfilter/nf_nat_proto.c
+++ b/net/netfilter/nf_nat_proto.c
@@ -1035,3 +1035,66 @@ void nf_nat_inet_unregister_fn(struct net *net, const struct nf_hook_ops *ops)
 }
 EXPORT_SYMBOL_GPL(nf_nat_inet_unregister_fn);
 #endif /* NFT INET NAT */
+
+#if defined(CONFIG_NF_TABLES_BRIDGE) && IS_ENABLED(CONFIG_NFT_NAT)
+static unsigned int
+nf_nat_bridge_in(void *priv, struct sk_buff *skb,
+		 const struct nf_hook_state *state)
+{
+	switch (skb->protocol) {
+	case htons(ETH_P_IP):
+		return nf_nat_ipv4_in(priv, skb, state);
+	case htons(ETH_P_IPV6):
+		return nf_nat_ipv6_in(priv, skb, state);
+	default:
+		return NF_ACCEPT;
+	}
+}
+
+static unsigned int
+nf_nat_bridge_out(void *priv, struct sk_buff *skb,
+		  const struct nf_hook_state *state)
+{
+	switch (skb->protocol) {
+	case htons(ETH_P_IP):
+		return nf_nat_ipv4_out(priv, skb, state);
+	case htons(ETH_P_IPV6):
+		return nf_nat_ipv6_out(priv, skb, state);
+	default:
+		return NF_ACCEPT;
+	}
+}
+
+const struct nf_hook_ops nf_nat_bridge_ops[] = {
+	/* Before packet filtering, change destination */
+	{
+		.hook		= nf_nat_bridge_in,
+		.pf		= NFPROTO_BRIDGE,
+		.hooknum	= NF_INET_PRE_ROUTING,
+		.priority	= NF_IP_PRI_NAT_DST,
+	},
+	/* After packet filtering, change source */
+	{
+		.hook		= nf_nat_bridge_out,
+		.pf		= NFPROTO_BRIDGE,
+		.hooknum	= NF_INET_POST_ROUTING,
+		.priority	= NF_IP_PRI_NAT_SRC,
+	},
+};
+
+int nf_nat_bridge_register_fn(struct net *net, const struct nf_hook_ops *ops)
+{
+	if (WARN_ON_ONCE(ops->pf != NFPROTO_BRIDGE))
+		return -EINVAL;
+
+	return nf_nat_register_fn(net, ops->pf, ops, nf_nat_bridge_ops,
+				  ARRAY_SIZE(nf_nat_bridge_ops));
+}
+EXPORT_SYMBOL_GPL(nf_nat_bridge_register_fn);
+
+void nf_nat_bridge_unregister_fn(struct net *net, const struct nf_hook_ops *ops)
+{
+	nf_nat_unregister_fn(net, ops->pf, ops, ARRAY_SIZE(nf_nat_bridge_ops));
+}
+EXPORT_SYMBOL_GPL(nf_nat_bridge_unregister_fn);
+#endif
-- 
1.8.3.1

[PATCH nf-next 2/3] netfilter: nft_chain_nat: add nft_chain_nat_bridge support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Add nft_chan_nat_bridge to handle nat rule in bridge family

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nft_chain_nat.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/net/netfilter/nft_chain_nat.c b/net/netfilter/nft_chain_nat.c
index 2f89bde..2ae3fbb 100644
--- a/net/netfilter/nft_chain_nat.c
+++ b/net/netfilter/nft_chain_nat.c
@@ -104,6 +104,23 @@ static void nft_nat_inet_unreg(struct net *net, const struct nf_hook_ops *ops)
 };
 #endif
 
+#ifdef CONFIG_NF_TABLES_BRIDGE
+static const struct nft_chain_type nft_chain_nat_bridge = {
+	.name		= "nat",
+	.type		= NFT_CHAIN_T_NAT,
+	.family		= NFPROTO_BRIDGE,
+	.owner		= THIS_MODULE,
+	.hook_mask	= (1 << NF_INET_PRE_ROUTING) |
+			  (1 << NF_INET_POST_ROUTING),
+	.hooks		= {
+		[NF_INET_PRE_ROUTING]	= nft_nat_do_chain,
+		[NF_INET_POST_ROUTING]	= nft_nat_do_chain,
+	},
+	.ops_register = nf_nat_bridge_register_fn,
+	.ops_unregister = nf_nat_bridge_unregister_fn,
+};
+#endif
+
 static int __init nft_chain_nat_init(void)
 {
 #ifdef CONFIG_NF_TABLES_IPV6
@@ -115,6 +132,9 @@ static int __init nft_chain_nat_init(void)
 #ifdef CONFIG_NF_TABLES_INET
 	nft_register_chain_type(&nft_chain_nat_inet);
 #endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+	nft_register_chain_type(&nft_chain_nat_bridge);
+#endif
 
 	return 0;
 }
@@ -130,6 +150,9 @@ static void __exit nft_chain_nat_exit(void)
 #ifdef CONFIG_NF_TABLES_INET
 	nft_unregister_chain_type(&nft_chain_nat_inet);
 #endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+	nft_unregister_chain_type(&nft_chain_nat_bridge);
+#endif
 }
 
 module_init(nft_chain_nat_init);
@@ -142,3 +165,6 @@ static void __exit nft_chain_nat_exit(void)
 #ifdef CONFIG_NF_TABLES_IPV6
 MODULE_ALIAS_NFT_CHAIN(AF_INET6, "nat");
 #endif
+#ifdef CONFIG_NF_TABLES_BRIDGE
+MODULE_ALIAS_NFT_CHAIN(AF_BRIDGE, "nat");
+#endif
-- 
1.8.3.1

[PATCH nf-next 3/3] netfilter: nft_nat: add nft_bridge_nat_type support

[wenxu]

From: wenxu <wenxu@ucloud.cn>

Add nft_bridge_nat_type to configure nat rule in bridge family

Signed-off-by: wenxu <wenxu@ucloud.cn>
---
 net/netfilter/nft_nat.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/net/netfilter/nft_nat.c b/net/netfilter/nft_nat.c
index c3c93e9..ba396851 100644
--- a/net/netfilter/nft_nat.c
+++ b/net/netfilter/nft_nat.c
@@ -136,7 +136,9 @@ static int nft_nat_init(const struct nft_ctx *ctx, const struct nft_expr *expr,
 		return -EINVAL;
 
 	family = ntohl(nla_get_be32(tb[NFTA_NAT_FAMILY]));
-	if (ctx->family != NFPROTO_INET && ctx->family != family)
+	if (ctx->family != NFPROTO_INET &&
+	    ctx->family != NFPROTO_BRIDGE &&
+	    ctx->family != family)
 		return -EOPNOTSUPP;
 
 	switch (family) {
@@ -318,6 +320,40 @@ static void nft_nat_inet_module_exit(void)
 static void nft_nat_inet_module_exit(void) { }
 #endif
 
+#ifdef CONFIG_NF_TABLES_BRIDGE
+static const struct nft_expr_ops nft_nat_bridge_ops = {
+	.type           = &nft_nat_type,
+	.size           = NFT_EXPR_SIZE(sizeof(struct nft_nat)),
+	.eval           = nft_nat_eval,
+	.init           = nft_nat_init,
+	.destroy        = nft_nat_destroy,
+	.dump           = nft_nat_dump,
+	.validate	= nft_nat_validate,
+};
+
+static struct nft_expr_type nft_bridge_nat_type __read_mostly = {
+	.name           = "nat",
+	.family		= NFPROTO_BRIDGE,
+	.ops            = &nft_nat_bridge_ops,
+	.policy         = nft_nat_policy,
+	.maxattr        = NFTA_NAT_MAX,
+	.owner          = THIS_MODULE,
+};
+
+static int nft_nat_bridge_module_init(void)
+{
+	return nft_register_expr(&nft_bridge_nat_type);
+}
+
+static void nft_nat_bridge_module_exit(void)
+{
+	nft_unregister_expr(&nft_bridge_nat_type);
+}
+#else
+static int nft_nat_bridge_module_init(void) { return 0; }
+static void nft_nat_bridge_module_exit(void) { }
+#endif
+
 static int __init nft_nat_module_init(void)
 {
 	int ret = nft_nat_inet_module_init();
@@ -325,15 +361,24 @@ static int __init nft_nat_module_init(void)
 	if (ret)
 		return ret;
 
+	ret = nft_nat_bridge_module_init();
+	if (ret) {
+		nft_nat_inet_module_exit();
+		return ret;
+	}
+
 	ret = nft_register_expr(&nft_nat_type);
-	if (ret)
+	if (ret) {
+		nft_nat_bridge_module_exit();
 		nft_nat_inet_module_exit();
+	}
 
 	return ret;
 }
 
 static void __exit nft_nat_module_exit(void)
 {
+	nft_nat_bridge_module_exit();
 	nft_nat_inet_module_exit();
 	nft_unregister_expr(&nft_nat_type);
 }
-- 
1.8.3.1

Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[Florian Westphal]

wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
> From: wenxu <wenxu@ucloud.cn>
> 
> Add nf_nat_bridge_ops to do nat in the bridge family

Whats the use case for this?

The reason I'm asking is that a bridge doesn't know about IP,
Bridge netfilter (the call-iptables thing) has a lot of glue code
to detect dnat rewrites and updates target mac address, including
support for redirect (suddently packet has to be pushed up the stack)
or changes in the oif to non-bridge ports (it even checks forward sysctl
state ..) and so on.

Thats something that I don't want to support in nftables.

For NAT on bridge, it should be possible already to push such packets
up the stack by

bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
       meta pkttype set unicast ether daddr set 00:11:22:33:44:55

then normal ip processing handles this and nat should "just work".
If above doesn't work for you I'd like to understand why.

Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[wenxu]

On 7/8/2019 10:17 PM, Florian Westphal wrote:
> wenxu@ucloud.cn <wenxu@ucloud.cn> wrote:
>> From: wenxu <wenxu@ucloud.cn>
>>
>> Add nf_nat_bridge_ops to do nat in the bridge family
> Whats the use case for this?
>
> The reason I'm asking is that a bridge doesn't know about IP,
> Bridge netfilter (the call-iptables thing) has a lot of glue code
> to detect dnat rewrites and updates target mac address, including
> support for redirect (suddently packet has to be pushed up the stack)
> or changes in the oif to non-bridge ports (it even checks forward sysctl
> state ..) and so on.
>
> Thats something that I don't want to support in nftables.
>
> For NAT on bridge, it should be possible already to push such packets
> up the stack by
>
> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
>        meta pkttype set unicast ether daddr set 00:11:22:33:44:55

yes, packet can be push up to IP stack to handle the nat through bridge device. 


In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address

is the same known by outer. So The bridge can just do nat( without modify mac address or oif).

But in This case modify the packet dmac to bridge device, the packet push up through bridge device

Then do nat and route send back to bridge device.

Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

Hi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on nf-next/master]

url:    https://github.com/0day-ci/linux/commits/wenxu-ucloud-cn/netfilter-nf_nat_proto-add-nf_nat_bridge_ops-support/20190709-070304
base:   https://kernel.googlesource.com/pub/scm/linux/kernel/git/pablo/nf-next.git master
config: x86_64-randconfig-s1-07091425 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-9) 7.4.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   net/netfilter/nf_nat_proto.c: In function 'nf_nat_bridge_in':
>> net/netfilter/nf_nat_proto.c:1048:10: error: implicit declaration of function 'nf_nat_ipv6_in'; did you mean 'nf_nat_ipv4_in'? [-Werror=implicit-function-declaration]
      return nf_nat_ipv6_in(priv, skb, state);
             ^~~~~~~~~~~~~~
             nf_nat_ipv4_in
   net/netfilter/nf_nat_proto.c: In function 'nf_nat_bridge_out':
>> net/netfilter/nf_nat_proto.c:1062:10: error: implicit declaration of function 'nf_nat_ipv6_out'; did you mean 'nf_nat_ipv4_out'? [-Werror=implicit-function-declaration]
      return nf_nat_ipv6_out(priv, skb, state);
             ^~~~~~~~~~~~~~~
             nf_nat_ipv4_out
   cc1: some warnings being treated as errors

vim +1048 net/netfilter/nf_nat_proto.c

  1038	
  1039	#if defined(CONFIG_NF_TABLES_BRIDGE) && IS_ENABLED(CONFIG_NFT_NAT)
  1040	static unsigned int
  1041	nf_nat_bridge_in(void *priv, struct sk_buff *skb,
  1042			 const struct nf_hook_state *state)
  1043	{
  1044		switch (skb->protocol) {
  1045		case htons(ETH_P_IP):
  1046			return nf_nat_ipv4_in(priv, skb, state);
  1047		case htons(ETH_P_IPV6):
> 1048			return nf_nat_ipv6_in(priv, skb, state);
  1049		default:
  1050			return NF_ACCEPT;
  1051		}
  1052	}
  1053	
  1054	static unsigned int
  1055	nf_nat_bridge_out(void *priv, struct sk_buff *skb,
  1056			  const struct nf_hook_state *state)
  1057	{
  1058		switch (skb->protocol) {
  1059		case htons(ETH_P_IP):
  1060			return nf_nat_ipv4_out(priv, skb, state);
  1061		case htons(ETH_P_IPV6):
> 1062			return nf_nat_ipv6_out(priv, skb, state);
  1063		default:
  1064			return NF_ACCEPT;
  1065		}
  1066	}
  1067	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34307 bytes --]

Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[Florian Westphal]

wenxu <wenxu@ucloud.cn> wrote:
> > For NAT on bridge, it should be possible already to push such packets
> > up the stack by
> >
> > bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
> >        meta pkttype set unicast ether daddr set 00:11:22:33:44:55
> 
> yes, packet can be push up to IP stack to handle the nat through bridge device. 
> 
> In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
> is the same known by outer.

I think that in general they will have different MAC addresses, so plain
replacement of ip addresses won't work.

> But in This case modify the packet dmac to bridge device, the packet push up through bridge device
> Then do nat and route send back to bridge device.

Are you saying that you can use the send-to-ip-layer approach?

We might need/want a more convenient way to do this.
There are two ways that I can see:

1. a redirect support for nftables bridge family.
   The redirect expression would be same as "ether daddr set
   <bridge_mac>", but there is no need to know the bridge mac address.

2. Support ebtables -t broute in nftables.
   The route rework for ebtables has been completed already, so
   this needs a new expression.  Packet that is brouted behaves
   as if the bridge port was not part of the bridge.

Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge_ops support

[wenxu]

在 2019/7/9 18:42, Florian Westphal 写道:
> wenxu <wenxu@ucloud.cn> wrote:
>>> For NAT on bridge, it should be possible already to push such packets
>>> up the stack by
>>>
>>> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
>>>        meta pkttype set unicast ether daddr set 00:11:22:33:44:55
>> yes, packet can be push up to IP stack to handle the nat through bridge device. 
>>
>> In my case dnat 2.2.1.7 to 10.0.0.7, It assume the mac address of the two address
>> is the same known by outer.
> I think that in general they will have different MAC addresses, so plain
> replacement of ip addresses won't work.
>
>> But in This case modify the packet dmac to bridge device, the packet push up through bridge device
>> Then do nat and route send back to bridge device.
> Are you saying that you can use the send-to-ip-layer approach?
>
> We might need/want a more convenient way to do this.
> There are two ways that I can see:
>
> 1. a redirect support for nftables bridge family.
>    The redirect expression would be same as "ether daddr set
>    <bridge_mac>", but there is no need to know the bridge mac address.
>
> 2. Support ebtables -t broute in nftables.
>    The route rework for ebtables has been completed already, so
>    this needs a new expression.  Packet that is brouted behaves
>    as if the bridge port was not part of the bridge.

This is my senario:

For a virtual machine example with address  10.0.0.7 and internet address 2.2.1.7  default router

10.0.0.1. There are both the east-west and south-north traffic. So the outer vnet0 connect to bridge

br0 which with address 10.0.0.1.   The bridge also add an flow-based/metadata_dst vxlan device vxlan0.


So there are three kinds traffic to handle:

1. 10.0.0.7 <-----> 10.0.0.8: both ingress and egress packet gothrough the bridge with vlanid to vni feature.

2. 10.0.0.7 <-----> 10.0.1.8: The egress packet push up to stack through br0 to do route. And the route send packet through

vxlan0 to peer with static mac(Maybe the route can send through br0); The ingress packet always gothrough the bridge to VM.

3. 10.0.0.7  <----> 1.1.1.7: The egress The egress packet push up to stack through br0 to do route and nat. And the route send

packet through vxlan0 to router. With this patche, The router assume is the same mac address for 10.0.0.7 and 2.2.1.7. so it can do

nat under bridge and send to VM.


I think the most big problem is that the only vxlan0 device is alyways attach on br0. For L3( do route) traffic the egress packet will push

up to stack do route through br0.  The ingress I hope only gothrough the bridge to VM for all the three kinds traffic above.