Otdfbt

To bridge wifi interface you may use iw tool to enable 4addr likewise:

# iw dev <wifiInterface> set 4addr on

ie:

# brctl addif <bridgename> <wifiInterface>
can't add <wifiInterface> to bridge <bridgename>: Operation not supported

# iw dev <wifiInterface> set 4addr on
# brctl addif <bridgename> <wifiInterface>

Now it should work. You can show bridges using:

# brctl show

Depends on how mean the AP is to you:

1) It might only want to see packets coming from you, with your known link layer address (and hence not of bridged packets)
2) It might actually be even smarter, and know which IP address should belong to which link layer address (cause it knows DHCP and inspects it)

If 1+2 are both true, you need indeed something like IP NAT, DHCP, ..

But if only 1) is the case, you can fake the link-layer address, and reverse map it onto the right one in the other direction as described here:

https://wiki.debian.org/BridgeNetworkConnections#Bridging_with_a_wireless_NIC

To bridge wifi interface you may use iw tool to enable 4addr likewise:

# iw dev <wifiInterface> set 4addr on

ie:

# brctl addif <bridgename> <wifiInterface>
# can't add <wifiInterface> to bridge <bridgename>: Operation not supported

# iw dev <wifiInterface> set 4addr on
# brctl addif <bridgename> <wifiInterface>

Now it should work. You can check with:

# brctl show

It might not work if iw itself reports an error, like "command failed: Operation not supported (-95)" (seen on Raspbian). Not all drivers implement the feature, apparently.

4addr as described in other answers is certainly the best way when supported by the adapter/driver, but not all of them does. NAT might work for some things, but getting proper communication both ways on the lan will become problematic (ex. connecting a printer or accessing other IoT devices on the other side of the NAT). Anything relying on broadcast/multicast (ex. auto-discovery, bonjour) will fail through the NAT.

The alternative is using an ARP Proxy (parprouted) as described in https://wiki.debian.org/BridgeNetworkConnectionsProxyArp. I've set this up on a Raspberry Pi for a printer and it works like a charm (I have added a 10 second sleep in the post-up commands to let it get an IP address first, it might have to do with the slowness of my old RPi...)

Bridge wlan and 4addr:

Bridging wlan0 is a pain. You normally cannot add it to a bridge interface (brctl returns "Operation not permitted"), and using VirtualBox "bridged" filter results in a big mess of ARP and DHCP conflicts. The cause of this is that 802.11 frames contain only three addresses by default: the MAC addresses of both wireless devices (laptop and AP) and of the final recipient (as in Ethernet). It is always assumed that there is only one possible originator.

802.11 can carry the fourth, originator's MAC address, and this is used in WDS mode by repeaters. This feature can be enabled on Linux too, using iw, and enabling this mode will allow wlan0 to be used in bridge interfaces, as well as with VirtualBox bridged networking:

iw dev wlan0 set 4addr on

However, with 4addr enabled, you're likely to get completely ignored by the AP: association succeeds but all data frames disappear into the ether. This could be for security reasons (because it's damn hard to spoof the source MAC address. Yeah.) In my router (running OpenRG), it's necessary to enable "WDS" mode for the wireless AP interface, add a WDS device restricted to my laptop's MAC address, and add it to the LAN bridge. 4addr packets now work.

There's another problem with this, though – the router now rejects three-address packets from the laptop, which can be rather inconvenient (having to toggle 4addr every time the WLAN network is changed). The workaround is to add, on the laptop, a second wireless interface linked to the same device, but with a different MAC address. First undo the earlier configuration:

iw dev wlan0 set 4addr off

Then, add a second interface – the name was chosen arbitrarily – with a different MAC address:

iw dev wlan0 interface add wds.wlan0 type managed 4addr on
ip link set dev wds.wlan0 addr <addr>
ip link set dev wds.wlan0 up

Here must match the WDS device address configured in the router; other than that, it can be any valid MAC address. The original MAC of wlan0 then remains for "normal" usage.

It's possible to use both wlan0 and wds.wlan0 at the same time – although I've only tested associating to the same AP twice, not to different APs. I'm guessing they would need to at least be on the same channel.

Some people have asked why use this when VirtualBox can bridge WiFi "just fine". The answer is that VirtualBox does not send the virtual machines' MAC addresses; rather, it performs NAT at the MAC layer too. – 2014-08-22

Direct wlan bridge

Under certain circumstances, you could also use wlan_kabel. It uses packet sockets to directly bridge wlan*-devices with ethernet devices. However, you can only bridge one single MAC at a time with wlan_kabel. It doesn't have the drawback of being barred by access points, because only the original MAC of the wlan device is used. In your case this would mean, that wlan0 could only be used by one VM and not even by the host. You can get wlan_kabel here. This is similar to the macvlans solution.

Bridging with ipvlan

IP Vlan does not have the limitation of a bridge it could be used to bridge a network details on how to use it can be found here

Masquerade alternative

Linux routing can be used instead with iptables-masquerade and ip_forward to achieve a bridge but as mentioned this require to enable ip_forward and will make linux act like a router this need to be setup carefully because it could introduce some security concern.

# bridge setup
brctl addbr br0
ifconfig br0 10.10.20.1/24 up

# enable ipv4 forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward

# netfilter cleanup
iptables --flush
iptables -t nat -F
iptables -X
iptables -Z
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

# netfilter network address translation
iptables -t nat -A POSTROUTING -o wlan0 -s 10.10.20.0/24 -j MASQUERADE

The interface br0 will then have access to the wlan0 network

Important and related

Also, and very important, you should not use obsolete, deprecated commands like ifconfig, brctl, and so on. The iproute2 suite contains commands for all of this, including setting up virtual interfaces (something for which we once had to use openvpn) and creating bridges. If you do not know how to set up a bridge with ip, here we go

 ip tuntap add tap0 mode tap user root 
 ip link set tap0 up
 ip link add br0 type bridge
 ip link set tap0 master br0
 ip link set eth0 master br0
 ip addr add 10.173.10.1/24 dev br0
 ip link set br0 up

With this set of commands, we create a virtual interface called tap0, then a bridge called br0, then enslave eth0 and tap0 to the bridge, to which we assign an IP address of 10.173.10.1, then bring it all up. The three separate instances of bringing the interfaces up (for tap0, eth0, and br0) are required.

The trick to make this work is to use proxy.arp, which allows your pc (not your VM/Linux container/network namespace) to answer ARP queries in their stead.

In other words, by using IPv4 forwarding between your hardware interface and your virtual interface, you think you can connect your VM/LXC/NNS to your LAN as if it were a physical interface, but this is not true: you are forgetting the absolutely fundamental ARP traffic, which is what truly allows LAN to operate. So, the problem is: if I correctly forward IPv4 traffic, how can I also forward ARP traffic, so that my VM/LXC/NNS work? The trick is to use proxy-arp.

The full answer to that is in Bohdi Zazen's Blog, with the revealing title: Bridge wireless cards. He uses an obsolete package, uml-utilities, to create a virtual interface by means of the command tunctl: this is the only command for which he uses uml-utilities, so that you can safely neglect downloading the package, and use the command I wrote above to create a tap or tun interface, whichever you like, just modify the command accordingly. then create a veth pair for your LXC, and now create a bridge between tap0 and veth0. This bridge, called br0, is what you must proxy-arp for, instead of the simple tap0 interface described by Bohdi Zazen.

Sources: askubuntu.com, nullroute.eu.org, firejail.wordpress.com, superuser.com