Is it possible to have a Mikrotik Router function as a bridge non-transparently? Similar to clients behind a wireless access point.
I have two vlans (vlan 1 and 2) on the same switch that I wish to be able to communicate with the same server using the same IP address. I would need to masquerade the MAC address of the server on one of these vlans so the switch doesn’t get confused. I have a number of mikrotik routers that can be used to implement this.
I have a large network of wireless devices that are all on the default vlan, which is 1. I wish to reconfigure their management interfaces for vlan 2, but wish to keep them online using the same IP address during the transition. The clients do not need to speak with each other, but they do need to speak to their gateway and one server.
Currently, I have this arangement:
Core Switch (vlan 1) <=> Gateway Router
Core Switch (vlan 2) <=> (ether2) Mikrotik Router in Bridge Mode (ether1) <=> Gateway Router
I’m attempting to configure the Router in Bridge Mode. I’ve tried Arp-proxy-local, but this responds to all arp requests from the Router, which isn’t good. I would want it to only respond to arp requests from VLAN2. There is also a Bridge NAT feature where I can define src-nat and dst-nat rules for Mac Addresses, but the rules do not recognize or filter mac addresses. I can only capture packets based on the interface they come in and out of.
I am surprised that bridge src-nat and dst-nat do not work for you, the last time I’ve tried it worked fine. However, if all the switches in the network are VLAN aware and support independent MAC learning (the same MAC address may be associated to different ports depending on the VLAN via which it came in), you can do it in a much simpler manner, by temporarily “short-circuiting” the two VLANs on a Mikrotik next to the central switch. Then all devices currently in VLAN 1 will see all devices currently in VLAN 2 through the Mikrotik - just bear in mind that the records in the forwarding databases have some lifetime, hence you need the device being moved from one VLAN to another to actively send something, otherwise the time until the switches start broadcasting the request frames for them could be stressful for you.
Assume that the “MacGyver” Mikrotik is connected to two different ports of the central switch using its etherA and etherB. It could probably work even using a single port but that way it sounds weird even to me. So on the central switch, the port connected to Tik’s etherA will be an access port to VLAN 1 and the port connected to Tik’s etherB will be a trunk port where only VLAN 2 will be permitted. Disable STP on both ports (make them edge ones) to prevent one of them getting eventually blocked by STP. On the Mikrotik side, STP should be blocked too using the bridge filter at the VLAN 1 access port and using the filtering of tagless frames at the VLAN 2 trunk port. You’ll be managing the Mikrotik via some other port.
Hello Sindy, Thank you for your help and attention. It’s greatly appreciated.
Unfortunately, my switches do no operate independent mac-address tables. One port per mac address. Because of this, I must masquerade my servers mac address on one of the two vlans.
Here is another simplified summary of what I have setup so far:
Core Switch with two vlans (vlan1 and vlan 2). I provide two access ports untagged for vlan1 and vlan2.
My Mikrotik has untagged access to vlan1 on ether1 and untagged access to vlan2 on ether2.
I create bridge1, add ether1 and ether2 and set a horizon on both ports to prevent the two ports from communicating with each other.
I plug my server into ether3 and add ether3 onto bridge1: This server can now communicated to both ether1(vlan1) and ether2(vlan2).
The core switch sees the mac address of the server on both of the access ports and gets confused. I need to masquerade/NAT the servers mac address on one, but not both ports.
That’s also clear. I’ve found what I wrote on the subject some time ago, and at that time I was testing that. So please read this and don’t forget to read the last post, it is also relevant for your scenario. Back then the purpose was to hide one particular IP address, which has lead to matching on IP address rather than on MAC address in the rules, which may explain why I couldn’t notice that matching on MAC address didn’t work, but that should not be an issue in your case either. The last post deals with ARP handling, and it is also important in your case.
It just dawned on me… have you set hw=no when adding the ports to the bridge? /interface bridge port add bridge=bridgeX interface=etherY hw=no? If not, neither the bridge rules nor the split horizon can work at all because the frames bypass the software bridge inside the switch chip.
I’ve made progress, but I’m not sure I’m there. The bridging table on the client device is only showing the NAT’d mac addresses, which is good. However the IP arp table still show the original mac of the server. It seems the part I’m missing was the part addressed in your last post. Take a look at my filter below. Does this look correct?
It looks correct to me, but I’d disable the use-ip-firewall-for-vlan because it might interfere with the bridge filter operation (not sure about that, though).
I’d also remove the in-bridge and out-bridge match conditions from the bridge firewall rules, as the interface (ether2) is a member of exactly one bridge. And maybe the in-bridge and out-bridge work different than we expect.
If the above doesn’t help, the next thought is that some IP stacks learn MAC addresses into their ARP tables from any incoming ARP traffic, not just from responses to the requests they’ve sent themselves; if this is the case with your devices, I’m afraid that there is no way to prevent them from learning the real MAC address of the gateway except dropping all the ARP traffic between ether2 and the router-facing port and using action=arp-reply rules (one per device in VLAN 2) also to respond the arp queries sent by the gateway router (with the real MACs of the devices). The thing is that the MAC address of the sender is not only in the header of the Ethernet frame carrying the ARP packet but also in the body of the ARP packet itself, and the bridge nat rules cannot NAT both (that’s basically the reason why the action=arp-reply exist).