nftables and connection tracking

nftables and connection tracking

[Marek Greško]

Hello,

I have problem to get connection tracking work when using nftables. I
have this setup on my fedora 32:

table ip raw {
        chain PREROUTING {
                type filter hook prerouting priority raw; policy accept;
                meta l4proto udp udp dport 5060 # CT helper sip
        }

        chain OUTPUT {
                type filter hook output priority raw; policy accept;
                meta l4proto udp udp dport 5060 # CT helper sip
        }
}

/etc/modules-load.d/conntrack.conf:

nf_conntrack_ftp
nf_conntrack_sip
nf_conntrack_h323
nf_conntrack_irc
nf_conntrack_amanda
nf_conntrack_netbios_ns
nf_conntrack_netlink
nf_conntrack_pptp
nf_conntrack_tftp
nf_conntrack_broadcast
nf_conntrack_snmp
nf_conntrack_sane
nf_nat
nf_nat_ftp
nf_nat_sip
nf_nat_h323
nf_nat_irc
nf_nat_amanda
nf_nat_pptp
nf_nat_snmp_basic
nf_nat_tftp

but I get no sound. When using iptables, everything is working. Should
this be configured diffrent way?

Thanks.

Marek

Re: nftables and connection tracking

[Florian Westphal]

Marek Gre¨ko <mgresko8@gmail.com> wrote:
> I have problem to get connection tracking work when using nftables. I
> have this setup on my fedora 32:
> 
> table ip raw {
>         chain PREROUTING {
>                 type filter hook prerouting priority raw; policy accept;
>                 meta l4proto udp udp dport 5060 # CT helper sip
>         }
> 
>         chain OUTPUT {
>                 type filter hook output priority raw; policy accept;
>                 meta l4proto udp udp dport 5060 # CT helper sip
>         }

These rules don't do anything (it matches udp 5060, but no action is
given).  I suspect this from xtables-translate, which did not understand
the -j CT --helper sip rule.

This needs something like:
table ip raw {
   ct helper sip {
     type "sip" protocol udp
   }
   chain prerouting {
       meta l4proto udp udp dport 5060 ct helper set "sip"
   }

# same for output
}

Re: nftables and connection tracking

[Marek Greško]

Hello,

unfortunately the helper is not there:

conntrack -L | grep sip                     -> no output

It is strange, that if I use iptables-nft it is working. Some userspace problem?

Marek


2020-06-21 11:01 GMT+02:00, Florian Westphal <fw@strlen.de>:
> Marek Greško <mgresko8@gmail.com> wrote:
>> Hello,
>>
>> thanks for your help. Unfortunately, it does not work either.
>
> Please keep mailing list on CC.
>
>> table ip raw {
>>         ct helper sip {
>>                 type "sip" protocol udp
>>         }
>>
>>         ct helper ftp {
>>                 type "ftp" protocol tcp
>>         }
>>
>>         chain PREROUTING {
>>                 type filter hook prerouting priority raw; policy accept;
>>                 meta l4proto udp udp dport 5060 ct helper set "sip"
>>                 meta l4proto tcp tcp dport 21 ct helper set "ftp"
>>         }
>>
>>         chain OUTPUT {
>>                 type filter hook output priority raw; policy accept;
>>                 meta l4proto udp udp dport 5060 ct helper set "sip"
>>                 meta l4proto tcp tcp dport 21 ct helper set "ftp"
>>         }
>> }
>
> Looks good.
>
>> Still nothing.
>
> Hmm, give it worked with iptables it should work with nft too since
> the tracker is the same code.
>
> Try 'conntrack -L' and check if the udp flow has a helper assigned.
> You might need to flush the conntrack table to make it pick up the
> tracker (assigning it only works at the start of the connection).
>

Re: nftables and connection tracking

[Florian Westphal]

Marek Gre¨ko <mgresko8@gmail.com> wrote:
> Hello,
> 
> unfortunately the helper is not there:
> 
> conntrack -L | grep sip                     -> no output
> 
> It is strange, that if I use iptables-nft it is working. Some userspace problem?

No, looks more like a kernel bug to me, I will have a look on
Monday.

In mean time, you can work around this bug by removing the entire "ip
raw" / "ct set" stuff.

and then use:
sysctl net.netfilter.nf_conntrack_helper=1

to re-enable the old auto-assign behaviour.

Re: nftables and connection tracking

[Marek Greško]

Hello,

thanks for the sysctl tip. It is wokring.

The iptables-nft does not configure the nftables kernel in the same
way? Because I did not see the problem when using it.

Marek


2020-06-21 12:45 GMT+02:00, Florian Westphal <fw@strlen.de>:
> Marek Greško <mgresko8@gmail.com> wrote:
>> Hello,
>>
>> unfortunately the helper is not there:
>>
>> conntrack -L | grep sip                     -> no output
>>
>> It is strange, that if I use iptables-nft it is working. Some userspace
>> problem?
>
> No, looks more like a kernel bug to me, I will have a look on
> Monday.
>
> In mean time, you can work around this bug by removing the entire "ip
> raw" / "ct set" stuff.
>
> and then use:
> sysctl net.netfilter.nf_conntrack_helper=1
>
> to re-enable the old auto-assign behaviour.
>

Re: nftables and connection tracking

[Pablo Neira Ayuso]

On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek Greško wrote:
> Hello,
> 
> I have problem to get connection tracking work when using nftables. I
> have this setup on my fedora 32:
> 
> table ip raw {
>         chain PREROUTING {
>                 type filter hook prerouting priority raw; policy accept;

Could you try from the filter (0) priority instead ?

                  type filter hook prerouting priority filter; policy accept;

Thanks.

Re: nftables and connection tracking

[Marek Greško]

Hello,

after changing priority it is working. It was a configuration error or a bug?

Marek


2020-06-22 14:06 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>:
> On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek Greško wrote:
>> Hello,
>>
>> I have problem to get connection tracking work when using nftables. I
>> have this setup on my fedora 32:
>>
>> table ip raw {
>>         chain PREROUTING {
>>                 type filter hook prerouting priority raw; policy accept;
>
> Could you try from the filter (0) priority instead ?
>
>                   type filter hook prerouting priority filter; policy
> accept;
>
> Thanks.
>

Re: nftables and connection tracking

[Marek Greško]

Hello Florian,

I am just thinking about what I did now when I changed the priority to
filter. For prerouting it is clear, since there is no other chain with
hook prerouting. But for output there is another one in the table
filter. Which one is proceeded first if they are the same priority?
what is they have conflicting policy? If the first one is drop, the
second chain will not proceed if not allowed in the first one?

If these priorities should be filter would not it be making more sense
to move the rules to the chains in the table filter?

Marek


2020-06-22 19:18 GMT+02:00, Marek Greško <mgresko8@gmail.com>:
> Hello,
>
> after changing priority it is working. It was a configuration error or a
> bug?
>
> Marek
>
>
> 2020-06-22 14:06 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>:
>> On Sun, Jun 21, 2020 at 07:54:14AM +0200, Marek Greško wrote:
>>> Hello,
>>>
>>> I have problem to get connection tracking work when using nftables. I
>>> have this setup on my fedora 32:
>>>
>>> table ip raw {
>>>         chain PREROUTING {
>>>                 type filter hook prerouting priority raw; policy accept;
>>
>> Could you try from the filter (0) priority instead ?
>>
>>                   type filter hook prerouting priority filter; policy
>> accept;
>>
>> Thanks.
>>
>

Re: nftables and connection tracking

[Marek Greško]

Hi Florian,

please is it a bug the rules did not work in the raw table or was it
my configuration error?

If it is a bug is it a bug of kernel or userspace?

If it was my configuration error, should not be the rules moved to the
filter table?

How is it possible that using iptables-nft the rules are added to the
raw table and it is working?

Thanks

Marek


2020-06-21 12:45 GMT+02:00, Florian Westphal <fw@strlen.de>:
> Marek Greško <mgresko8@gmail.com> wrote:
>> Hello,
>>
>> unfortunately the helper is not there:
>>
>> conntrack -L | grep sip                     -> no output
>>
>> It is strange, that if I use iptables-nft it is working. Some userspace
>> problem?
>
> No, looks more like a kernel bug to me, I will have a look on
> Monday.
>
> In mean time, you can work around this bug by removing the entire "ip
> raw" / "ct set" stuff.
>
> and then use:
> sysctl net.netfilter.nf_conntrack_helper=1
>
> to re-enable the old auto-assign behaviour.
>

Re: nftables and connection tracking

[Florian Westphal]

Marek Gre¨ko <mgresko8@gmail.com> wrote:
> please is it a bug the rules did not work in the raw table or was it
> my configuration error?

Config error.

> How is it possible that using iptables-nft the rules are added to the
> raw table and it is working?

iptables-nft and fntables are not the same.
-j CT works with 'connection tracking templates',
but the nft equivalent sets the helper directly.

So, for iptables (and iptables-nft), the rule needs to be
executed before conntrack lookup.  With nft it has to be done
after conntrack lookup.

Re: nftables and connection tracking

[Marek Greško]

Great, thanks for explanation.

Now I have two chains OUTPUT with priority filter. One in the table
raw and second in the table filter (currently both of them with policy
accept). Is that correct? What is the order of evaluation? The order
it appears in config file? Should not one of the priorities be changed
to (filter + 1) or the rules moved to the filter table?

Thanks

Marek


2020-07-02 0:48 GMT+02:00, Florian Westphal <fw@strlen.de>:
> Marek Greško <mgresko8@gmail.com> wrote:
>> please is it a bug the rules did not work in the raw table or was it
>> my configuration error?
>
> Config error.
>
>> How is it possible that using iptables-nft the rules are added to the
>> raw table and it is working?
>
> iptables-nft and fntables are not the same.
> -j CT works with 'connection tracking templates',
> but the nft equivalent sets the helper directly.
>
> So, for iptables (and iptables-nft), the rule needs to be
> executed before conntrack lookup.  With nft it has to be done
> after conntrack lookup.
>

Re: nftables and connection tracking

[Pablo Neira Ayuso]

On Thu, Jul 02, 2020 at 09:33:41PM +0200, Marek Greško wrote:
> Great, thanks for explanation.
> 
> Now I have two chains OUTPUT with priority filter. One in the table
> raw and second in the table filter (currently both of them with policy
> accept). Is that correct? What is the order of evaluation? The order
> it appears in config file? Should not one of the priorities be changed
> to (filter + 1) or the rules moved to the filter table?

Move them to the "filter" table, no need to define a new chain. Chains
are somewhat expensives: one of the good things about nftables is that
you can define the chains that you need.

Chains whose priority is filter (0) see packets with the conntrack
information. Anything from priority -200 onwards (INT_MAX) have access
to the conntrack information.

Priorities from INT_MIN to -199 see no conntrack information (what it
used to be the "raw" table semantics).

In nftables, tables have no specific semantics anymore, it's the chain
priority that specifies what semantics apply to your basechain.

Thanks.

Fwd: nftables and connection tracking

[Marek Greško]

Sorry, repost to the mailing list.

Marek

---------- Forwarded message ----------
From: Marek Greško <mgresko8@gmail.com>
Date: Thu, 23 Sep 2021 20:05:33 +0200
Subject: Re: nftables and connection tracking
To: Pablo Neira Ayuso <pablo@netfilter.org>

Hello,

no rule is blocking traffic. There is no match for rule so the udp
drops. If I add accept rule as a last rule of the INPUT chain, it
works.

I tried conntrack -F without any progress.
The conntrack -L expect shows some local sip phone 5060 connections
and sip provider connection. No nat phones here. Even after reboot
when it is working after reboot there is nothing about natted phones,

Yes debugging would be probably the best, could you tell me how to
debug it? I had never such firewall problems for 25 years history. I
did not try to revert to iptables yet.

To be honest, I do not expect it to be a configuration problem, but
one never knows.

Thanks

Marek


2021-09-21 3:59 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>:
> On Thu, Sep 16, 2021 at 10:32:01PM +0200, Marek Greško wrote:
>> Hello,
>>
>> I would like to make the revival of this thread. My current
>> configuration looks like this:
>>
>> table ip filter {
>>   ct helper sip {
>>     type "sip" protocol udp
>>     l3proto ip
>>   }
>>
>>   chain PREROUTING {
>>     type filter hook prerouting priority filter; policy accept;
>>     udp port 5060 ct helper set "sip"
>>   }
>>
>>   chain INPUT {
>>     ...
>>     ct state invalid drop
>>     ct state related accept
>>     ct state established accept
>>     ...
>>     iifname "ppp0" jump i-inet
>>   }
>>
>>   chain OUTPUT {
>>     type filter hook output priority filter; policy accept;
>>     udp port 5060 ct helper set "sip"
>>     ...
>>   }
>>
>>   chain i-inet {
>>     ...
>>     udp port 5060 jump r-sip
>>     ...
>>   }
>>
>>   chain r-sip {
>>     ip saddr 192.0.2.0/24 accept
>>   }
>> }
>>
>> table ip mangle {
>>   chain PREROUTING {
>>     type filter hook prerouting priority mangle; policy accept;
>>     ...
>>     udp sport 5060 ip dscp set 0x04
>>   }
>>
>>   chain OUTPUT {
>>     type route hook output priority mangle; policy accept;
>>     ...
>>     udp dport 5060 ip dscp set 0x04
>>     ...
>>   }
>> }
>>
>> table ip6 filter {
>>   ct helper sip {
>>     type "sip" protocol udp
>>     l3proto ip6
>>   }
>>
>>   ... pretty the same, but I have no ipv6 internet connectivity, so
>> this should not match ...
>>
>> }
>>
>> I run the nftables locally on the asterisk server. The phones located
>> on the local lan are working ok. But the remote phones behind nat are
>> experiencing intermittent problems. After several days of working
>> there is suddenly no audio. We with some guys on the asterisk list
>> have found out it is a nftables problem. But I am not sure whether it
>> is configuration problem or a bug.
>>
>> The problem is that when the rtp stream is built the stream incoming
>> to asterisk is blocked by nftables
>
> What rule is blocking the traffic?
>
>> and thus asterisk never learns the
>> public ip of the remote phone and is sending rtp stream to it's
>> internal address. So there is no audio in either direction. When I
>> enable rtp udp port range to pass to the asterisk it works. After
>> blocking again it stops working. To resolve the problem for several
>> days I found out that rebooting of the remote router resolves the
>> issue.
>
> Did you try 'conntrack -F' instead of rebooting to flush the conntrack
> table? What does 'conntrack -L expect' shows?
>
>> I have one successful resolving by rebooting the asterisk
>> server the problematic nftables is running on. The proble arises again
>> in several days. The problem is too frequent to be accepted, but too
>> rare to be debugged. I have not tried the trick with sysctl above,
>> yet.
>>
>> Do you think this could be a configuration problem?
>
> Even if it's a configuration problem, debugging the ruleset would be
> needed.
>

Re: Fwd: nftables and connection tracking

[Daniel]

Hello,

For the list information, on Asterisk list we asked Marek to open UDP 
RTP range ports but he don't want (security reason are his words). We 
run few Asterik servers with nftables, various versions, and never run 
any problem. And we are from far not alone with such setup.

Le 24/09/2021 à 07:21, Marek Greško a écrit :
> Sorry, repost to the mailing list.
>
> Marek
>
> ---------- Forwarded message ----------
> From: Marek Greško <mgresko8@gmail.com>
> Date: Thu, 23 Sep 2021 20:05:33 +0200
> Subject: Re: nftables and connection tracking
> To: Pablo Neira Ayuso <pablo@netfilter.org>
>
> Hello,
>
> no rule is blocking traffic. There is no match for rule so the udp
> drops. If I add accept rule as a last rule of the INPUT chain, it
> works.
>
> I tried conntrack -F without any progress.
> The conntrack -L expect shows some local sip phone 5060 connections
> and sip provider connection. No nat phones here. Even after reboot
> when it is working after reboot there is nothing about natted phones,
>
> Yes debugging would be probably the best, could you tell me how to
> debug it? I had never such firewall problems for 25 years history. I
> did not try to revert to iptables yet.
>
> To be honest, I do not expect it to be a configuration problem, but
> one never knows.
>
> Thanks
>
> Marek
>
>
> 2021-09-21 3:59 GMT+02:00, Pablo Neira Ayuso <pablo@netfilter.org>:
>> On Thu, Sep 16, 2021 at 10:32:01PM +0200, Marek Greško wrote:
>>> Hello,
>>>
>>> I would like to make the revival of this thread. My current
>>> configuration looks like this:
>>>
>>> table ip filter {
>>>    ct helper sip {
>>>      type "sip" protocol udp
>>>      l3proto ip
>>>    }
>>>
>>>    chain PREROUTING {
>>>      type filter hook prerouting priority filter; policy accept;
>>>      udp port 5060 ct helper set "sip"
>>>    }
>>>
>>>    chain INPUT {
>>>      ...
>>>      ct state invalid drop
>>>      ct state related accept
>>>      ct state established accept
>>>      ...
>>>      iifname "ppp0" jump i-inet
>>>    }
>>>
>>>    chain OUTPUT {
>>>      type filter hook output priority filter; policy accept;
>>>      udp port 5060 ct helper set "sip"
>>>      ...
>>>    }
>>>
>>>    chain i-inet {
>>>      ...
>>>      udp port 5060 jump r-sip
>>>      ...
>>>    }
>>>
>>>    chain r-sip {
>>>      ip saddr 192.0.2.0/24 accept
>>>    }
>>> }
>>>
>>> table ip mangle {
>>>    chain PREROUTING {
>>>      type filter hook prerouting priority mangle; policy accept;
>>>      ...
>>>      udp sport 5060 ip dscp set 0x04
>>>    }
>>>
>>>    chain OUTPUT {
>>>      type route hook output priority mangle; policy accept;
>>>      ...
>>>      udp dport 5060 ip dscp set 0x04
>>>      ...
>>>    }
>>> }
>>>
>>> table ip6 filter {
>>>    ct helper sip {
>>>      type "sip" protocol udp
>>>      l3proto ip6
>>>    }
>>>
>>>    ... pretty the same, but I have no ipv6 internet connectivity, so
>>> this should not match ...
>>>
>>> }
>>>
>>> I run the nftables locally on the asterisk server. The phones located
>>> on the local lan are working ok. But the remote phones behind nat are
>>> experiencing intermittent problems. After several days of working
>>> there is suddenly no audio. We with some guys on the asterisk list
>>> have found out it is a nftables problem. But I am not sure whether it
>>> is configuration problem or a bug.
>>>
>>> The problem is that when the rtp stream is built the stream incoming
>>> to asterisk is blocked by nftables
>> What rule is blocking the traffic?
>>
>>> and thus asterisk never learns the
>>> public ip of the remote phone and is sending rtp stream to it's
>>> internal address. So there is no audio in either direction. When I
>>> enable rtp udp port range to pass to the asterisk it works. After
>>> blocking again it stops working. To resolve the problem for several
>>> days I found out that rebooting of the remote router resolves the
>>> issue.
>> Did you try 'conntrack -F' instead of rebooting to flush the conntrack
>> table? What does 'conntrack -L expect' shows?
>>
>>> I have one successful resolving by rebooting the asterisk
>>> server the problematic nftables is running on. The proble arises again
>>> in several days. The problem is too frequent to be accepted, but too
>>> rare to be debugged. I have not tried the trick with sysctl above,
>>> yet.
>>>
>>> Do you think this could be a configuration problem?
>> Even if it's a configuration problem, debugging the ruleset would be
>> needed.
>>
-- 
Daniel