Thursday, May 30, 2019

Conntrack timeout explanation

Background: I have a DNAT rule configured on a firewall which works fine until the source is turned off over night, and then the next morning the traffic does not seem to be matching to the rule. Running tcpdump shows packets with a [S] flag, but these are not forwarded on as they should be, until the firewall is restarted.

I have had the vendor looking into the issue, and they have come back to me saying that the conntrack timeout only being 3 hours is the cause of the issue. They have increased this timeout and are assuring me that this is the fix - this is not a fix in my eyes.

Question: Am I right in thinking that even when the timeout of that connection is reached, it should simply create a new connection when receiving traffic again? To my knowledge, increasing the timeout is putting a band-aid on the real issue.



No comments:

Post a Comment