AP2 is bridged wirelessly to AP1 as a client of AP1 - there is no NAT
DHCP relay working perfectly, clients get same IP address in either building
Clients on AP2 can ping IPfire (.254)
Clients on AP2 can browse and print from the printer on AP1
Clients on AP1 - which is in the same subnet as AP2 can go to the internet
The same client when walked over the road to AP2 cannot
No clients on AP2 can get to the internet. nor can AP2 obtain NTP from IPFire
I have added All 3 of AP2s NIC MACs into “blue access”
I feel certain this is a layer 2 MAC issue , but I have put in a good few hours today and cannot
resolve why IPfire drops all forwards from AP2 , be they DNS lookups or web access .
Anyone got a suggestion that doesnt involve digging up the road or stringing ethernet between the two
buildings please (neither of which are feasible)
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!
.
.