No internet on select green devices

Set up is as follows:

ISP Modem → IPFIRE (Pi3B) → Router-InBridgeMode (WAP/Switch) → Managed L3 Switch (Can ignore)

The primary focus to me is the wireless connections of 2 device (Old Samsung TV & Thermomix TM6)

Both devices worked with the default Router before the firewall on it was disabled and bridge mode activated.

All other devices connect without issues immediately, hotspotting the afflicted devices works just fine.

I can see they have the correct IP’s and manually assigning google or cloudflare DNS doesn’t progress them.

I can ping them from other devices on green just fine. (192.168.1.0)

I have opened up all firewall rules to no avail (temporarily).

On a side note the firewall (ipfire ssh’d) cannot ping any clients on green, only gateways & itself

I have also disabled the IPS and some other default blocking protection stuff.

These firewall logs report nothing on these IP’s

I should note researching the thermomix has proven to be concerning with its connectivity issues, as well the old TV is on its way out.

The exact details on connectivity is they connect but both say lack internet and cant access their respective services (account logins and searches).

I do not use any of the proxies or anything, very basic setup so far.

I should disclaimer that I do not have a lot of experience setting up firewalls.

Hello @juiceboxdrinker and welcome to IPFire community.

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?

1 Like

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.

2 Likes

Hey thank you for the welcome !

Yes that is exactly correct, I should have explained it better my bad.

I do have BLUE, but that is functioning like a VLAN when it hits the switch.

I have the dedicated BLUE wireless configuration allow the whole subnet to work (mac address filtering off)

Having green devices be wireless I didn’t think would cause an issue, but maybe somehow it is?

I can see the leased addresses in the green interface are correct as the device is getting.

I will check the routing and ARP Table in a few minutes thank you for the suggestion and sorry for the confusion.

That’s possible, it’s a telstra LH1000 - I do not trust its construction ahah.

I will turn DHCP off on green and assign those 2 devices a fixed IP.

They were already on the same range as IPFIRE so I’ll just make them fixed now outside the initial IP distribution Range to be sure.

That’s interesting, I that would not have ever occurred to me; I will change the port off of the WAN port on the router too thanks for the suggestion.

I have the Route Table as:

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).

2 Likes

Sorry for the long absence

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 :slight_smile:

2 Likes