[nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[ѽ҉ᶬḳ℠]

WIKI [1] stipulates the rule in the ip family table, perhaps logical 
since it applies to IPv4 only, It is however possible to include the 
rule in the inet family table?

Having it implemented in

table inet filter {
  chain input               { oif pppoe-wan tcp flags syn tcp option 
maxseg size set 1400; }
}

does not throw an error but it does not work either.

Then tried instead (inet family)

{ oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 1400; }
{ oif pppoe-wan ip protocol tcp flags syn ip protocol tcp option maxseg 
size set 1400; }

But either throwing

Error: syntax error, unexpected flags, expecting newline or semicolon.

What am I missing to get this to work in the inet family table?

____
[1] https://wiki.nftables.org/wiki-nftables/index.php/Mangle_TCP_options

Re: [nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[Florian Westphal]

ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> WIKI [1] stipulates the rule in the ip family table, perhaps logical since
> it applies to IPv4 only, It is however possible to include the rule in the
> inet family table?
> 
> Having it implemented in
> 
> table inet filter {
>  chain input               { oif pppoe-wan tcp flags syn tcp option maxseg
> size set 1400; }
> }
> 
> does not throw an error but it does not work either.

That chain isn't hooked up, its missing the 'type filter hook input
priority 0;' part.

> Then tried instead (inet family)
> 
> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 1400; }
> { oif pppoe-wan ip protocol tcp flags syn ip protocol tcp option maxseg size
> set 1400; }
> 
> But either throwing
> 
> Error: syntax error, unexpected flags, expecting newline or semicolon.

> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 1400; }

This is: oif == pppoe-wan
         ip protocol == tcp
	 flags syn # invalid, should be "tcp flags syn"

> What am I missing to get this to work in the inet family table?

Did not try it but it should work, there is nothing ip/ipv6 specific
in the tcp option code.

Re: [nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[ѽ҉ᶬḳ℠]

On 05/02/2020 11:26, Florian Westphal wrote:
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>> WIKI [1] stipulates the rule in the ip family table, perhaps logical since
>> it applies to IPv4 only, It is however possible to include the rule in the
>> inet family table?
>>
>> Having it implemented in
>>
>> table inet filter {
>>   chain input               { oif pppoe-wan tcp flags syn tcp option maxseg
>> size set 1400; }
>> }
>>
>> does not throw an error but it does not work either.
> That chain isn't hooked up, its missing the 'type filter hook input
> priority 0;' part.

It is hooked, in the spirit of brevity skipped that code portion having 
composed the initial message to the mailing list.

>
>> Then tried instead (inet family)
>>
>> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 1400; }
>> { oif pppoe-wan ip protocol tcp flags syn ip protocol tcp option maxseg size
>> set 1400; }
>>
>> But either throwing
>>
>> Error: syntax error, unexpected flags, expecting newline or semicolon.
>> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 1400; }
> This is: oif == pppoe-wan
>           ip protocol == tcp
> 	 flags syn # invalid, should be "tcp flags syn"
>
>> What am I missing to get this to work in the inet family table?
> Did not try it but it should work, there is nothing ip/ipv6 specific
> in the tcp option code.

It does not work in the inet family table but does in the ip family table;

* rule when deployed with the _ip family_ -> packet capture shows the 
packet size as set/stipulated in the rule
* rule when deployed with the _inet family_ -> packet capture does not 
show the packet size as set/stipulated in the rule

As far as I can comprehend IPv6 does not require MSS clamping due to its 
build-in Path MTU Discovery which is not mandatory for IPv4. It would 
thus probably not make sense to apply MSS clamping to IPv6.

Re: [nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[ѽ҉ᶬḳ℠]

On 05/02/2020 12:46, ѽ҉ᶬḳ℠ wrote:
> On 05/02/2020 11:26, Florian Westphal wrote:
>> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>>> WIKI [1] stipulates the rule in the ip family table, perhaps logical 
>>> since
>>> it applies to IPv4 only, It is however possible to include the rule 
>>> in the
>>> inet family table?
>>>
>>> Having it implemented in
>>>
>>> table inet filter {
>>>   chain input               { oif pppoe-wan tcp flags syn tcp option 
>>> maxseg
>>> size set 1400; }
>>> }
>>>
>>> does not throw an error but it does not work either.
>> That chain isn't hooked up, its missing the 'type filter hook input
>> priority 0;' part.
>
> It is hooked, in the spirit of brevity skipped that code portion 
> having composed the initial message to the mailing list.
>
>>
>>> Then tried instead (inet family)
>>>
>>> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 
>>> 1400; }
>>> { oif pppoe-wan ip protocol tcp flags syn ip protocol tcp option 
>>> maxseg size
>>> set 1400; }
>>>
>>> But either throwing
>>>
>>> Error: syntax error, unexpected flags, expecting newline or semicolon.
>>> { oif pppoe-wan ip protocol tcp flags syn tcp option maxseg size set 
>>> 1400; }
>> This is: oif == pppoe-wan
>>           ip protocol == tcp
>>      flags syn # invalid, should be "tcp flags syn"
>>
>>> What am I missing to get this to work in the inet family table?
>> Did not try it but it should work, there is nothing ip/ipv6 specific
>> in the tcp option code.
>
> It does not work in the inet family table but does in the ip family 
> table;
>
> * rule when deployed with the _ip family_ -> packet capture shows the 
> packet size as set/stipulated in the rule
> * rule when deployed with the _inet family_ -> packet capture does not 
> show the packet size as set/stipulated in the rule
>
> As far as I can comprehend IPv6 does not require MSS clamping due to 
> its build-in Path MTU Discovery which is not mandatory for IPv4. It 
> would thus probably not make sense to apply MSS clamping to IPv6.
>

Finally got it working in the inet table, seems being a matter of rule 
position (handle value),

this works

chain forward { # handle 2
                 type filter hook forward priority filter; policy drop;
                 ct state established,related accept # handle 19
                 ct state invalid drop # handle 20
                 oif "pppoe-wan" tcp flags syn tcp option maxseg size 
set 1300 # handle 21
                 iif "br-lan" accept # handle 22
                 oif "br-lan" accept # handle 23
                 iif "br-mgt" accept # handle 24
                 oif "br-mgt" accept # handle 25
                 log prefix "DROP_FW " level debug flags all counter 
packets 0 bytes 0 # handle 26

but this does not

chain forward { # handle 2
         type filter hook forward priority filter; policy drop;
         ct state established,related accept # handle 19
         ct state invalid drop # handle 20
         iif "br-lan" accept # handle 21
         oif "br-lan" accept # handle 22
         iif "br-mgt" accept # handle 23
         oif "br-mgt" accept # handle 24
         oif "pppoe-wan" tcp flags syn tcp option maxseg size set 1300 # 
handle 25
         log prefix "DROP_FW " level debug flags all counter packets 0 
bytes 0 # handle 26

I someone could explain why I would be grateful because I do not 
comprehend the varying outcome. Is it because after egress/ingress 
traffic hitting handle 21/22 (bottom syntax) the packets are exiting the 
chain after been processed and not reaching handle 25 for processing?

Re: [nftables v0.9.2 | kernel 4.19.93] MSS clamping rule possible in the inet family table?

[Florian Westphal]

ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> Finally got it working in the inet table, seems being a matter of rule
> position (handle value),

The handle has nothing to do with the ordering though, the handle is
just a unique identifier.

> chain forward { # handle 2
>                 type filter hook forward priority filter; policy drop;
>                 ct state established,related accept # handle 19
>                 ct state invalid drop # handle 20
>                 oif "pppoe-wan" tcp flags syn tcp option maxseg size set
> 1300 # handle 21
>                 iif "br-lan" accept # handle 22
>                 oif "br-lan" accept # handle 23
>                 iif "br-mgt" accept # handle 24
>                 oif "br-mgt" accept # handle 25

iif { "br-lan", "br-mgt } accept
oif { "br-lan", "br-mgt } accept

or maybe
iifname "br-*"

saves two rules.

> but this does not
> 
> chain forward { # handle 2
>         type filter hook forward priority filter; policy drop;
>         ct state established,related accept # handle 19
>         ct state invalid drop # handle 20
>         iif "br-lan" accept # handle 21
>         oif "br-lan" accept # handle 22
>         iif "br-mgt" accept # handle 23
>         oif "br-mgt" accept # handle 24
>         oif "pppoe-wan" tcp flags syn tcp option maxseg size set 1300 #
> handle 25
>         log prefix "DROP_FW " level debug flags all counter packets 0 bytes
> 0 # handle 26
> 
> I someone could explain why I would be grateful because I do not comprehend
> the varying outcome. Is it because after egress/ingress traffic hitting
> handle 21/22 (bottom syntax) the packets are exiting the chain after been
> processed and not reaching handle 25 for processing?

Yes, this is no different than iptables, a verdict ends packet
evaluation in that base chain hook.

So, if packet came from "br-lan" forward chain evaluation ends with handle 21.