All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Greško" <mgresko8@gmail.com>
To: netfilter@vger.kernel.org
Subject: Fwd: nftables and connection tracking
Date: Fri, 24 Sep 2021 07:21:32 +0200	[thread overview]
Message-ID: <CAChjPdQ8yUEyFuAiHiw+FZgnvNWjc1wM2LTcffyr_f49x4X7Aw@mail.gmail.com> (raw)
In-Reply-To: <CAChjPdREO=jtTNGc32H3mv+Zv8AHKbujb_a8=tkwC0+b2sbVCQ@mail.gmail.com>

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

  parent reply	other threads:[~2021-09-24  5:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-21  5:54 nftables and connection tracking Marek Greško
2020-06-21  8:06 ` Florian Westphal
     [not found]   ` <CAChjPdQtKBGuUvdveCVc5kmhA+fgP4DUDNKhNd11KUVCKNUZLg@mail.gmail.com>
     [not found]     ` <20200621090142.GL26990@breakpoint.cc>
2020-06-21  9:39       ` Marek Greško
2020-06-21 10:45         ` Florian Westphal
2020-06-21 11:33           ` Marek Greško
2020-07-01 20:01           ` Marek Greško
2020-07-01 22:48             ` Florian Westphal
2020-07-02 19:33               ` Marek Greško
2020-07-02 19:47                 ` Pablo Neira Ayuso
     [not found]                   ` <CAChjPdQb5wUP7Qbz=D-0jg-YFC0cWgV4oPJQD9-G7evi3SupAw@mail.gmail.com>
     [not found]                     ` <YUk8dCSHCUcKn+Xy@salvia>
     [not found]                       ` <CAChjPdREO=jtTNGc32H3mv+Zv8AHKbujb_a8=tkwC0+b2sbVCQ@mail.gmail.com>
2021-09-24  5:21                         ` Marek Greško [this message]
2021-09-24  7:19                           ` Fwd: " Daniel
2020-06-22 12:06 ` Pablo Neira Ayuso
2020-06-22 17:18   ` Marek Greško
2020-06-22 21:35     ` Marek Greško

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAChjPdQ8yUEyFuAiHiw+FZgnvNWjc1wM2LTcffyr_f49x4X7Aw@mail.gmail.com \
    --to=mgresko8@gmail.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.