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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/02/2020 12:46, ѽ҉ᶬḳ℠ wrote:
On 05/02/2020 11:26, Florian Westphal wrote:
ѽ҉ᶬḳ℠ <vtol@xxxxxxx> 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?




[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux