Trying to troubleshoot IPTABLES issue

I stumbled across this as I was watching the IPFire boot. There is not error on the firewall.cgi screen or the messages log.

I am trying to troubleshoot an issue with IPTABLES but I cannot find the errors in the logs. I dug through /var/log/messages but there is nothing located there.

Setting up firewall
iptables v1.8.7 (legacy): host/network `none' not found
Try `iptables -h' or 'iptables --help' for more information.
ERROR: iptables --wait -A FORWARDFW -m mac --mac-source x4:92:9x:x6:67:10 -d no
iptables v1.8.7 (legacy): host/network `none' not found

I see 20+ of these errors on boot.

This may be related to:

IPFire 2.27 (x86_64) - Core Update 159

Hi Jon,

Under Firewall Groups I have Hosts, Network/Host Groups, Services and Service Groups defined which I then use or have used in Firewall rules.

I don’t see those iptables messages that you see.

This suggests to me that one of your group rules has an error in it. It seems to be looking for ‘none’.

What has been created in Networks, Hosts or Network/Host Groups.

Many (most?) all of my Firewall Rules have a MAC address. And those are the ones that ERROR.

x is not a valid char in hexadecimal (unless you masked the actual mac for privacy).

Yes, the MAC address was sanitized for my protection :slightly_smiling_face:

What’s the group definition for the affected MACs and how is the group used in firewall rule?

1 Like

Here is one that is a little simpler AND also has the same error:
Any device in BLUE0 (my wi-fi) network can have access to my Mac on one port.

Here is Firewall Rules (FR) Host:

Nothing is in FR Network

Here is FR Network/Host Groups:

FYI - I originally created the group with one MAC address and one IP address for the same device. But I tried to make it simple and I removed the IP address but kept the group.

Here is the error for this device (only seen at boot up):

iptables v1.8.7 (legacy): host/network `none' not found
Try `iptables -h' or 'iptables --help' for more information.
ERROR: iptables --wait -A FORWARDFW -p tcp --dport 10631 -s -d none -i blue0  -j ACCEPT = my BLUE0 / wi-fi network

Hi Jon,

You are using the group name iMac3 as a destination. I think that is your problem, because the group has hosts using mac addresses and those can only be used for the source, not for the destination.

If you try and put a mac address into the destination of a firewall rule you will get an error message but if you put a host group in then it accepts that. If you put a host name in that uses mac addresses you will get an error message. Maybe this is a bug that needs to be raised, that it should check that the host group only contains ip addresses if used as a destination as it does for the hosts.

1 Like

Hi Adolf,

your explanation is plausible.
So we have to raise a ticket in bugzilla. Maybe there are more cases where errors in rules are not found because of indirection.

I confirmed that when I used my host group that uses hosts with mac addresses and put it in the destination field it accepted the rule without an error.

I just had a look through the code for the firewall page and it does check if there are mac addresses in the host group but it doesn’t give an error it generates a hint which is supposed to say

'The destination group contains MAC addresses, which will be skipped during rule creation.'

However I couldn’t find that hint being displayed anywhere on the firewall page when creating the rule or applying it.

The code looks to just be checking if at least on of the entries in the host group is a mac. It doesn’t check if all the entries in the host group have a mac address because then the overall rule becomes invalid.

I will have to have a look at how these hints are supposed to work.

I have also confirmed that if I create the host group with hosts with mac addresses and create a rule from them and activate it and then reboot, I see exactly the same messages that Jon found.

Thank you for looking into!

So does this mean a MAC address should never be a destination for an IPTable?

EDIT: found this - see Attention:

I gave the above a try. First I removed the MAC address from the group to then added the MAC address directly to Destination address (IP address or network) and I saw the expected error message.

Then I removed the MAC address and replaced with the IP Address (w/ DHCP Lease). The Rule saved fine!

But then I had to reboot and monitor with Serial Console to make sure the error was truly gone. It was!

So. Is it possible for a IPTables boot up Error message to be added to the messages log?

Haven’t looked into the sources, yet.
But a error at boot time is too late!
The WebGUI should not produce erroneous IPtables rules.
Faulty settings in the UI must be rejected with an error message.

In the source code they just have a hint not an error message (separate problem that the hint does not show up).
I think the reason they have only a hint for a host group is that it could be made up of a combination of IP’s and MAC’s and that would be fine for the source entry. For the destination entry the hint is supposed to show up and tell you that

‘The destination group contains MAC addresses, which will be skipped during rule creation.’

So the rule will only be created with the entries in the host group that use IP’s.

However if you have a host group that has only MAC’s and no IP’s then that test ends up not using any of the entries and you end up with a ‘none’ in the destination which then gives you the error when you boot.

I think that making the hint work so it can be seen by people is one action.
The second is probably that the test also needs to see if there are any IP’s in the host group at all and if not then to have an error message.

So this issue needs to be raised as a bug.

1 Like

Add to this one?

or create a new bug?

1 Like

That is exactly the problem. Apparently the hint not being shown was being worked on in a patch but it has never been merged. So that explains why I didn’t see the hint - it hasn’t been fixed yet.

I would say add any additional information of your experience that you think is useful to show that the problem is likely still being experienced by other people. There are probably people who have not noticed they have the problem.


I added a couple of lines of info.

Thank you Adolf & Bernhard for your help!

1 Like

I didn’t have the time to look deeply into the sources.
But I know from previous attempts, that this part isn’t just straight-forward and there is no real dev doc.
I’ll do my best in investigating this ( and possibly other ) issues.
Applying a patch should include those known issues.

It may be not easy to realise our goal:

  • Firewall is transparently configured using the UI.
  • A legal configuration is stored in the various settings ( rules, definitions of hosts, services, …, groups of them )
  • The iptables generator produces only legal entries from this configuration.
  • Errors and/or possible problems are signaled in the UI.

The contents of firewall.local cannot be checked by this procedure. Therefore it must be checked by invocation from the shell with a

/etc/sysconfig/firewall.local start
/etc/sysconfig/firewall.local reload


Something forgotten?