Open Stack

Hi Miguel, Brian, and All,

Don't think there was any progress on this so I'd like to pick it up.

I tested this PoC patch, which adds a CT firewall rule to the
namespace. And it seems to do the job.
https://review.openstack.org/643570


Not sure that adding these rules trough a global option is the right
thing to do. Would it be better to implement this as an extension
similar to how FIP port forwarding was done?

A new object?

{'conntrack_helper_rules':
   'helpers': [
     {'proto': '<protocol>',
      'port':  '<port>',
      'helper': '<helper>'},
   ],
   'router_id': '<router_uuid>'
}

An extension in `neutron/agent/l3/extensions` that adds the relevant
firewall rules in the namespace. The conntrack_helper_rules would be a
sub_resource_extension of `neutron_lib/api/definitions/l3.py`/'router'?


wdyt?


Best Regards
Harald

On Sun, 2019-01-13 at 12:11 -0600, Miguel Lavalle wrote:
> Hi Derek,
> 
> Yes, these rules would need to be added inside the router namespace
> when it is created and it seems to me it is a workable solution. I
> will raise this work in the next L3 sub-team meeting, so we keep an
> eye on the patches / progress you make
> 
> Regards
> 
> Miguel
> 
> On Mon, Jan 7, 2019 at 11:54 AM Derek Higgins <derekh at redhat.com>
> wrote:
> > On Mon, 7 Jan 2019 at 17:08, Clark Boylan <cboylan at sapwetik.org>
> > wrote:
> > >
> > > On Mon, Jan 7, 2019, at 8:48 AM, Julia Kreger wrote:
> > > > Thanks for bringing this up Derek!
> > > > Comments below.
> > > >
> > > > On Mon, Jan 7, 2019 at 8:30 AM Derek Higgins <derekh at redhat.com
> > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > Shortly before the holidays CI jobs moved from xenial to
> > bionic, for
> > > > > Ironic this meant a bunch failures[1], all have now been
> > dealt with,
> > > > > with the exception of the UEFI job. It turns out that during
> > this job
> > > > > our (virtual) baremetal nodes use tftp to download a ipxe
> > image. In
> > > > > order to track these tftp connections we have been making use
> > of the
> > > > > fact that nf_conntrack_helper has been enabled by default. In
> > newer
> > > > > kernel versions[2] this is no longer the case and I'm now
> > trying to
> > > > > figure out the best way to deal with the new behaviour. I've
> > put
> > > > > together some possible solutions along with some details on
> > why they
> > > > > are not ideal and would appreciate some opinions
> > > >
> > > > The git commit message suggests that users should explicitly
> > put in rules such
> > > > that the traffic is matched. I feel like the kernel change ends
> > up
> > > > being a behavior
> > > > change in this case.
> > > >
> > > > I think the reasonable path forward is to have a configuration
> > > > parameter that the
> > > > l3 agent can use to determine to set the netfilter connection
> > tracker helper.
> > > >
> > > > Doing so, allows us to raise this behavior change to operators
> > minimizing the
> > > > need of them having to troubleshoot it in production, and gives
> > them a choice
> > > > in the direction that they wish to take.
> > >
> > > https://home.regit.org/netfilter-en/secure-use-of-helpers/ seems
> > to cover this. Basically you should explicitly enable specific
> > helpers when you need them rather than relying on the auto helper
> > rules.
> > 
> > Thanks, I forgot to point out the option of adding these rules, If
> > I
> > understand it correctly they would need to be added inside the
> > router
> > namespace when neutron creates it, somebody from neutron might be
> > able
> > to indicate if this is a workable solution.
> > 
> > >
> > > Maybe even avoid the configuration option entirely if ironic and
> > neutron can set the required helper for tftp when tftp is used?
> > >
> > > >
> > > > [trim]
> > > >
> > >
> > > [more trimming]
> > >
> >