Unknown Office 365 IP address

[Kenneth Meyer-Lassen]

I saw at a customer site today, a STUN request going from the client to 13.100.4.192. By looking at the src and dest ports, I would say this is a video session trying to establish a connection to a meeting.

This IP address is not listed in any of the Office 365 IP ranges, so the traffic is blocked by the firewall. After some time the client tries to connect to a 52.112.0.0/14 host and the RTP flow is established towards this host.

This influences user experience as the connection takes longer time than necessary.

Does anyone know this IP address and which range should be allowed for this to connect??

/Kenneth ML

[#2]

See that the src and dst ports are on the higher upper side, I'm think they may have CDN defined and that is the agent on the machine?  I know Hive agent uses 40K to 69K range. ALso the IP belongs to MSFT. 

[#3]

The answer is here https://techcommunity.microsoft.com/t5/Skype-Operations-Framework-Skype/Updated-IP-ranges-and-ports-...
• New IP ranges: We already started to move the Skype for Business infrastructure to the following port ranges:
o 13.107.64.0/18
o 52.112.0.0/14

[#4]

Hi Leonardo.

Thanks for taking your time to reply, but unfortunately your suggestion is not correct. The IP address 13.100.4.192 is not in the documented new ranges for Office 365 (13.107.64.0/18 and 52.112.0.0/14).

/Kenneth ML

[#5]

Hi Ken,

I can say, everyone is prone to make a mistake, i'm sure that Microsoft has done the same in not posting that 13.100.4.192 belongs to them.

Looking at whois, you will see that it does belong to them and seeing that it is STUN traffic,  its most likely a\v edge services or Microsoft Teams A\V channel...

[#6]

Yes I made a mistake, verify again the xml file was updated the 29th of march https://support.content.office.net/en-us/static/O365IPAddresses.xml ans still doesn't have this IP so we must open a support ticket

[#7]

We noticed the same phenomenon. We had a lot of users reporting issues when having Skype for Business calls with external participants or when having a call with multiple participants. Both scenario's connect to SfB online. 

Internal point to point call did not show any issues.

This pointed us in the direction of the firewall in place between our network and the Microsoft (SfB) cloud environment.

After extensively going through the firewall logs and cross linking with the call quality dashboard now available on the Teams & Skype for Business admin portal we noticed a lot of drops by the firewall.

When investigating these drops we noticed a lot of inconsistencies with the documentation provided by Microsoft.

• High ports range 50000-59999 should actually be 49152-65535
• Connections towards 13.100.x.x ranges (UDP3478-3481) -> After WhoIs lookup the subnet is actually 13.96.0.0/13

This inconsistencies caused a lot of performance issues and users complaining about calls being dropped, content sharing issues, etc...

[#8]

The 13.100 series are only the Host IPs. Not necessarily it needs to be route-able publicly.  It would by default try connecting direct and fail. We need to worry only about Relay IP which is 52.112 on most cases. 

a=candidate:1 1 tcp-pass 2120613887 13.100.10.217 61560 typ host
a=candidate:2 1 tcp-act 2121006591 13.100.10.217 62483 typ host
a=candidate:3 1 tcp-pass 174455807 52.112.0.193 59614 typ relay raddr 13.100.10.217 rport 61049
a=candidate:4 1 tcp-act 174848511 52.112.0.193 59614 typ relay raddr 13.100.10.217 rport 61049

[#9]

@Kenneth Meyer-Lassendid you ever get to the bottom of the 13.100.x.x phenomenon ?  This is still not listed and I am seeing this in logs too and firewall dropping packets.

[#10]

@umeshradia  I have unfortunately never gotten to the bottom of this issue.

I am right now working with a financial customer, who has a more restrictive firewall policy than most companies. I will investigate if this is still occurring.

[#11]

@Kenneth Meyer-Lassen 

do you guys fixed this by today?

We see this ip address too 

13.100.33.107