Open Stack

On 3/15/19 10:06 AM, Harald Jensås wrote:
> Hi Miguel, Brian, and All,
> 
> Don't think there was any progress on this so I'd like to pick it up.

Hi Harald,

Sorry, I seemed to have dropped the ball on this.

> 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

Glad it worked for you.  One reason I don't mind this approach is that 
inside the router namespace we aren't really running any services 
(except for maybe radvd or dibbler-client), so the hypervisor shouldn't 
be accessible even when a helper is loaded.

> 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'?has

That's a good suggestion, my only thought is it makes things more 
complicated to configure.  Let me add it to the L3 subteam meeting 
agenda this week so we can spend some time talking about our options.

Thanks,

-Brian


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