20 Feb
2023
20 Feb
'23
9:12 a.m.
Hi
Sorry for the OT but I think here's the place where I an find a lot of Ms teams
integrations
I've been working on MS teams direct routing integration for PekePBX. It works.
I guess I've done it as everybody else, using Henning's guide as base and
extending it for multitenant setup (thanks Henning!)
What I've realized is that the source IP address of calls coming from MS are
not always matching dispatcher hosts. Sometimes they come from another source
IP and failover to the dispatcher hosts when they receive no response. That
makes some of the calls to have an additional latency
Searching in the MS doc I see that they document these nets as source of their
signaling:
52.112.0.0/14
52.120.0.0/14
But I've seen IP addresses outside of this range as source.
In this blog
https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/
The ranges are listed as
52.112.0.0/16
52.113.0.0/16
52.114.0.0/16
52.115.0.0/16
52.120.0.0/16
52.121.0.0/16
52.122.0.0/16
52.123.0.0/16
which looks better but scares me out. Having no auth is it secure to bind so
many ranges to MS?
Do you use anything else than certificate verification for these calls?
cheers,
Jon
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
20 Feb
20 Feb
11:08 a.m.
Yeah, don’t trust that IP range blindly. It’s just Azure space.
The only logical approach I’ve seen appears to be certificate validation and checking.
On 20 Feb 2023, at 7:00 pm, Jon Bonilla (Manwe)
<manwe(a)sipdoc.net> wrote:
Hi
Sorry for the OT but I think here's the place where I an find a lot of Ms teams
integrations
I've been working on MS teams direct routing integration for PekePBX. It works.
I guess I've done it as everybody else, using Henning's guide as base and
extending it for multitenant setup (thanks Henning!)
What I've realized is that the source IP address of calls coming from MS are
not always matching dispatcher hosts. Sometimes they come from another source
IP and failover to the dispatcher hosts when they receive no response. That
makes some of the calls to have an additional latency
Searching in the MS doc I see that they document these nets as source of their
signaling:
52.112.0.0/14
52.120.0.0/14
But I've seen IP addresses outside of this range as source.
In this blog
https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/
The ranges are listed as
52.112.0.0/16
52.113.0.0/16
52.114.0.0/16
52.115.0.0/16
52.120.0.0/16
52.121.0.0/16
52.122.0.0/16
52.123.0.0/16
which looks better but scares me out. Having no auth is it secure to bind so
many ranges to MS?
Do you use anything else than certificate verification for these calls?
cheers,
Jon
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
23 Feb
23 Feb
11:39 a.m.
El Mon, 20 Feb 2023 20:08:50 +1000
Richard Edmands <thesirdmz(a)gmail.com> escribió:
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
Yeah, don’t trust that IP range blindly. It’s just
Azure space.
The only logical approach I’ve seen appears to be certificate validation and
checking.
okok.
I can see that the client certificate is being validated. But that means the
client certificate is valid. Doesn't mean that the certificate is microsoft.
Is there a way to check the certificate owner in the config script? Or to limit
the certificate to a certain "Subject Alternative Name"?
Would it be nuts to limit the CA list allowed for that socket creating a custom
ca list? It still would not filter just MS.
In the end I guess I'll get an IP list and filter because opening two /14 nets
seems crazy to me.
On 20 Feb 2023, at 7:00 pm, Jon Bonilla (Manwe)
<manwe(a)sipdoc.net> wrote:
Hi
Sorry for the OT but I think here's the place where I an find a lot of Ms
teams integrations
I've been working on MS teams direct routing integration for PekePBX. It
works. I guess I've done it as everybody else, using Henning's guide as
base and extending it for multitenant setup (thanks Henning!)
What I've realized is that the source IP address of calls coming from MS are
not always matching dispatcher hosts. Sometimes they come from another
source IP and failover to the dispatcher hosts when they receive no
response. That makes some of the calls to have an additional latency
Searching in the MS doc I see that they document these nets as source of
their signaling:
52.112.0.0/14
52.120.0.0/14
But I've seen IP addresses outside of this range as source.
In this blog
https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/
The ranges are listed as
52.112.0.0/16
52.113.0.0/16
52.114.0.0/16
52.115.0.0/16
52.120.0.0/16
52.121.0.0/16
52.122.0.0/16
52.123.0.0/16
which looks better but scares me out. Having no auth is it secure to bind so
many ranges to MS?
Do you use anything else than certificate verification for these calls?
cheers,
Jon
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender! Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender! Edit mailing list options or unsubscribe: 
12:59 p.m.
You can also check the issuer of the certificate, there should be some
variable in the config returning that when incoming traffic is over tls
and the peer has presented a certificate.
Cheers,
Daniel
On 23.02.23 11:39, Jon Bonilla (Manwe) wrote:
El Mon, 20 Feb 2023 20:08:50 +1000
Richard Edmands <thesirdmz(a)gmail.com> escribió:
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com
Yeah, don’t trust that IP range blindly. It’s
just Azure space.
The only logical approach I’ve seen appears to be certificate validation and
checking.
okok.
I can see that the client certificate is being validated. But that means the
client certificate is valid. Doesn't mean that the certificate is microsoft.
Is there a way to check the certificate owner in the config script? Or to limit
the certificate to a certain "Subject Alternative Name"?
Would it be nuts to limit the CA list allowed for that socket creating a custom
ca list? It still would not filter just MS.
In the end I guess I'll get an IP list and filter because opening two /14 nets
seems crazy to me.
On 20 Feb
2023, at 7:00 pm, Jon Bonilla (Manwe) <manwe(a)sipdoc.net> wrote:
Hi
Sorry for the OT but I think here's the place where I an find a lot of Ms
teams integrations
I've been working on MS teams direct routing integration for PekePBX. It
works. I guess I've done it as everybody else, using Henning's guide as
base and extending it for multitenant setup (thanks Henning!)
What I've realized is that the source IP address of calls coming from MS are
not always matching dispatcher hosts. Sometimes they come from another
source IP and failover to the dispatcher hosts when they receive no
response. That makes some of the calls to have an additional latency
Searching in the MS doc I see that they document these nets as source of
their signaling:
52.112.0.0/14
52.120.0.0/14
But I've seen IP addresses outside of this range as source.
In this blog
https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/
The ranges are listed as
52.112.0.0/16
52.113.0.0/16
52.114.0.0/16
52.115.0.0/16
52.120.0.0/16
52.121.0.0/16
52.122.0.0/16
52.123.0.0/16
which looks better but scares me out. Having no auth is it secure to bind so
many ranges to MS?
Do you use anything else than certificate verification for these calls?
cheers,
Jon
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender! Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender! Edit mailing list options or unsubscribe:
24 Feb
24 Feb
10:08 a.m.
El Thu, 23 Feb 2023 12:59:42 +0100
Daniel-Constantin Mierla <miconda(a)gmail.com> escribió:
You can also check the issuer of the certificate,
there should be some
variable in the config returning that when incoming traffic is over tls
and the peer has presented a certificate.
Right
I was checking only in the tls module, not in the pseudovariables documentation.
I should know that there's always a pseudovariable for your needs.
Will check that.
Thanks Daniel.
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
20 Feb
20 Feb
2:06 p.m.
Hello,
correct me if I am wrong, but the second group of addresses ("/16") is included
in the first group ("/14"), right?
Regarding the large IP scope, this is the way Microsoft designed it, unfortunately. There
is not that much what you can do about.
Cheers,
Henning
-----Original Message-----
From: Jon Bonilla (Manwe) <manwe(a)sipdoc.net>
Sent: Montag, 20. Februar 2023 09:12
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] OT: MS Teams source IP address ranges
Hi
Sorry for the OT but I think here's the place where I an find a lot of Ms teams
integrations
I've been working on MS teams direct routing integration for PekePBX. It works.
I guess I've done it as everybody else, using Henning's guide as base and
extending it for multitenant setup (thanks Henning!)
What I've realized is that the source IP address of calls coming from MS are not
always matching dispatcher hosts. Sometimes they come from another source IP and failover
to the dispatcher hosts when they receive no response. That makes some of the calls to
have an additional latency
Searching in the MS doc I see that they document these nets as source of their
signaling:
52.112.0.0/14
52.120.0.0/14
But I've seen IP addresses outside of this range as source.
In this blog
https://erwinbierens.com/microsoft-teams-direct-routing-ip-addresses/
The ranges are listed as
52.112.0.0/16
52.113.0.0/16
52.114.0.0/16
52.115.0.0/16
52.120.0.0/16
52.121.0.0/16
52.122.0.0/16
52.123.0.0/16
which looks better but scares me out. Having no auth is it secure to bind so many ranges
to MS?
Do you use anything else than certificate verification for these calls?
cheers,
Jon
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
3:49 p.m.
El Mon, 20 Feb 2023 13:06:30 +0000
Henning Westerholt <hw(a)gilawa.com> escribió:
Hello,
correct me if I am wrong, but the second group of addresses ("/16") is
included in the first group ("/14"), right?
Regarding the large IP scope, this is the way Microsoft designed it,
unfortunately. There is not that much what you can do about.
Right. Didn't check the masks. they all were 16 in my mind :)
So, if I add those ranges in the permissions table my only way of avoiding
spoofed calls is certificate validation? I'm already doing that and also
checking the company domain and ms account email address. Just wanted to be
sure that nothing "essential" was missing.
--
PekePBX, the multitenant PBX solution
https://pekepbx.com
420
days inactive
424
days old
6 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Jon Bonilla (Manwe) -
Richard Edmands