Re: GRE-NAT broken - SOLVED

Re-sending to LARTC.

On 02/05/2018 07:00 AM, Matthias Walther wrote:
> Hi,

Hi Matthias,

> 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.

Okay.

I've apparently conflated multiple things that I've been working on.

I'm sorry for the confusion.

> No, all masquerading goes through the same, one and only public ip on 
> the hypervisor.

ACK

Then MASQUERADE should be fine.

> The ping doesn't go through, even with correct source IP (-I 
> local_tunnel_ip) and resetting the connection with conntrack doesn't work.

Okay.  :-/

> 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]

Okay.  I see the DESTROY which corresponds to the command that you 
issues.  Then the NEW (not currently in the connection tracking table), 
the UPDATE for the reply, and the UPDATE for the reply to the reply 
going the same direction as the NEW packet, thus marking the connection 
ASSURED.

> (This paticular tunnel still doesn't work.)

Okay.

> 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.

You might be onto something.  This may come back to the race condition 
that I was referring to.

> 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.

I think I need to do some more reading on conntrack and how to manually 
manipulate the connection tracking table.

> There must be something else going on.

Maybe.

I feel like it is connection tracking related.

Are the tunnels that had the persistent ping running still working 
correctly?



-- 
Grant. . . .
unix || die