[Firehol-devs] code generation

[Tsaousis, Costa]

Regarding FIREHOL_AUTO_CT_HELPERS=1 I think the instructions I gave
previously are wrong.

I advised you to add src/dst to routers when this is enabled.

Well, it turns out that this will not work...

The problem is that in the raw table where this is applied, packets
are seen outside the NAT. The packets are seen before the NAT for the
incoming packets and after the NAT for the outgoing packets. If you
NAT your traffic and you have src/dst IP in your router and interface
statements which are NAT'd, then FIREHOL_AUTO_CT_HELPERS=1 will not be
able to match anything for the helpers at the 'raw' table. The same is
also true of you NAT the server ports. FireHOL will create statements
to enable the helper that will not match the NATed ports.

So the correct statement is: when you use helpers, for
FIREHOL_AUTO_CT_HELPERS=1 to match the traffic, you should use src and
dst IPs in routers and interfaces, as seen on the wire in both
directions (and in case of routers, use only the IPs that are common
to both wires). If you NAT ports, FIREHOL_AUTO_CT_HELPERS=1 cannot
help at all.

So, if you don't usually put src/dst in your interfaces and routers
and you don't NAT ports, FIREHOL_AUTO_CT_HELPERS=1 will work out of
the box.

If you do however limit the traffic with src/dst (and you should to
avoid spoofing) FIREHOL_AUTO_CT_HELPERS=1 will not generate statements
to match the helper traffic properly.
In this case, use the cthelper to configure the conntrack helpers manually.

I switched back the default behaviour:

FIREHOL_DEFAULT_CT_HELPERS=1 (default assignment by kernel enabled)
FIREHOL_AUTO_CT_HELPERS=0 (automatic assignment by FireHOL disabled)

If you plan to use the cthelper, you should set
FIREHOL_DEFAULT_CT_HELPERS=0 (disable default assignment by kernel).

I updated the cthelper to work also bidirectionally:

cthelper <helper name> in|out|inout [ optional rule parameters ]

In case of 'inout' you should match 'in' and FireHOL will create 'out'.

I also added a warning in cthelper if FIREHOL_DEFAULT_CT_HELPERS=1.

Costa

On Sun, Feb 15, 2015 at 11:22 AM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> Phil I agree with all your proposals.
>
> Regarding the mms, my mistake, I couldn't find the helper to test it,
> so I removed it.
> I now see that it exists in openwrt. I added it back.
>
> Costa
>
>
> On Sun, Feb 15, 2015 at 10:55 AM, Phil Whineray <phil at sanewall.org> wrote:
>> Hi Costa
>>
>> When there was no builds for a couple of days I thought perhaps you
>> were taking a well-deserved break.
>>
>> On Sun, Feb 15, 2015 at 03:04:05AM +0200, Tsaousis, Costa wrote:
>>> To my understanding this commit contains so important changes, new
>>> features and optimizations, that FireHOL is now at v3 (Phil this is
>>> your call though).
>>
>> It seems the opposite is true! Together, these are some impressive changes.
>> I agree this must be v3.
>>
>> From here I think there are 3 main activities:
>>  - get as wide testing as possible
>>  - get the documentation done internally
>>  - update the website
>>
>> Unless you disagree with this approach I will put together a 3.0.0-rc.1
>> fairly soon (should be today) and announce on the lists and website
>> to encourage people to start testing.
>>
>> I will also see about putting in place a basic unit test structure,
>> better than the regression one I had which allows us to track when
>> results change. This seems like an appropriate time, in that I would
>> like to create a number of test configurations, so recording the
>> results seems sensible.
>>
>> I will also create a v2 branch and a 2.0.1 release to apply a bugfix
>> when plain iptables statements are used by the user. I hope most
>> people will jump straight to v3 but any that don't should have that patch.
>>
>> Cheers
>> Phil
>>
>> P.S. Final question - the latest changes include this - I don't
>> understand the removal? If it is intentional then lines 768-769 need
>> removing from doc/services-db.data so that the code does not expect
>> to find a helper when building the docs.
>>
>> @@ -2091,10 +2169,6 @@ client_microsoft_ds_ports="default"
>>
>>  server_mms_ports="tcp/1755 udp/1755"
>>  client_mms_ports="default"
>> -helper_mms="mms"
>> -# this will produce warnings on most distribution
>> -# because the mms module is not there:
>> -# ALL_SHOULD_ALSO_RUN="${ALL_SHOULD_ALSO_RUN} mms"