On 02/02/2018 05:33 AM, Matthias Walther wrote:
do you have some reading material on this besides the man page of course?
Sorry, I don't have anything specific.I suspect there's a mailing list or other support resources, other than LARTC, around iproute2 and connection tracking.
I'd consider a race condition in this paticular case a bug. As GRE is stateless, the NAT module needs to be capable of handling first connection attemps from both sides.
I think the race condition is between which side sends a GRE packet first, after the connection tracking state has been cleared. I.e. the local inside system sending the GRE packet to the remote outside system, or the remote outside system sending the GRE packet to the local inside system.
I haven't seen the code so far, maybe I just need another source-NAT based rule for GRE?
I don't know. Take a look at the GRE-NAT.sh script that I shared in a previous email.
Like, do not only nat incomming packages and learn from that how to handle outgoing packages. But something like "Do nat incoming GRE packages to that IP. Do nat outgoing GRE packages to my public IP address with source NAT."
I know that other NAT implementations need NAT rules for incoming and outgoing traffic. But IPTables has always managed both of those as one atomic unit, which handled both directions.
At my current point of understanding it just seems logical, that this might be needed to prevent race conditions.
I think the race is who sends packets first, not a problem in the code or implementation.
But on second thought, the masquerading should do this already. Which brings me back the point, that I didn't understand something here or I'd consider this a bug.
First, compare what I think you are considering the race condition vs what I'm considering the race condition.
BGP should be holding the tunnels open with its status packages. I could still give it a try. Test started. We'll know the results later.
How often does BGP send packets if there aren't any updates or changes to advertise? - Cursory Google search makes me think that BGP sends a a keepalive (heartbeat) packet every minute. - I would think that would be often enough to keep connection tracking entries from timing out.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
