>From my understanding after development of FireWall and TCP/IP in general used in modern networking , it seems that it has been reasoned that clients should avoid to send 2 separate requests with same source port . ( again , not as an absolute rule , but certainly as a strong rule of thumb ) I am not sure it is correct to describe 2 separate request via UDP as a flow , but I agree that the client isn't directly doing something that is "wrong" . As you say historically like my DHCP RELAY example it was accepted ( and normal ) to only user port 67 as both SOURCE and DESTINATION port . However it doesn't take much reasoning to argue that this is potentially problematic for any sort of state tables , and it seems un-economic to make more advanced state tables or mark packets to avoid certain scenarios . ( compared to opening 2 sockets from the various clients which have a distributed "load" for millions of clients , while the "servers" and "firewalls" need to be optimized for millions of requests ) I disagree this is a bug in the FIREWALL(s) as this would ONLY happen when reusing source port which in my opinion isn't reasonable optimization for simple clients , and mind you this is the security feature of the FIREWALL to track states and for DNS there are no flows like you have with SIP / SYSLOG . Which also reuse the SOURCE port for their flows , but these are known directly for establishing such flows - which is not the same for DNS which after also using random ports for each request now make 2 for each after IPv6 was added . Previously the expected behavior each unique request would have a similarly unique response . ( not the earliest which reused source port made in 1983 or something for all requests which was created to replace a globally distributed hosts.txt file used by ARPANET ) Best regards André Paulsberg-Csibi Senior Network Engineer IBM Services AS Sensitivity: Internal -----Opprinnelig melding----- Fra: zrm <zrm@xxxxxxxxxxxxxxx> Sendt: torsdag 6. september 2018 20.07 Til: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx>; 'Kyle Larose' <kyle@xxxxxxxxxxxx> Kopi: netfilter@xxxxxxxxxxxxxxx Emne: Re: SV: Conntrack insertion race conditions -- any workarounds? On 09/06/2018 12:46 PM, André Paulsberg-Csibi (IBM Consultant) wrote: > > That is really sad , I have also seen similar issue with other "firewalls" like checkpoint and such with DHCP RELAY , because the DHCP always use port 67 for both source and destination port in those cases . > > I do not think we can blame the FIREWALL itself for this as it is supposed to protect system from some of this , it is more "bad" design to reuse the port for another request . This does actually seem to be a race condition in the firewall. There are two packets as part of the same flow but the second gets processed concurrent with the first without proper synchronization. The client isn't doing anything wrong here. Historically DNS clients would use the same source port for _every_ request, the reason they don't anymore is the Kaminsky attack for which source port randomization is used as a mitigation. But reusing the same random source port for concurrent requests to the same server doesn't give an attacker much if anything there, so the client is doing a reasonable optimization and avoids having to open and close two sockets instead of one. You would get the same problem with anything that sends two packets right away. Not many other things do this (except by coincidence of just having two simultaneous requests), but it's definitely a bug in the firewall if it can't handle it when it happens. As for what to do about it, could CONNMARK work here? Suppose you queue everything without a particular connection mark and then set that mark on everything somewhere later in processing than where you queue it, so that all the packets that are part of an existing flow are marked and not queued. The question is whether there is anywhere to put the queue rule which is after it's possible to identify that the flow has a particular connmark but before the packet is dropped.
