Re: GRE-NAT broken - SOLVED

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