I cannot understand several things from your description. How do the wireless clients connect to IPFire? The Pi3B is also working as an access point? Keep in mind that for wireless devices IPFire has a default block on the Ethernet MAC address. You have to enable them before use. I am not sure if this is also valid when you assign a wireless device to the green network. Hopefully someone else in the community will clarify this point.
EDIT: Now I get it, you have wired your former router to the green interface of IPFire, and by setting it in bridge mode you would use it as an Access Point and therefore it should allow the WIFI clients connected to this AP to receive an IP address in the green zone from IPFire DHCP server. Did I get it right?
If yes, can you see these devices it the DHCP setting of IPFire Web User Interface? Can you see these devices in Routing and ARP table?
My first inclination is the bridged router.
DHCP off.
Fixed ip in same range as ipfire.
Don’t use WAN port as a general rule.
Not all routers like this behavior.
192.168.1.0/24 dev green0 proto kernel scope link src 192.168.1.1
And the ARP Table for one of the offending devices as:
192.168.1.7 dev green0 lladdr 44:eb:2e:e4:4f:f9 STALE
I think stale is bad, but I have some other devices reporting the same despite working.
Perhaps this means not currently communicating (the reported device 192.168.1.7 is on but still not connecting).
I will test @hvacguy in a bit, when there is less happening on the router.
Your ARP entry for 192.168.1.7 indicates that the device with MAC address 44:eb:2e:e4:4f:f9 is on the ‘green0’ interface. The ‘STALE’ state means that while the entry is valid, it hasn’t been actively used recently.
A DHCP entry for the same device suggests that DHCP negotiation occurred successfully. However, the fact that the device is unreachable via ping, despite having a corresponding ARP entry, points to a potential blockage between IPFire and the target device. This could be due to network configuration in your AP, firewall rules (probably not from the IPFire side), or physical connectivity issues. Please let us know if you manage to go to the bottom of this issue.
Keep in mind that the ARP protocol operates at the link layer (lladdr means link-layer address which is the MAC address), which is below the IP protocol (network layer). Therefore it is possible for the ARP request to succeed (hence the STALE flag) but utterly fail on the IP layer, including any echo request/reply (PING).
Alright awesome thats what I suspected thank you lots.
And yes suspected something might be off with the stale entries.
I did today give it another go, and it turns out the router outside of bridge mode works just fine !
So that’s really annoying as I suspect its a problem less with the configuration and more with the router itself. Thanks for guidance and support @cfusco and @hvacguy
When attempting to plug into port other than WAN I couldn’t regain access (I was impatient and should probably test again)
Otherwise I did attempt to emulate the Bridge mode instead. Turning off dhcp, firewall etc.
But this meant no addressed were being passed. I attempted to port forward the dns etc. ports required for connectivity but the it wouldn’t let me port forward an address that wasn’t on the same subnet.
I attempted to change the devices local address range to the same as IPfires but it also didn’t like this.
So I will likely move IPFIRE behind it until I can get a competent WAP, this solution does suck since I can’t configure custom DNS Server on this thing either… Telstra = Locked Down & In -___-
Anyway all the best sorry & thanks for listening to my stupid problems