netdev - Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add nf_nat_bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Jul 2019 12:42:06 +0200
From:   Florian Westphal <fw@...len.de>
To:     wenxu <wenxu@...oud.cn>
Cc:     Florian Westphal <fw@...len.de>, pablo@...filter.org,
        netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH nf-next 1/3] netfilter: nf_nat_proto: add
 nf_nat_bridge_ops support

wenxu <wenxu@...oud.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.