Core Update 170: No Internet


I updated from 169 to 170.
Internet ist not working.



The rules were working in 169, but with 170 ist fails.

Ist there any way to go back to 169 (easil)?

Or ist there another workaround?

Thanx for your help.

Hi Thorsten - Welcome to the IPFire Community!

The details of your issue are a little vague so it is hard to offer advice on how to fix.

To go back to Core Update 169, make sure you have a backup copied to another device (like a thumb drive)

Here is info about backup (and restore) here:

Here is a download of Core Update 169:

1 Like

Thanx for the answer.

What I want so say is:

The LAN Adapter in the PC that is connected to the Ipfire-PC is rejected since the Update 170.
Nothing has been changed.
Every package send to or from this LAN adapter is answered by “drop Input” “drop Forward” with this “netbios dgm” message.

The IP of the LAN Adapter is and is connected to the ipfire ( The ipfire ist connected to a Fritzbox (

That has been working correctly since the Update to 170.

Are you able to look at /var/log/messages and ifconfig from a console ( directly connected,not via SSH )?
I suppose your IPFire can’t establish an internet connection using the Fritzbox ( in router mode with double NAT?).

The Computer directly connected to the ipfire (via Switch) can not Connect to the ipfire.
Not by ssh or Ping or something else.
Others PC connected (via Switch) can. (Ping working)
So I was thinking it has to do with some kind of firewall in the PC itself, but nothing has changed there.
Disabling any Security in that specific PC doesn’t change anything.
As I said: the Same configuration worked before the 170 Update.

If you can access IPFire from other devices, just look for blocking messages for in /var/log/messages or the logging pages in WebGUI.

1 Like

Here is a screenshot of the problem.

Allowing everything for in the Firewall rules, won’t change anything.

Could you be a bit more specific about your configuration?

  • how are the devices connected?
  • how is your FW configuration?
    Your smartphone( :roll_eyes:) screenshot shows messages for red0 ( the WAN interface ) only. Are there other DROP_xxx messages on other interfaces? Is the logging on green0 and/or blue0 enabled?
1 Like

I’m trying to discripe my setup.
Perhaps that helps.

PC (

Ipfire (

Fritzbox ( Routing to Red)

Kocobox (, it’s for the Telematic Infrastructure for medicine in Germany)

The Kocobox is connected to the Fritzbox.
The Fritzbox ist connected to ipfire (Red)
The PC ist connected to ipfire (via Switch, Green)

Before the Update everything was working.
The PC could connect to the Kocobox and vice versa.


Ping from Kocobox to ipfire ( working!
Ping from Kocobox to Fritzbox ( working!
Ping from Kocobox to PC ( NOT working!
Ping from PC ( to ipfire NOT working!
Ping from PC ( to Kocobox NOT working!

Thanks for your description.

As far I can see, you have a nearly standard configuration.
LAN ( including your PC ) connected to green0 of IPFire ( I suppose the switch is a stanard one ),
IPFire connected to WAN constructed by the Fritzbox router as gateway.
For connections initiated by the Kocobox you need a port forward rule in IPFire. The other way around should work out-of-the-box.

It’s a standard Switch. :wink:

To be more detailed:

In the Kokobox:

  • redirection of Intranet ist enabled.
  • Routes are set to and

In the Fritzbox:

  • the traffic is “routed” to the Red ipfire (
    -a static route to

In ipfire:

  • a firewall rule ist set to

allow to with all Protokolls and NAT

It’s not working either way. :frowning:

Your PC isn’t but

Maybe your (wrong) config was accepeted by CU169, but not with CU170. See discussions about RPF.

Right. The PC ist ist the ipfire

Sorry. Forgot to say:

Fritzbox has route to as well.
(Box can’t manage

So can you point me to where my config ist wrong.
It seems I’am to dump to see. :grimacing:

Ist there an easy way to change the RPF strictness?

We do not know, whether it is the RPF strictness. But you can test it. See the threads in our forum.

For your network, it isn’t easy to help without knowledge of the exact settings.
Not knowing the configuration of the Fritzbox and the Kokobox, it would help if you could specify the functionality these devices realize in your installation and how they are configured ( in a more general manner ).

This is no offending. But my experience is, that describing of a system by the admin helps a lot ( for the helper and the admin ).


I’ll try.

The PC runs a dental Software with IP at the LAN Adapter.

The patient has to put his/her health insurance Card in a Orga 6141 (

The software calls the data from that card and checks online via the Kocobox ( if the card ist valid and tells the software.

To avoid a more complex system setup, the Kocobox and Cardreader are installed parallel to the “Intranet” (ipfire), because there is enough security measures installed in the Kocobox, so it does not need to be behind a additional Firewall.
The Kocobox and Card Reader can comunicate without a Problem.

The Kocobox is connected “directly” to the Card reader via the Fritzbox.

As I said: there hast been no single change for the PC, the Kocobox, the Card Reader…it worked with 169.
But after the Update, the LAN Adapter can not connect to the ipfire, the Card Reader, the Kocobox, nor the Internet.

So my first thought was, that the Update caused that.
I checked and changed LAN cables etc.

Windows ist allowed to accept packages from other subnets.

Tomorrow I will hopefully try the RPF thing.

Just a thought. Are the NICs of all PCs in the intranet the same?
Maybe there are problems with the NIC of your PC.

EDIT: @ntb857 If you don’t want to disclose your exact system, I send you a PM.

I don’t think that all NICs are the same. I think mostly Realtek. But wich rev…?
But I can check this.

I can post the full system settings. But will do it tomorrow (hopefully), because I don’t have Access to all Systems from home.

What came in my mind:
After the Update to 170, I could once SSH to ipfire and access the webif of ipfire.
After that…dead.

Did you check the ip of the green interface after the update? On the starting page green should be listed as A /32 could explain that behaviour - or a completely different ip. Though I don‘t know how your config could have been changed in an update.

The IP of Green ist Nothing changed.