7.20.6 bug(?) with routing traffic coming across wireless station-pseudobridge

RouterOS General
1

Very weird and frustrating problem here. UniFi wireless setup with dsl router. Had to move the router to the other side of the room as the telephone wiring under the room had degraded. No wired networking on the other side so I put in a HAP AX2 to run a wireless bridge (router was ISP managed). Ran it on the 2.4GHz band for range as the line tops out at 25Mbps. All good, problem solved, went home. A day or so later, it all falls apart and nothing is working. After a bit of poking it all starts working again for a few hours. I've tried switching to 5GHz, getting the ISP's router switched to modem-only so that our HAP is in control and I can get access etc. Also set up Dude to monitor all the infrastructure and put it all on static IPs. It went down again today and I managed to get some diagnostics.
Dude said everything was reachable and up. I could access it all from a wireguard VPN I set up. Plugging a laptop in to a switch on the far side of the wireless bridge, I could ping everything locally and access the HAP but I couldn't ping the internet. I could see the icmp packets arrive at the HAP by torching the wifi interface but nothing was being routed out to the internet. Reboot the HAP and all good again but probably only temporarily. Everything worked if I connected to the HAP over wired ethernet so I've run a network cable and taped it to the skirting boards to get us to next year. Has anyone seen this or know of something I'm missing?

Slightly trimmed code - the extra IP on bridge was for an IPSEC connection allowing that single IP to a single IP at the other end of the tunnel, just for remote access before the ISPs router was put in modem-only mode.

Many thanks,
Gareth

/interface wifi
set [ find default-name=wifi2 ] channel.band=5ghz-ax .skip-dfs-channels=10min-cac .width=20/40/80mhz configuration.country="United Kingdom" .mode=station-pseudobridge .ssid=<SSID> name=wifi-5GHz security.authentication-types=wpa2-psk .ft=no .ft-over-ds=no

/dude
set enabled=yes

/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=wifi-5GHz
add bridge=bridge comment=defconf interface=wifi-2.4

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=Claranet list=WAN

/ip address
add address=192.168.0.1/24 comment=defconf interface=bridge network=192.168.0.0
add address=10.1.245.1/24 interface=bridge network=10.1.245.0

/ip dhcp-client
add comment=defconf interface=ether1

/ip pool
add name=DHCP-Pool ranges=192.168.0.50-192.168.0.159

/ip dhcp-server
add address-pool=DHCP-Pool interface=bridge name=DHCP

/ip dhcp-server network
add address=192.168.0.0/24 dns-server=192.168.0.1,208.67.222.222 gateway=192.168.0.1

/ip dns
set allow-remote-requests=yes servers=208.67.220.220,208.67.222.222

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid log-prefix="Drop Input invalid:"
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow Remote Management - Winbox" dst-port=8291 protocol=tcp src-address-list=RemoteManagement
add action=accept chain=input comment="Allow Remote Management - SNMP" dst-port=161 protocol=udp src-address-list=RemoteManagement
add action=accept chain=input comment="Allow Dude SNMP" disabled=yes dst-port=161 protocol=udp src-address=192.168.0.1
add action=accept chain=input comment="Allow Dude DNS & SNMP" dst-port=53,161 protocol=udp src-address=192.168.0.1
add action=accept chain=forward comment="Allow Remote Management - RDP" dst-port=3389 protocol=tcp src-address-list=RemoteManagement
add action=accept chain=input comment="Allow Wireguard" dst-port=13231 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="Allow Wireguard DNS" dst-port=53 in-interface=wireguard protocol=udp src-address=172.20.1.0/24
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log-prefix="default drop: "
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid log-prefix="Drop fwd invalid: "
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=reject chain=forward comment="Reject egress to RFC1918 address ranges" dst-address-list=RFC1918 out-interface-list=WAN reject-with=icmp-network-unreachable
add action=reject chain=output comment="Reject egress to RFC1918 address ranges" dst-address-list=RFC1918 log=yes out-interface-list=WAN reject-with=icmp-network-unreachable
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
2

Maybe related, maybe not (your settings for bridge are seemingly missing) when using station-psdeudobridge in some cases (all?. most?) you need to disable rstp on the bridge, usually this is connected with DHCP issues, but it costs nothing to try, i.e. setting protocol-mode=none.

But 7.20.6 has been reported as having many (some evident, some less so) bugs/problems, so maybe it would be better if you temporarily downgrade to 7.20.2 or 7.20.4 (or even a 7.19x) version.

3

Thanks Jaclaz. That might have pointed me in the direction of why it failed over the wifi link but not the wired. Pseudobridge does MAC NAT and that might be what's falling over after time.
You're right about my bridge settings - I didn't include them as there was nothing other default but that means it's in RSTP mode. I'm not sure if I had DHCP issues; there was definitely something going on with the UniFi Cloud key (wifi controller) on the far side of the bridge reporting IP conflicts. That might be the MAC NAT causing issues though.
So it's possible I may have got away with station mode if I could route the traffic over the wireless link or otherwise in station-bridge mode if I put another HAP AX2 at the other end of the link so that it was Mikrotik at both ends. That is something I was looking at as a possible solution but the situation was that the customer's patience was wearing severely thin....and on a purely selfish note, I really didn't want to get call-outs over Christmas! :smiley:

4

When you want a transparent connection over a WiFi link that does not support bridge, like when you connect between different manufacturers, you can consider setting up an IPIP, GRE or even EoIP tunnel over the connection. Of course only possible when the router at the other end has some of those capabilities.

Indeed it is a nasty problem, so terrible that the 802.11 standards tried to get away with “3 address mode” and the solutions invented by different vendors are mutually incompatible… That even affects MikroTik itself, where wireless bridge is incompatible between new and old models from the same company.

5

I didn't have anything at the other end that could do any of those in this case. Definitely a possibility for scenarios where there is a box at each end but mixed vendors but in this case, I'd have put another Mikrotik box at the other end and then, if I'd been clued up enough, I'd have selected station-bridge and it would have worked. It does seem oddly short-sighted that the standards don't allow for wireless bridging - or provide a standard extension to make it work.

6

Yeah, it was stupid from the beginning. Bridge mode should have been standard and default for all connections.

I think the newest standards support bridging but of course in a way that is incompatible with the existing implementations, so it still only works when everything is new. As you know, it would work between two AX models, but I think it would also work with similar models from another manufacturer. Not sure, it may be that BE is the minimal version for that.