Hi, Am 05.02.2018 um 02:05 schrieb Grant Taylor: > 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. > no, there are VMs with public IPs, which run in bridged mode. And VMs, which have only private IPs. Those are natted on the hypervisor. The eth0s of the VMs have no address but a public IPV4 and a public IPV6 address. > >> 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. No, all masquerading goes through the same, one and only public ip on the hypervisor. >> 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. The ping doesn't go through, even with correct source IP (-I local_tunnel_ip) and resetting the connection with conntrack doesn't work. > 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. ACK. > 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. conntrack -E shows this, when I delete an entry: [DESTROY] gre 47 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [NEW] gre 47 30 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 [UNREPLIED] src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 30 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] (This paticular tunnel still doesn't work.) Then I tried a working tunnel: Set up a ping, flushed the entry, but: root@unimatrixzero ~ # conntrack -D -s 185.66.194.1 conntrack v1.4.3 (conntrack-tools): 0 flow entries have been deleted. root@unimatrixzero ~ # conntrack -D -d 185.66.194.1 gre 47 179 src=192.168.10.62 dst=185.66.194.1 srckey=0x0 dstkey=0x0 src=185.66.194.1 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] mark=0 use=1 conntrack v1.4.3 (conntrack-tools): 1 flow entries have been deleted. The not working tunnel seems to have a conntrack entry based on the remote IP as source. The working tunnel seems to have a conntrack entry based on the remote IP as destination. But it's not as simple as that. I tried to making a not working tunnel work. Set up a ping (one packet per second) and deleted entries, till it worked: root@unimatrixzero ~ # conntrack -E|grep 185.66.195.0 [NEW] gre 47 30 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UNREPLIED] src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [DESTROY] gre 47 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UNREPLIED] src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [NEW] gre 47 30 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UNREPLIED] src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 29 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] [DESTROY] gre 47 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] [DESTROY] gre 47 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [NEW] gre 47 30 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 [UNREPLIED] src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 29 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [NEW] gre 47 30 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UNREPLIED] src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [DESTROY] gre 47 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [UPDATE] gre 47 30 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] [NEW] gre 47 30 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 [UNREPLIED] src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 29 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [DESTROY] gre 47 src=176.9.38.158 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] [DESTROY] gre 47 src=185.66.195.0 dst=176.9.38.158 srckey=0x0 dstkey=0x0 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [ASSURED] [NEW] gre 47 30 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 [UNREPLIED] src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 30 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [UPDATE] gre 47 180 src=192.168.10.62 dst=185.66.195.0 srckey=0x0 dstkey=0x0 src=185.66.195.0 dst=176.9.38.150 srckey=0x0 dstkey=0x0 [ASSURED] As you can see the third lines is identical to the third last. But the tunnel didn't work with the entry from the third line, but did so with the third last line. There must be something else going on. Regards, Matthias -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
