Every single client is already in blue access for AP1, and also in the DHCP server , but having now slept on the problem, as you have confirmed, when transiting the bridge, I imagine the relationship between the IP and MAC is broken!
So, a 2 step test today I think:
modify blue access to feature all MACs but no IPs
if that doesnt work, just add the whole x.x.200.0/24 subnet and be done with it .
Fortunately the building B arrangement is transitory! I will test today and post my findings
It’s the same as a Network Switch. As you wrote there is no NAT so you will find the DROP messages in the firewall log for all your clients connected to AP2 with their MAC and IP.
There was already before .
The script messes up with the line numbers/IDs. In the past I had multiple entries with the same line number / ID or many missing. However it was working as long as I didn’t need to touch it. That’s why I don’t update the entries via the web interface anymore. I create an excel sheet with 5 columns: line number/ID, hostname, IP, MAC, description. When I’m done I copy the content to a usuall text editor and replace all tab stops to a comma. After that I replace the contect of the local ipfire file via SSH an nano.
NONE that there a “none” defined is correct, but I agree ANY will be better because that means that “any” will work .
Just to close the thread (as the problem is solved) by summarizing the “lesson learnt”
When planning to wirelessly bridge Access Points with no NAT boundary in order to extend the reach of the blue subnet (For example - To use a remote Access Point 5.8GHz radio in client mode to feed a second 2.4 GHz radio radiating as a standard blue network Access Point)
Ensure that IPFire’s blue access table does not contain IP addresses and MACs in the same entry.
Either / or per line is acceptable, but not both.
Having both ties the IP to the MAC so that when you roam to the bridged AP and forwarded
packets will have a different source MAC, IPFire will drop them - because you told it to!