Hello, Am 01.02.2018 um 19:31 schrieb Grant Taylor: > I think that you will need to do some more digging into connection > tracking and how to interpret the output. At least enough so that you > can learn what is necessary to surgically add / remove entries to the > connection tracking table. do you have some reading material on this besides the man page of course? > I don't know if it's a bug in connection tracking or not. It might > simply be a race condition. I'd consider a race condition in this paticular case a bug. As GRE is stateless, the NAT module needs to be capable of handling first connection attemps from both sides. I haven't seen the code so far, maybe I just need another source-NAT based rule for GRE? Like, do not only nat incomming packages and learn from that how to handle outgoing packages. But something like "Do nat incoming GRE packages to that IP. Do nat outgoing GRE packages to my public IP address with source NAT." At my current point of understanding it just seems logical, that this might be needed to prevent race conditions. But on second thought, the masquerading should do this already. Which brings me back the point, that I didn't understand something here or I'd consider this a bug. > > Try clearing the connection tracking table, and then starting a > persistent ping through each tunnel and seeing if the tunnels stay up > and functional. - I.e. constantly send traffic through the tunnels > to make sure that the connection tracking table entries don't become > stale, which leads to them getting purged, which means a new "first > seen" condition again. BGP should be holding the tunnels open with its status packages. I could still give it a try. Test started. We'll know the results later. Bye, 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
