Re: GRE-NAT broken - SOLVED

On 02/04/2018 05:17 PM, Matthias Walther wrote:
> They're bridged through the physical interface and should not interfere 
> with the other packages.

I agree that the bridged packets shouldn't interfere.  But that doesn't 
account for the two VMs.  I thought that each VM had an additional IP 
bound to the outside.

Too many things.  I've lost track.

> How do you mean that with at least one of the tunnels? Could you give 
> an example?

Suppose that you have two additional IPs bound to the eth0 interface, 
which has it's own IP, and DNATing the traffic into the VMs.

I believe that the simple MASQUERADE will end up SNATing egress packets 
with one IP address.  I expect it will either be the IP that shows up in 
ifconfig or the first address added or the numerically lowest IP.

So, outgoing packets from at least on of the VMs will possibly be 
MASQUERADEd to the wrong IP.

> In fact I do have one tunnel, that is still down. I ignored it, because 
> I thought there might be another problem with that one.

You'll have to give details before I can speculate.

> How do you mean this exactly? The first package might be incoming or 
> outgoing. Or are you thinking of the case, that they might arrive the 
> (almost) the same time?

Yes, I'm referring to the first packet that connection tracking seeing 
(after booting or being cleared) could be incoming /or/ outgoing.  This 
unpredictability has everything to do with timing of the sequence of events.

> The ping workaround still works

Good.  Then we might be on to something.

Skim the man page for conntrack.  There's a way that you can get it to 
show you events as they happen.  Perhaps you can watch them and figure 
out a pattern to when things do and do not work.



-- 
Grant. . . .
unix || die