Okay, I finally got a 1-to-1 MAC-NAT to work *almost* completely successfully. I'm not really sure what I did differently this time as I could've sworn I tried exactly the same thing before, but whatever.
The only stipulation is that at the same time, I was able to verify my theory about DirectWireless's DHCP question as well...your DHCP server must have "always-broadcast" set to "yes" (if this is a MikroTik DHCP server...use the equivalent option on whatever it is you use if it is not MikroTik) if you want DHCP to cross the "bridge" successfully, even with the MAC-NAT rules in place. When I turn that "always-broadcast" option off, the DHCP server sees the REQUEST, sends an OFFER, but the client never sees the OFFER and so just sits there, sending REQUEST after REQUEST ad infinitum
. (I'm not actually sure why this is, though...maybe it's because the MAC of the DHCP client is included in the payload of the DHCP packet in addition
to the ethernet frame header, and in a MAC-NAT situation these values will not
match because MAC-NAT changes the source address in the frame header only. The DHCP server is *probably* sending the reply back unicast to the MAC that was embedded in the DHCP request instead of the source MAC address according to the ethernet packet header. Just a guess.).
Furthermore, ARP does not seem to get bridged correctly, either. There is a patchwork way around this which I will demonstrate in my example (below), but you will have to know the MAC address of your gateway and statically program it into the MikroTik CPE. If the MAC of the gateway changes, then you will need to change the NAT rule in all the clients that you have set up this way.
Also, as has already been discussed, there is no "masquerade" option, so you can *only* "bridge" one ethernet MAC over the wireless link with this technique. So all that this will allow you to do is to offload your routing from the MikroTik to whatever is plugged into the ethernet of the MikroTik. You will not be able to plug a switch in with a bunch of devices on it.
Okay, on to the example. Here's what I did:
/ interface bridge
/ interface bridge port
add interface=wlan1 bridge=bridge1
add interface=ether1 bridge=bridge1
/ interface bridge nat
add chain=srcnat src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF \
add chain=dstnat dst-mac-address=00:55:44:33:22:11/FF:FF:FF:FF:FF:FF \
add chain=dstnat mac-protocol=arp arp-opcode=request \
arp-src-mac-address=00:11:22:33:44:55/FF:FF:FF:FF:FF:FF action=arp-reply \
00:11:22:33:44:55 == the MAC of the ethernet device you wish to bridge
00:55:44:33:22:11 == the MAC of the wireless interface in "station" mode
00:77:77:77:77:77 == the MAC of the gateway for your IP subnet that lies beyond the AP you're connecting to
The first two rules should be pretty self-explanatory. The third MAC-NAT rule says that if the ethernet device sends an ARP request that gets broadcast over the bridge, then automatically generate the reply to that device locally on the MikroTik CPE. If you elect not to do this, you will have to end up adding a static ARP entry on the device connected to the MikroTik via ethernet (which also works fine).
Interestingly, PPPoE works perfectly fine over this pseudo-bridge, even though unicast DHCP and ARP do not. Go figure. Obviously, if you're using PPPoE, you don't need a NAT rule to auto-generate replies for ARP requests.
Hope this helps,