Layer 2 forwarding between wlan-client and Ethernet interface

Installing and Using OpenWrt
1

This post is a follow up of a previous post (btw now I'm using upstream openwrt).

To go around the 802.11 lack of bridging capabilities, relayd can be used to masquerade the MAC addresses between the interfaces. It acts essentially as a layer 2 NAT: devices on the ethernet side will see every device on the wifi side as having the router's mac, and vice versa.

I'm now trying to get a simpler, full layer 2 forwarder over wireless, i.e. a single-pair bridge where the dst MAC of incoming LAN frames is replaced with the remote device's MAC, and the src MAC of outgoing MAC frames is replaced with the forwarder's MAC.
We must also make some exceptions to allow the forwarder device to be individually addressable; In a real use case, the forwarder can be use to bring a (single) remote device "into the LAN" over wifi, down to layer 2. Layer 2 access is commonly required for network monitoring purposes.

I think I should be able to achieve this with ebtables:

ebtables -t nat -A POSTROUTING -o phy0-sta0 -j snat -p IPv4 --ip-source <device ip> --snat-arp --to-source <forwarder mac> --snat-target ACCEPT
ebtables -t nat -A POSTROUTING -o phy0-sta0 -j snat -p ARP --arp-ip-src <device ip> --snat-arp --to-source <forwarder mac> --snat-target ACCEPT

ebtables -t nat -A PREROUTING -i phy0-sta0 -j dnat -p IPv4 --ip-dst <device ip> --to-dst <device mac> --dnat-target ACCEPT
ebtables -t nat -A PREROUTING -i phy0-sta0 -j dnat -p ARP --arp-ip-dst <device ip> --to-dst <device mac> --dnat-target ACCEPT

This doesn't work. Neither device sees devices across the forwarder.

I wonder if there's some fundamental reason of why this is not working, or other OpenWRT (routing) components interfering in what is basically switching trickery.

I've also toyed around setting up wds as shown here but I suspect the hardware is just not there.

I've also tried setting up a gretap tunnel between the forwarder and another scavenged openWRT device "B" to cross the wifi connection. The device B does the bridging over ethernet (but it cannot do the remote tunneling, it uses an outdated customized build).

image

Devices across the forwarder can ping each other and see each other's MAC, but iperf -uR reports traffic only in one direction. Strangely, the device and the forwarder can't ping eachother.

Note that the device, forwarder, and B are all in the same network, but the forwarder's remote tunnel port has an IP of another network. This is analogous to a relayd setup:

image
image801×424 56.7 KB

1 Like
2

Please post output of

ubus call system board
ebtables -V
nft -V
3 
{
	"kernel": "5.15.167",
	"hostname": "OpenWrt",
	"system": "Qualcomm Atheros QCA9533 ver 2 rev 0",
	"model": "GL.iNet GL-AR300M16",
	"board_name": "glinet,gl-ar300m16",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.5",
		"revision": "r24106-10cc5fcd00",
		"target": "ath79/generic",
		"description": "OpenWrt 23.05.5 r24106-10cc5fcd00"
	}
}

ebtables 1.8.8 (nf_tables)

nftables v1.0.8 (Old Doc Yak #2)
  cli:		no
  json:		yes
  minigmp:	yes
  libxtables:	no
1 Like
4

Probably upstream example can help to transcode rules to bridge firewall?
https://git.netfilter.org/iptables/tree/extensions/libebt_dnat.txlate

5

Please. It's a layer. Not a level.

1 Like
6

And that's not all, I'll tell you a funnier thing: as a MS CS student, I've dealt on and off with computer networks since 2015, algorithms, terminology and whatnot. And still I manage from time to time to butcher some well established english translation🤣 I apologize!

4 Likes
7

Nat in layer 2 is level 99 task.

8

Hello👋🏻, buddy of @KayJay7 here.
I want to make a further attempt to better explain the issue at hand.

We want to bridge a remote device to our network using a local forwarder (openWRT router) connected as a wifi client. As we know wifi doesn't support bridging so in this situation MAC masquerading is used, usually through relayd. We imaginatively called this "layer 2 NAT" because it's similar to what ebtables calls snat/dnat. In hindsight, it probably behaves closer to a router: incoming/outgoing frames gets their src/dst MAC replaced with the router port/ARP entry MAC.

I'm not sure of the details, but some of the things relayd also does (..differently than a router, at L2) are:

  1. cross wifi, as a side-effect of replacing src MAC in incoming (device->forwarder) packets
  2. let through DHCP broadcasts
  3. tweak ARP replies: this is done symmetrically, and thus outside devices have ARP tables where all IPs across the forwarder have the forwarder's MAC.
  4. route packets, again symmetrically. dst MACs are replaced with the actual destination across the forwarder, obtained from ARP table. This is an educated guess of mine.

Point 4 is something ebtables can't do (replacement from ARP), but we do not need this. We have a only single device outside the forwarder.

Point 3 is an issue. While it is required on the LAN side to make wifi work, we want the outside device to receive the original ARP replies with the respective MACs. For technical reasons, we are forced to do this this way. The device is, among other things, a network monitoring security tool.

This should be simple with ebtables, we used the commands listed in the first post.
Hope to have made it technically clearer, but should really be hard to explain, not hard to do.

The second part describes a more advanced alternative approach with gretap (which didn't work either). Albeit more versatile, it is also a bit inefficient. Not fond of it.

2 Likes
9

If you want to bridge layer 2 domains, did you considered using frr and bgp with evpn?

10

Yes, but we cannot bridge directly, as the forwarder is a wifi client. We're using zeroTier as a remote layer 2 tunnel. There must some MAC masquerading to cross wifi, but only on the LAN side. relayd is symmetric in this.

11

I'm not really sure I can follow you...

Normally any wifi interface is attached/enslaved to a bridge. We do this on site-1 and site-2; and between both sites we have any type of a layer-3 tunnel and that we use to transfer the encapsulated vxlan packet which contains the (layer-2) frame.
The distribution of the mac addresses and the VTEP addresses is done by EVPN. I'm not sure where and when any of the layer-2 fiddling enters the game...

Edit: To extent that. I think it is in general and most of the time a really bad idea to stretch a layer-2 between remote sites especially if they are far away. And far away can even be a few kilometers apart... however, with vxlan/evpn it has gotten at least a little bit less painfull because most of the frames got encapsulated and transported via a tunnel (layer-3), and not in a "classical" way where you have to deal with STP, or ProxyARP, or even "layer-2 nat". And btw... really? layer-2 nat?! i'm clad I've never heard of that before. It sounds kinda scary to me.