Re: GRE-NAT broken - SOLVED

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux