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 . However maybe it would be an idea for iptables/netfilter to have a setting similar to the CHECKPOINT FIREWALL workaround : $FWDIR/boot/modules/fwkern.conf fwconn_rematch_udp_s2c_old_conn=1 fwconn_rematch_udp_s2c_old_conn_by_service=67 which would allow "rematching" the same source ports for destination port 67 ... Best regards André Paulsberg-Csibi Senior Network Engineer IBM Services AS Sensitivity: Internal -----Opprinnelig melding----- Fra: Kyle Larose <kyle@xxxxxxxxxxxx> Sendt: torsdag 6. september 2018 15.43 Til: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx> Kopi: netfilter@xxxxxxxxxxxxxxx Emne: Re: Conntrack insertion race conditions -- any workarounds? On 6 September 2018 at 09:19, André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx> wrote: > I am not sure I agree that this is a race condition , but I might be wrong here . > > Based on what I assume is normal UDP behavior I would think 2 request > generated for one A and second AAAA record should have 2 separate sources ports , and should result in 2 separate conntrack entries and as such not race each other for any entry . > ( this is my understanding , correct me if this assumption is > incorrect and tcpdumps actually show same UDP source port is used ) > > The same request is forwarded out of the same socket. When the issue is not occurring, you can see that through tcpdump. My service listening on nfqueue also shows that the packets are from the same port. Apparently it is fairly standard with libc and musl dns implementations. This blog post discusses it a bit, and uses DNS as an example of the problem: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.weave.works%2Fblog%2Fracy-conntrack-and-dns-lookup-timeouts&data=02%7C01%7CAndre.Paulsberg-Csibi%40evry.com%7C0e79155c7266482557bc08d613feb137%7C40cc2915e2834a2794716bdd7ca4c6e1%7C1%7C0%7C636718381958862453&sdata=L0NvKKclmY8spsOlB9nMwPgwKJ2889%2F5MCh%2Burig7e8%3D&reserved=0
