Re: GRE-NAT broken - SOLVED

[Grant Taylor <gtaylor@tnetconsulting.net>]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

On 02/02/2018 02:30 PM, Matthias Walther wrote:
> 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

Maybe, maybe not.

I thought you had additional globally routed IPs bound to the outside 
interface that were DNATed into the VMs.  (Have I remembered incorrectly?)

If that is the case, then MASQUERADEing will likely cause at least one 
of the tunnels to end up with the wrong GRE source IP on outgoing packets.

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

I think that the IPTables rules do account for packets in either 
direction to arrive first.

But I think the problem is when both ends send packets with timing that 
does not jive with state that Connection Tracking is expecting.

I /think/.

> True, but the implementation and my configuration of the same should 
> handle both cases.

I think it's a complication related to interaction between arrival 
timing and what Connection Tracking is expecting.  Hence the "UNREPLIED" 
in the output of conntrack -L.

> I'd have to look that up. So far the ping keeps the tunnels going.

Well, I think that's a good thing.  It seems like we're narrowing in on 
the problem.  The solution to said problem may be something else. 
(Unless you want to just leave persistent pings running.  }:-)



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3982 bytes --]