Red seems to work, but Green does not

I’ve successfully installed IPFire on an Intel Celeron G4900T system, but running into some trouble trying to get it to work.

The motherboard is an EVGA Z370, which has a built-in Intel gigabit NIC, and I’ve also added a dual-port PCIe gigabit NIC (Realtek) card, for a total of 3 NICs. Originally I’d planned on configuring the network as green + red + blue, but seeing as how I can’t even get green to work yet, I’ve decided to just stick to green + red for now, and add in the blue or maybe the orange later.

Here are some pics I uploaded (removed to comply with the ToS) on Imgur which might provide some useful info. They have been given relevant captions.

These are the IPs (pic #1) and routes (pic #2) I’ve set-up. And here are the ethtool outputs for green0 (pic #3) and red0 (pic #4) respectively, which I believe should rule out hardware issues as a cause.

The ISP modem/router gateway has IP 192.168.1.1, and as you can see I gave red0 the static IP (pic #5) of 192.168.1.2. I can ping the ISP’s gateway from the IPFire box fine, and can also reach the outside internet. DNS seems to work as well, since it’s able to resolve names when I do # ping google.com for example.

However when I connected a laptop directly to green0 by ethernet, with a static IP of 192.168.0.200 it’s unable to reach the internet for reasons I cannot figure out. When I do # ping 192.168.0.200 from IPFire, many packets would be dropped, then after a while it’ll be able to reach it, which I also find strange; see pic #6 from link. The same thing occurs (see pic #7) when I do $ ping 192.168.0.1 from the laptop connected to green0.

Here’s a picture of the back panel (pic #8) of the IPFire box for reference. The white ethernet cable on the left connects red0 to the ISP modem/router. The blue ethernet cable on the right connects green0 to the aforementioned laptop. Another potential clue might be that, the orange LED on the green0 is not lit; whereas both the orange and green LEDs on red0 are lit.

In addition to the ISP router and currently IPFire, I also have an OpenWRT wireless AP on the network at 192.168.1.10. Before the addition of IPFire, I also used the AP as the DNS server for my entire network, so I’m not sure if this might be interfering with anything. Though I don’t think it should since it sits on the other side of IPFire’s LAN (green), and I was running into this problem even with that AP off. I’ve turned it back on in order to still provide WiFi access to the rest of my household while I do the upgrade to IPFire.

Lastly here are my ISP’s router settings (pic #9). It runs its own DHCP service, and I’ve just changed its DNS today to using the two external ones (Google, and the ISP’s own name server); but as mentioned above, in the previous working configuration of my network prior to IPFire, the DNS servers on the ISP router were pointed to the wireless AP at 192.168.1.10.

And one last point of peculiarity I found is that, with IPFire half added to my network now, when I connected the earlier laptop directly to the ISP’s router/switch by ethernet, and gave it a static IP of 192.168.1.5, it also could no longer reach the internet. However, all wireless clients that are connected either through the wireless AP 192.168.1.10 or through the ISP router itself (it also comes with a built-in WAP, which I just turned on today as a backup), then they can access the internet.

I’m quite baffled by the situation. Any help is greatly appreciated.

Have you set 192.168.0.1 as default route on the client in green? If not you will not reach the internet.

For the meaning of this LED’s you have to check the manual of the network cards. There are many different color and Blink/stay solid configurations.
This led’s often shows the link speed so if you Router support only 100Mbit and the other 1000Mbit it is different even if the link is Ok.
Sometimes also a cable can have problems.

Please respect our ToS.

  1. You may not hyperlink to images or other non-hypertext content on the forum on other webpages.

Thank you.

Thanks for the suggestions. though $ ip route on the client does show default via 192.168.0.1. However I’m just noticing now that it says linkdown for that route, not sure if that might have something to do with it. I’ll have to try more later tonight.

Apologies, I wasn’t aware. I’ve removed them.

You should post them inside the forum not remove them completely :wink:

I tried to originally, but there were too many lol.

Think I wrote up most of the relevant info (hopefully), just thought the full output shown from the pics might be useful for identifying if I’d missed something obvious, but I’m sensing that doesn’t seem to be the case.

1 Like

Just to bring us back to topic.
Does the problem exist furthermore?
Could the TO describe it in words than in pics?

On the original topic, if you set RED to static, then a gateway must also be set. See the second last screenshot in: setting gateway

Setting RED to static can be useful if the ISP’s router is slow to respond with IP offers.

With the above configuration, workstations using DHCP should be able to access the Internet. Those using static addressing also need a default route set, as mentioned above.

1 Like