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:
smime.p7s
Description: S/MIME Cryptographic Signature
