Help with DROP_CTINVALID errors being logged

Hi there,
We are using IPFIRE (ver. 172) as a dhcp server implementing a proxy.pac to forward any webtraffic to our web filter.

In general this works really well, We have started to use Papercut Mobility Client which requires ports 9163 and 9164 to be reachable but im seeing DROP_CTINVALID in ipfire firewall logs for port 9164 (only when the setup is trying to retrieve the available printers)

Adding a rule to allow 9163 and 9164 still does not allow these packets through.

Thanks for your help and advice.

EDIT: It seems to be very intermittant, ive just restarted my client and no blocks are shown and the printer list retrieved correctly, after multiple attempts of running the setup again DROP_CTINVALID packets are being logged again and the printer list retrieval fails. (My client still has the same IP address as before)


The ports have to be available from internet? is you web proxy? Who initiates the connection? How is this protocol supposed to work?

I believe ct_invalid means that the traffic initiated by the source, to the destination cannot be attributed to an open connection, as tracked by iptables in the connection track table. Why is that?

Hello again @cfusco,
Thanks for replying again.

This ipfire is running in a green interface only mode (no red interface) is the Mobility Print Host, What i do not understand is why it intermittantly works.

so, there is no traffic going to the red interface?

No the red interface is not needed and has been deleted

I got confused by you mentioning the proxy filtering in your initial message. Then, traffic inside the green network is routed without filtering unless you write a custom rule. Therefore the problem should not be due to IPFire routing/filtering activity.

If I understand correctly Mobility Print will provide an mDNS (also called by apple bonjour) service for automatic discovery. I use bonjour in my green network and it works flawlessly.

Here is my hypothesis for your consideration, could be that the problem is in the server? If the service drops unexpectedly, it would explain the ct_invalid, which is basically traffic from broken or not existent connections. I would look the logs of the server.

Edit: also the clients could malfunction, I guess.

1 Like

I will do some more investigating!
I will also look into implementing mDNS (Currently using the known host method)

Thanks for all the advice you have given.

mDNS in this scenario I dont think will work, the known host method should work (Which it does for the majority of clients - just not any of the clients using this IPFIRE box)

Yes, I agree. However, this should work in a simple IPFire only green zone configuration. Your answer seems to imply you have a more complex routing. Maybe you should describe in detail your setup. I doubt I have the skills to help you out, but others might if they understand your network. I think, it must be a routing problem.


IPFIRE (setup with a GREEN interface only)
DHCP service running deploying proxy.pac to all clients

proxy.pac is as below

function FindProxyForURL(url, host)
if (
(isInNet(myIpAddress(), “”, “”))
return “PROXY”;
} is an interface on our url filter

Wireless SSID the clients connect to has an ACL applied allowing ports 9163 and 9164

(hitting allows the device to hit the Mobility Print setup page)

When the software is ran and tries to retrieve the printer list DROP_CTINVALID is logged, once in a while it does work and the printer list is retrieved correctly. isn’t an element of
Therefore there must be some other routing rules/elements.

Could you describe your system more in detail, please?
Especially, where is IPFire located in this system ( physical/logical ), where is the access to the WAN?



Thanks to all, you are correct and i should of been more specific.

This ipfire box has an IP address of, with a default gateway of (which is a static reserved ip address of the ipfire box due to the way our core switch is configured, DHCP server running on this ipfire is leasing addresses with a netmask of hence why the 44.254 is a fake static reserved address.)

Our core switch has an ACL permit rule in place to allow any traffic to the 62.26 address.

Our wireless infrastructure also has ACLs in place, which look correct and but to confirm this i removed all the ACLS and left it open, sure enough I could not get the Mobility Client to fail , replicating the steps previously where i could get it to fail.

I left the machine alone for while and retried, still no failure and no DROP_CTINVALID packets logged on IPFIRE.

I readded the ACL rules once again, in the exact same order… tested no failure, left the machine overnight and first thing this morning retried …again no failure.

Thanks to everyone for all the help and advise!

@retroisbest , I’ve marked the thread as solved, interpreting your last post.

Nevertheless I don’t understand your system really.
Is it right, that your green interface connects both to a LAN ( ) and WAN

I’m just asking for other users trying to implement a simliar config.


Looking back earlier in this post I see that IPFire is being used only as a dhcp server for green.

The red interface is not used. From the post it even seems to have been deleted in the settings, presumably manually after having done the setup.

The green interface on IPFire has been set up with an IP of with a netmask of which gives a usable host range of -

The problem, I believe, is that the Mobility Print system has an IP of which is outside of the IPFire green subnet but is coming in to IPFire on the green interface. This is what is confusing IPFire.

IPFire can not work with two subnets operating on the green interface.

Normally clients coming into green and going back out on green don’t traverse any firewall rules as they are not being routed from one subnet to another.
I believe in this case the client address, being outside the green subnet is somehow getting into some firewall rules which are failing. This can be seen in the firewall log in the first post where the in and out are both set as green0 but the IP’s are not in the same subnet.

I believe that as long as you have two subnets allowed to enter on green the problem you outlined can occur again.

Do you need to access the IPFire green interface. If yes then you need to set the netmask to which will give you a usable range of -

If does not need to access IPFire then you need to set the ACL’s on your swith to prevent any traffic from an IP outside of the - range from being sent to the IPFire green interface.


the rule seems to be the fact that the packets do not belong to the conntrack table. I think in certain circumstances IPFire sees these packets as broken because it does not have an open connection to whom they belong and drops them. Is it possible that this happens because is not assigned by the IPFIre DHCP server?

1 Like