Hello,
I already read the scenario you pointed to. It is not really the same.
as you can see in my rules I sent before I have CT in both directions.
Related to configuration error I am 99% sure the configuration is
correct. It was generated by automatic tool and then slightly edited
and reviewed
> On 11/09/2021, at 2:54 AM, Marek Greško wrote:
>
> Hello,
>
> thanks you very much for your effort. Without your help I would never
> realize the problem lies in the firewall.
>
> But what do you mean by the doubt that it is bug? You mean it should
> be configured another way? I do not
Hello,
thanks you very much for your effort. Without your help I would never
realize the problem lies in the firewall.
But what do you mean by the doubt that it is bug? You mean it should
be configured another way? I do not claim my configuration is correct.
I am also new to nftables. But I do
> On 10/09/2021, at 4:37 AM, Marek Greško wrote:
>
> There are other systems running on the same hardware. It would just
> leave open ports here.
>
> Do not compare SIP ALG on a closed source device to an opensource
> software with active development. I had no such problems in the past
>
Le 09/09/2021 à 18:15, Marek Greško a écrit :
There is always some risk. If there is a solution that should work, it
is best to use it. We just need the root cause, why it fails
sometimes.
Like SIP ALG ? ;) Please explain which risk are existing if there is
nothing listening on those ports ?
There are other systems running on the same hardware. It would just
leave open ports here.
Do not compare SIP ALG on a closed source device to an opensource
software with active development. I had no such problems in the past
when using iptables. The nftables is a pretty new software, so some
There is always some risk. If there is a solution that should work, it
is best to use it. We just need the root cause, why it fails
sometimes.
Marek
2021-09-09 18:01 GMT+02:00, Antony Stone :
> On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
>
>> Hello,
>>
>> I would not like to
On Thursday 09 September 2021 at 17:56:10, Marek Greško wrote:
> Hello,
>
> I would not like to open whole range of udp ports for rtp.
Why not? What is the risk?
What would possibly be listening on UDP ports 1 - 2 (the Asterisk
default range) which an external scanner / attacker
Hello,
I would not like to open whole range of udp ports for rtp. I use
nf_conntrack_sip module for dynamically opening relevant ports. And
there is probably some bug in it.
Marek
2021-09-08 23:12 GMT+02:00, Administrator :
> Hi. Our rules:
>
> Le 08/09/2021 à 22:43, Marek Greško a écrit :
>>
Hi. Our rules:
Le 08/09/2021 à 22:43, Marek Greško a écrit :
Hello,
I did converted from iptables by automatical script and then rewritten
myself, because not everything was rewritten successfully.
Relevant parts:
table ip filter {
ct helper sip {
type "sip" protocol udp
l3proto
> On 9/09/2021, at 8:46 AM, Marek Greško wrote:
>
> Sorry did convert, not did converted :)
>
> 2021-09-08 22:43 GMT+02:00, Marek Greško :
>> Hello,
>>
>> I did converted from iptables by automatical script and then rewritten
>> myself, because not everything was rewritten successfully.
>>
Sorry did convert, not did converted :)
2021-09-08 22:43 GMT+02:00, Marek Greško :
> Hello,
>
> I did converted from iptables by automatical script and then rewritten
> myself, because not everything was rewritten successfully.
>
> Relevant parts:
>
> table ip filter {
> ct helper sip {
>
Hello,
I did converted from iptables by automatical script and then rewritten
myself, because not everything was rewritten successfully.
Relevant parts:
table ip filter {
ct helper sip {
type "sip" protocol udp
l3proto ip
}
chain PREROUTING {
type filter hook prerouting
> On 9/09/2021, at 6:23 AM, Marek Greško wrote:
>
> Hello,
>
> I confirm temporarily allowing all the udp communication from the nat
> ip address solved the problem, so the problem lies in the nftables.
> This is probably not the right forum to continue. Or is it? Does
> anybody have wide
Hello,
I confirm temporarily allowing all the udp communication from the nat
ip address solved the problem, so the problem lies in the nftables.
This is probably not the right forum to continue. Or is it? Does
anybody have wide experience with nftables and sip?
Thanks
Marek
2021-09-07 10:40
On Monday 06 September 2021 at 23:05:27, Duncan Turnbull wrote:
> > On 7/09/2021, at 8:30 AM, Marek Greško wrote:
> >
> > Hello,
> >
> > it is only local nftables with nf_conntrack_sip on the asterisk
> > server. Probably a kernel bug? It did not trigger with previous
> > providers since they
> On 7/09/2021, at 8:30 AM, Marek Greško wrote:
>
> Hello,
>
> it is only local nftables with nf_conntrack_sip on the asterisk
> server. Probably a kernel bug? It did not trigger with previous
> providers since they had working SIP ALG. Now I hear no audio in both
> directions because
Hello,
it is only local nftables with nf_conntrack_sip on the asterisk
server. Probably a kernel bug? It did not trigger with previous
providers since they had working SIP ALG. Now I hear no audio in both
directions because outgoing rtp stream from asterisk goes to private
address space and
> On 7/09/2021, at 3:08 AM, Marek Greško wrote:
>
> Hello,
>
> so when debugging RTP in asterisk there was no rtp income from the
> remote site. I did check remote nat ip address and it was same as the
> one in the pjsip show aors. So it is not due to ip address change. It
> seems the local
Hello,
so when debugging RTP in asterisk there was no rtp income from the
remote site. I did check remote nat ip address and it was same as the
one in the pjsip show aors. So it is not due to ip address change. It
seems the local firewall sip module does not allow rtp stream to get
into. It was
Sorry rtp set debug on showed something. So let try for the problem to
arise again.
Marek
2021-09-06 11:48 GMT+02:00, Marek Greško :
> Hello,
>
>>> I would expect that when asterisk is aware of nat, it does not send
>>> the rtp until it receives rtp from other side to learn the port, but
>>>
Hello,
>> I would expect that when asterisk is aware of nat, it does not send
>> the rtp until it receives rtp from other side to learn the port, but
>> OK, no problem to accept the behavior.
>>
> That’s not how things work. You should google how sip rtp and Nat work as it
> will help you
no
> On 6/09/2021, at 7:10 PM, Marek Greško wrote:
>
> Hello,
>
>
>
> 2021-09-06 2:51 GMT+02:00, Duncan Turnbull :
>> Hi Marek
>>
>> I didn't understand your setup originally.
>>
>> Can you confirm this is correct:
>>
>> You provide asterisk for a number of remote phones. I assume they
Hello,
2021-09-06 2:51 GMT+02:00, Duncan Turnbull :
> Hi Marek
>
> I didn't understand your setup originally.
>
> Can you confirm this is correct:
>
> You provide asterisk for a number of remote phones. I assume they register
> to the asterisk
>
> Asterisk ( 198.51.100.1) <==> Phone Provider (
Hi Marek
I didn't understand your setup originally.
Can you confirm this is correct:
You provide asterisk for a number of remote phones. I assume they register
to the asterisk
Asterisk ( 198.51.100.1) <==> Phone Provider ( 192.0.2.0/24 ) <==> Phone (
192.168.100.235 )
Your call that fail is
Hello,
regarding the ipv6, you see nothing about that it should be some type
of ipv6 tunnelling, because also MTU is lower than expected. You
should not see any ipv6 related communication in the sniff. Phone is
not aware of it.
The asterisk's static public ip address is 198.51.100.1.
The remote
> On 5/09/2021, at 10:21 AM, Marek Greško wrote:
>
> Hello,
>
> could you please answer my previous question about anonymizing several
> parameters? I have the data ready, but will post after answer. I have
> no clue whether I could disclose some important data not deleting
> them.
>
>
On Sunday 05 September 2021 at 00:54:10, Marek Greško wrote:
> the local provider's router does not possess any ipv4 address on the
> external interface, only ipv6.
So, what do the two addresses which you have labelled in the packet captures
as 198.51.100.1 and 192.0.2.2 correspond to?
I see
Hello,
I first tried to communicate to internet provider but without any
result. They told me I should find problem on my side. It does not
seem the provider is blocking SIP, since it is working for some time
and then stops. But I suspect the problem could be the NAT address
change. The provider
On Thursday 08 July 2021 at 20:57:30, Marek Greško wrote:
> Hello,
>
> I have an asterisk setup using pjsip. Everything used to work
> correctly until one remote site changed internet provider and thier
> router does not support sip protocol algorithms.
I'm slightly bothered by the word
On Sunday 05 September 2021 at 00:19:41, Marek Greško wrote:
> Hello,
>
> could you please answer my previous question about anonymizing several
> parameters? I have the data ready, but will post after answer. I have
> no clue whether I could disclose some important data not deleting
> them.
Hello,
could you please answer my previous question about anonymizing several
parameters? I have the data ready, but will post after answer. I have
no clue whether I could disclose some important data not deleting
them.
Regarding sdp, the address will be the internal one, since the phone
is
On Saturday 04 September 2021 at 22:13:32, Marek Greško wrote:
> Hello,
>
> I agree my knowledge of SIP itself is poor, but I have quite well
> general tcp/ip understanding. What sip parameters should be
> anonymized? How about tag, branch, call-id, cseq values?
Show us your packet captures
Hi Marek
The way it works is that the sip message will carry the sdp and in that will be
the instructions for where to route the rtp
If systems don’t know their external address or are misconfigured they send an
internal address that is not reachable from the far end. This is where lack of
Hello,
I agree my knowledge of SIP itself is poor, but I have quite well
general tcp/ip understanding. What sip parameters should be
anonymized? How about tag, branch, call-id, cseq values?
Thanks
Marek
2021-09-04 12:36 GMT+02:00, Duncan Turnbull :
>
>
>> On 4/09/2021, at 8:55 PM, Marek
> On 4/09/2021, at 8:55 PM, Marek Greško wrote:
>
> Ok,
>
> let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
> asterisk with 198.51.100.1.
Can you provide the previous packet details with these addresses filled in
>
> In the working scenario understand that asterisk is
Ok,
let substitute lan for 192.168.100.235, provider with 192.0.2.1 and
asterisk with 198.51.100.1.
In the working scenario understand that asterisk is not aware of the
providers ip address 192.0.2.1 in the sip protocol, and it should pick
it from the network layer. It is harder to calcutale
On Saturday 04 September 2021 at 00:34:49, Duncan Turnbull wrote:
> > On 4/09/2021, at 7:53 AM, Marek Greško wrote:
> >
> > So you suspect something is messing up SIP protocol? Maybe the phone
> > itself is not working properly. The phone itself is not aware of the
> > internet address, so is
> On 4/09/2021, at 7:53 AM, Marek Greško wrote:
>
> So you suspect something is messing up SIP protocol? Maybe the phone
> itself is not working properly. The phone itself is not aware of the
> internet address, so is sending lan private address in the sip
> protocol.
I doubt it’s the phone.
So you suspect something is messing up SIP protocol? Maybe the phone
itself is not working properly. The phone itself is not aware of the
internet address, so is sending lan private address in the sip
protocol. I would expect asterisk itself is pairing the provider
address with the lan address. I
On Fri, Sep 3, 2021 at 8:47 PM Marek Greško wrote:
> Hello,
>
> I looked into tcpdumps. When problem starts (after some asterisk
> reboot) the call looks like this:
>
> provider:25298 -> asterisk:5060
> SIP: SIP/2.0 200 OK
> Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
> From: ;tag=...
>
Hello,
I looked into tcpdumps. When problem starts (after some asterisk
reboot) the call looks like this:
provider:25298 -> asterisk:5060
SIP: SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk:5060;rport=5060;branch=...
From: ;tag=...
To: ;tag=...
Call-ID: ...
CSeq: ... INVITE
Contact:
Supported:
Hello,
it triggered again. Even disabling RTSp ALG did not help. My fantasy
ends here. It agains seems to be reboot triggered on asterisk side.
Not every one. But there was surely one before it was last working.
Reboot of the router on the phone side fixes the problem. Any other
suggestions?
Hello,
it triggered again. Even disabling RTSp ALG did not help. My fantasy
ends here. It agains seems to be reboot triggered on asterisk side.
Not every one. But there was surely one before it was last working.
Reboot of the router on the phone side fixes the problem. Any other
suggestions?
I currently disabled also RTSP ALG and rebooted the router. Fixed for
now. I do not know for how long.
Marek
2021-07-26 8:54 GMT+02:00, Marek Greško :
> Hmm, back to original problem. My happines was premature. Today one of
> the phones have no audio again. I see packets from lan segment again.
Hmm, back to original problem. My happines was premature. Today one of
the phones have no audio again. I see packets from lan segment again.
I double checked the router configuration. SIP ALG is disabled. There
are also another ALGs present:
NAT ALG
RTSP ALG
PPTP ALG
IPSEC ALG
Which of them are
I achieved a partial success adding --use-compact-form option.
Marek
2021-07-23 13:47 GMT+02:00, Marek Greško :
> Hello,
>
> your suggestion to turn off SIP ALG on provider's router was probably
> correct. no problem until now. Thank you very much.
>
> I just found out another issue. I had a
Hello,
your suggestion to turn off SIP ALG on provider's router was probably
correct. no problem until now. Thank you very much.
I just found out another issue. I had a pjsue client in that network
which called specific number when turned on. It was working perfectly
with the old provider with
Hello,
I just disabled. Currently it is working. I shloud give it some time
to confirm the problem has gone. Maybe one month would be enough to
confirm.
Thanks
Marek
2021-07-09 20:11 GMT+02:00, Abdenasser Ghomri :
> Yes just disable the SIP ALG and see if it helps, Thanks.
>
> Best Regards,
>
Yes just disable the SIP ALG and see if it helps, Thanks.
Best Regards,
On Fri, Jul 9, 2021, 09:10 Antony Stone <
antony.st...@asterisk.open.source.it> wrote:
> On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
>
> > Hello,
> >
> > yes SIP ALG are anbled on the router. Should I disable?
>
On Friday 09 July 2021 at 08:47:46, Marek Greško wrote:
> Hello,
>
> yes SIP ALG are anbled on the router. Should I disable?
In my opinion, always.
Antony.
--
I don't know, maybe if we all waited then cosmic rays would write all our
software for us. Of course it might take a while.
- Ron
To be more specific I was on the
https://wiki.asterisk.org/wiki/display/AST/Getting+Started already,
but I assume all the additional transport parameters are relevant only
when asterisk itself is behind nat. Is not it true?
Marek
2021-07-09 8:47 GMT+02:00, Marek Greško :
> Hello,
>
> yes SIP
Hello,
yes SIP ALG are anbled on the router. Should I disable?
Transport config looks like that:
[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
domain = mydomain.com
Asterisk itself is not natted.
Marek
2021-07-08 21:14 GMT+02:00, Michael L. Young :
> El jue, 8 de jul. de
El jue, 8 de jul. de 2021 a la(s) 14:58, Marek Greško (mgres...@gmail.com)
escribió:
> The asterisk is connected to the internet with public static IP address.
>
> The pjsip config contains:
>
>
What does your transport config look like?
Take a look at this wiki page:
Have you tried to see if the router has any SIP ALG enabled this might
create such issues, Thanks.
Best Regards,
On Thu, Jul 8, 2021, 19:59 Marek Greško wrote:
> Hello,
>
> I have an asterisk setup using pjsip. Everything used to work
> correctly until one remote site changed internet
Hello,
I have an asterisk setup using pjsip. Everything used to work
correctly until one remote site changed internet provider and thier
router does not support sip protocol algorithms.
It works for some time, but then suddenly audio stops working both
directions. When this happens I see RTP
56 matches
Mail list logo
