New install fails: mysterious

I am trying to replace an aging ipcop firewall with ipfire 2.27 x86_64 core update 164
generic PC with AMD Phenom II (4 cores), 8GiB ram
generic red + green setup

green nic: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
red nic: Intel Corporation 82541PI Gigabit Ethernet Controller

I initially connected RED ethernet to my switch:

physical network: ISP – ipcop – switch – ipfire + {multiple internal machines, WAP, etc}

dhcp acquired address from existing nternal dhcpd and everything seems fine. From the ipfire console, ping google DNS, ookla speed test, and pakfire updates are working via red0 (green0 is configured as but not plugged in).

The I swapped the new box in to replace ipcop.

  • from console, stopped network
    [root@ipfire ~]# /etc/init.d/network stop red
    [root@ipfire ~]# /etc/init.d/network stop green

  • swapped ethernet cables from old ipcop machine
    physical network: ISP – ipfire – switch – {multiple internal machines, WAP, etc}

  • run setup to change green IP, and restart network
    [root@ipfire ~]# /etc/init.d/network start red
    [root@ipfire ~]# /etc/init.d/network start green

[root@ipfire log]# ifconfig
green0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet netmask broadcast

red0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet netmask broadcast

  • from /var/logs/messages

    Mar 17 14:19:33 ipfire dhcpcd[6037]: dhcpcd-9.4.1 starting
    Mar 17 14:19:33 ipfire dhcpcd[6040]: DUID 00:04:1e:00:cd:20:00:8c:e2:00:7d:1b:bc:ae:c5:63:17:ed
    Mar 17 14:19:33 ipfire kernel: e1000: red0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
    Mar 17 14:19:33 ipfire dhcpcd[6040]: red0: waiting for carrier
    Mar 17 14:19:33 ipfire dhcpcd[6040]: red0: carrier acquired
    Mar 17 14:19:33 ipfire dhcpcd[6040]: red0: IAID 21:56:1b:66
    Mar 17 14:19:33 ipfire dhcpcd[6040]: red0: adding address fe80::21b:21ff:fe56:1b66
    Mar 17 14:19:33 ipfire dhcpcd[6040]: ipv6_addaddr1: Permission denied
    Mar 17 14:19:33 ipfire dhcpcd[6040]: red0: soliciting an IPv6 router
    Mar 17 14:19:34 ipfire dhcpcd[6040]: red0: soliciting a DHCP lease
    Mar 17 14:19:34 ipfire dhcpcd[6040]: red0: probing address
    Mar 17 14:19:39 ipfire dhcpcd[6040]: red0: leased for 14400 seconds
    Mar 17 14:19:39 ipfire dhcpcd[6040]: red0: adding route to
    Mar 17 14:19:39 ipfire dhcpcd[6040]: red0: adding default route via
    Mar 17 14:19:40 ipfire dhcpcd.exe[6078]: red0 has been (re)configured with IP=

Looks fine, but:

  • ping google DNS
    [root@ipfire ~]# ping
    PING ( 56(84) bytes of data.
    From icmp_seq=1 Destination Host Unreachable

  • ping ISP gateway
    [root@ipfire ~]# ping
    PING ( 56(84) bytes of data.
    From icmp_seq=1 Destination Host Unreachable

  • ping ISP dhcp server
    [root@ipfire ~]# ping
    PING ( 56(84) bytes of data.
    From icmp_seq=1 Destination Host Unreachable

No internal machines can access anything at this point.

I can’t see anything else amiss and haven’t changed any firewall config. The only config change I made was to use the admin UI to enable ssh access (port 222), disable password, enable pub key.

#stumped… swapped ipcop back in for now

Hello Patrick! Welcome to the IPFire Community! Happy St. Patricks Day!

go back to physical network: ISP – IPFire mode for a moment and take a screenshot of menu SystemHome and post it. Tnx!

Here is the screenshot of System → Home

A more conventional topography would be to put IPFire in place of IPCop, not was well as.

How do you authenticate with your ISP ?

The “as well as” was just when installing and configuring… I then swapped it “in place of” the ipcop box.

The ISP in there is a optical network termination (ONT) box with fibre coming in. That thing is registered with the ISP so no further authentication… then cat6 from there to ipfire box.

I noted above that ipfire does get a normal looking IP via dhcp – just like my old ipcop box: same lease time, same gateway, same DNS servers.

The only visible difference is that my ipcop gets a hostname from the ISP’s dhcp server (it shows in the ipcop network status page but has no other use/effect).

Have you tried powering down the IPFire and the ISP box?

Turn on the ISP box first and wait a minute or two. Then power up the IPFire box.

This is my box:

Yes, I have rebooted the ipfire box and the ISP’s ONT (although to be honest I’ve never had to do that before). The ISP does provide a gateway (some sort of consumer router/wifi/switch thing I don’t really trust to be a decent firewall) that I’m not using at all.

Is “Proxy On” (or off) on the main page the http proxy (squid) or a more basic firewall setting? Because mine is “off” (the default).

The simplest and quickest solution can be to re-install, but this time with the IPFire in its intended final place in the topology.

Is the MAC address of your ipcop box registered to your isp by any chance? It is a very thin straw, I‘d give you that. Especially as your box is getting a dhcp response…

1 Like

For my ISP, the MAC address is registered. And rebooting the ISP box re-registers it.

Does the ISP deliver one ore more VLANs that couldn’t be handled by the IPFIRE?

How would I tell that “ISP deliver one ore more VLANs”?

Nothing in the logs from dhcpcd looks out of the ordinary and other clients hooked directly to ISP (old ipcop or my laptop) have any issue getting an IP and working as expected.

Responding to earlier point about trying a re-install with final network wiring in place:

First, that is a pain because it means a longer network outage for other people here trying to work at home :smile: Or have to stay up after everyone goes to bed :slightly_frowning_face:

The theory here appears to be that ipfire saved/cached something from the initial test setup and the steps I took did not successfully clear it when I swapped the cables?

After cable swap, red0 did acquire an ISP-supplied IP and network settings via dhcp. The network, gateway, dns servers, and lease time all look normal for this ISP, yet I cannot ping the gateway from ipfire. I checked routing (netstat -nr) and it looks normal: 192.168.1 → green, default → red.

Anything else I can check to support this “re-install” theory?

This might indicate that you do not have “gateway” correctly configured.

  • if red0 is set “static” (the default) then you have to set gateway before page is done. It is usually the next “hop” from IPFire, but what you have previously used as “gateway” might be further away.
  • if red0 is DHCP, then this should be handled automatically, but can be set manually, if the network is more complex.

Are you permitted to give us a perfunctory sketch of your organisations local network topology ?

1 Like

Hello Patrick,

… the same problems I know.
The best way I found:
Go to IPFire-Console and starting


Configure the network / nic again. This was often the right way for me …


I have run setup to reconfigure NICs when moving into the right place in network topology (mainly to assign to green0 but also re-check red0 was still dhcp) and that does a full “network down” && “network up”… no luck with that.

I will try a complete re-install with the ipfire host plugged into the right place (I’m pretty good at it now and don’t have any customisations yet)… just need a lull in demand (remote work during the day, gaming and netflix at night :smile:) since that’s disruptive.


I finally had an opportunity to reinstall from scratch (ipfire 2.2.7 core 164), made all the most vanilla choices, and still: red0 gets IP address from my ISP, routing looks correct, and yet ipfire machine cannot reach external sites (cannot even ping the gateway - “Network unreachable”).

I was optimistic that someone had taken ipcop and updated/modernised it, but I have to say this is a pretty bad initial experience to fail out of the box like this.


@rodneyp network sketch for the above fresh install:

{ISP} – {ONT} – red0-{ipfire}-green0 – {switch}-- various devices in

ONT = optical network terminator, belongs to ISP, converts fibre to cat6

red0 gets a publicly routable IP addr from the ISP via dhcp; the ONT does nothing special

netstat -nr showed normal expected routing table with ISP gateway as the default.

The only odd thing that goes outside my network-fu is that the arp entry for the gateway was “incomplete” but I don’t know if that’s a cause or effect.


I believe your problem has nothing to do with the development state of IPFire. I have an identical setting to yours and never had any problem. However, I never tried to change my router as well. Networking is a dark and powerful art and unexpected things can happen which are not that obvious and a hasty analysis can lead the blame to the wrong quarter.

To me it sounds like your DHCP lease negotiation is not going as it should, otherwise the arp gateway would be configured and it would not result in an incomplete state. Could it be that your provider does not recognize the ethernet address of your IPFire machine because a previous lease with a different ethernet address (the ipcop machine)?

For example, contrary to @jon provider, my provider warned its customers that its DHCP lease time is 30 min, therefore if a router is changed, we are supposed to switch off the router and the media converter (what you called OTO) for more than 30 min before logging in again. Otherwise, in any earlier connection attempt, the DHCP server will not assign an IP address to an ethernet different from the one registered in its table for that optical termination outlet and the connection will not be made. Depending on the lease time of your provider, you might need to switch off the router and the media converter for more than a simple reboot to allow the table of the DHCP server to be cleared before logging in again.

My ISP doesn’t restrict connecting different devices to the ONT and acquiring an IP lease via dhcp. I’ve tried it with my laptop, the (cheapo) wifi/gateway the ISP provides, my old 32-bit ipcop machine (the one I’m trying to replace)… all of those can acquire a dhcp lease and function immediately without power-cycling the ONT.

The ONT is registered to my account (was done by the tech when they upgraded it from an old model) and there is no further authentication required.