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