From mboxrd@z Thu Jan  1 00:00:00 1970
From: Matthias Walther <matthias@walther.xyz>
Date: Fri, 02 Feb 2018 21:30:17 +0000
Subject: Re: GRE-NAT broken - SOLVED
Message-Id: <9eb1a123-6861-6a1e-a566-bfc2b30f8dbe@walther.xyz>
List-Id: <lartc.vger.kernel.org>
References: <93df1d66-01b5-1ddf-b3f7-5a59c940eb2f@spamtrap.tnetconsulting.net>
In-Reply-To: <93df1d66-01b5-1ddf-b3f7-5a59c940eb2f@spamtrap.tnetconsulting.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
To: lartc@vger.kernel.org

Hi,

Am 02.02.2018 um 21:21 schrieb Grant Taylor:
>
>> 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.
You have a SNAT rule in there.

But my masquerading rule should do the exact same thing:
-A POSTROUTING -s 192.168.10.0/24 ! -d 192.168.10.0/24 -j MASQUERADE

Both cases, the first package from the inside and from the outside
should be covered. Or am I missing something here?

>
> I think the race is who sends packets first, not a problem in the code
> or implementation.
>
True, but the implementation and my configuration of the same should
handle both cases.
>
> 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.
>
I'd have to look that up. So far the ping keeps the tunnels going.

Bye,
Matthias