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? 10.220.62.2 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?
This ipfire is running in a green interface only mode (no red interface) 10.220.62.2 is the Mobility Print Host, What i do not understand is why it intermittantly works.
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.
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.
@cfusco
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(), “10.220.44.0”, “255.255.254.0”))
)
return “PROXY 10.220.44.3:8080”;
}
10.220.44.3 is an interface on our url filter
Wireless SSID the clients connect to has an ACL applied allowing ports 9163 and 9164
(hitting 10.220.62.2:9163/setup/ 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.
10.220.62.2 isn’t an element of 10.220.44.0/23.
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 10.220.44.2, with a default gateway of 10.220.44.254 (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 255.255.254.0 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.
@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 ( 10.220.44.0/23 ) and WAN 10.220.62.0/xx?
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 10.220.44.254 with a netmask of 255.255.254.0 which gives a usable host range of 10.220.44.1 - 10.220.45.254
The problem, I believe, is that the Mobility Print system has an IP of 10.220.62.2 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 10.220.62.2 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 10.220.62.2 to access the IPFire green interface. If yes then you need to set the netmask to 10.220.63.255 which will give you a usable range of 10.220.32.1 - 10.220.63.254
If 19.220.63.255 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 10.220.44.0 - 10.220.45.255 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 10.220.62.2 is not assigned by the IPFIre DHCP server?
