Red seems to work, but Green does not

Getting Started with IPFire
1

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.

2

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.

3

Please respect our ToS.

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

Thank you.

4

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.

5

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

6

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

7

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
12

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

13

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
14

Sorry, I didn’t have time to try again yet (had to put in some over time the last couple nights for a work deadline today). But I’ll give it a try again tonight and report back with results, and more details if applicable.

15

I will double check later tonight, but I’m 95% sure I did set the default gateway for RED to 192.168.1.1, which is the IP for my ISP’s router.

16

Simplest way to isolate the problem would be to set any workstation to “auto” or “DHCP” (depends on OS). If that can then access the Internet, then IPFire is suitably configured. The problen is then in the configuration of static addressing in other workstations.

2 Likes
17

Okay so I tried doing that using a new laptop from the one I used during my first attempt. And wasn’t able to get an IP assigned to it by the DHCP server provisioning IPs for the GREEN network, which I’d checked to make sure was configured properly as well.

I also made sure the NICs on the laptops were functioning, by wiring them directly to the router again, which has its own DHCP server, and that worked.

So at this point, I decided to swap the GREEN and RED interface assignments on the IPFire box just to see. And what happened was that RED has problems being connected to, with the internet basically being unreachable now. If I configure RED to receive its IP by DHCP from the upstream ISP router, then it just seems to never be able to get one; but when it was using the good Intel NIC built into the motherboard, that wasn’t a problem. And when I instead assign red0 to using the static IP of 192.168.1.2 as I did initially, but now on one of the two Realtek NICs on the PCIe card, it would be able to intermittently reach out of the RED network and ping the ISP router, or even google.com for example. But with massive and unpredictable latency, just as was the case when this NIC was being used for GREEN. Which is working perfectly now that it’s on the Intel NIC. Able to get assigned an IP by IPFire’s DHCP; and when I connected both laptops into GREEN via a dumb switch, both got IPs too, and were able to ping each other.

So in short, I’m beginning to suspect it’s the PCIe expansion NIC card that’s the problem. I didn’t think this was the case initially since I saw in some other threads people were telling users to check the interfaces using ethtool, and when I did that both interfaces from the PCIe card were detected. Then again I did get this card off eBay for <30CAD from China, so… If this is indeed the case, then I’m really going to kick myself, since more legit looking ones from Amazon are maybe 10-15 bucks more.

Is there a definitive way to determine if the interface hardware is the problem? Like some utility command? ethtool doesn’t seem to do the trick here for my case. And do you guys think my hunch is right that it’s likely this hardware that’s causing the issue?

18

When you have a suspect NIC configured as a zone in IPFire, try running “ifconfig”. It should report the status of each NIC. If not working reliably, you could see a double-digit percentage of errors. If the NIC is generally working, but a mis-match of speed to the other end of the Cat 5 cable, then you might see a few percent of errors - which might be tolerable.

2 Likes
19

I bought a new NIC (Intel chipset) off Amazon, which got delivered to me in about 12 hours (Amazon Prime is pretty clutch sometimes). Swapped it out for the Realtek PCIe card I was using. Re-installed IPFire, configured GREEN + RED, assigned the interfaces appropriately, and used the same settings as I did on my first attempt. And everything worked out-of-the-box.

So looks like the hardware was indeed the issue. Sorry for the fuss. Though thanks to everyone, especially @rodneyp for all the good diagnostic tips, which eventually lead me to pinning down the underlying cause.

Learned my lesson: don’t be overly cheap with trying to save 10-20 bucks by buying from dubious Chinese eBay vendors, their (likely fake) good ratings notwithstanding.

2 Likes