office365

[Dragon2611]

I seem to be having trouble reaching outlook-emeacenter.office365.com from tunserv5.lon1

Although rather unhelpfully it looks like Microsoft are blocking IMCP traffic making it hard to tell exactly where the problem is.

I can't ping any of their IPv4 or IPv6 addresses however if I disable IPv6 on my PC then outlook is then able to connect to o365 over IPv4

I can reach OWA regardless of the state of my IPv6 connection so I suspect it's a problem specifically with the Proxies outlook connects to for it's RPC over HTTPS outlook just hangs in the "connecting" state indefinitely.

[cholzhauer]

You're not able to browse to the site at all?  It loads fine for me on the Chicago server, but according to Google, it's an IPv4 only site.

[Dragon2611]

You're not able to browse to the site at all?  It loads fine for me on the Chicago server, but according to Google, it's an IPv4 only site.

nslookup outlook-emeacenter.office365.com
Server:  UnKnown
Address:  192.168.6.1

Non-authoritative answer:
Name:    outlook-emeacenter.office365.com
Addresses:  2a01:111:f400:9800::12
          2a01:111:f400:8014::2
          2a01:111:f400:8000::6
          2a01:111:f400:1000::12
          2a01:111:f400:9814::2
          157.56.255.60
          157.56.253.246
          132.245.193.130
          157.56.251.214
          157.56.251.60
          132.245.210.2

I'll have to try and find out which of the addresses outlook is trying to connect to when it next hangs.

Weirdly browsing to the v6 addresses redirects me to the login page, so it looks like the routing is ok only thing I can think of is either an MTU related issue or one of the servers in that cluster isn't working properly with outlook

[cholzhauer]

Interesting; I'm getting the same DNS info you are, but the little red 4 still shows in my browser window. 

[Dragon2611]

Interesting; I'm getting the same DNS info you are, but the little red 4 still shows in my browser window. 

If you try and browse to those IP's it bounces you off to login.live.com even if you use HTTPS

outlook claims to be connected via proxy outlook.office365.com which when I do a DNS lookup for i get

nslookup outlook.office365.com
Server:  UnKnown
Address:  192.168.6.1

Non-authoritative answer:
Name:    outlook-emeacenter.office365.com
Addresses:  2a01:111:f400:1000::12
          2a01:111:f400:8000::6
          2a01:111:f400:8014::2
          2a01:111:f400:9800::12
          2a01:111:f400:9814::2
          157.56.251.60
          132.245.210.2
          157.56.255.60
          157.56.253.246
          132.245.193.130
          157.56.251.214
Aliases:  outlook.office365.com
          outlook.office365.com.glbdns.microsoft.com

I presume they can tell the difference between the Outlook client connecting and a browser connecting, but as it's encrypted it's hard to know what it's doing.

[kasperd]

Although rather unhelpfully it looks like Microsoft are blocking IMCP traffic making it hard to tell exactly where the problem is.

That's going to cause problems for any Teredo client trying to connect to the service. Considering who designed the Teredo protocol, you'd think Microsoft would know better than to deploy servers not responding to echo requests.

[PaulosV]

A related issue - I'm unable to open any of the Office Web Apps from Skydrive with my IPv6 tunneled connection.

The same symptoms - AAAA address with no ICMP ping reply. Using IPv4 everything works (well, except ICMP)

This time another address - word-view.officeapps.live.com (aka word-view.officeapps.live.com.akadns.net).

nslookup word-view.officeapps.live.com
Server:  private.rionet.cz
Address:  192.168.1.1

Non-authoritative answer:
Name:    word-view.officeapps.live.com.akadns.net
Addresses:  2a01:111:f406::151
         94.245.119.151
Aliases:  word-view.officeapps.live.com

HTTP(S) IPv6 connection to that address bounces you off to Office Web Apps introductory page...

I've already delivered them my question about the notworking IPv6 Office access, you can view it here: https://answers.microsoft.com/en-us/windowslive/forum/skydrive-files/skydrive-office-web-apps-inaccessible/b7bcd27f-3285-4b00-8e9c-be5784288ec1

Still not fixed since then.

[fastbone]

same here, still no solution

[Dragon2611]

http://answers.microsoft.com/en-us/windowslive/forum/skydrive-files/skydrive-office-web-apps-inaccessible/b7bcd27f-3285-4b00-8e9c-be5784288ec1

Now they're trying to blame my wireless router... given the wireless "routers" in my network are actually running as a Dumb L2 bridge between their switch and wi-fi chips I very much doubt they're calling it.

Then they asked are there any routers...  Damn and here's me thinking it was the internet pixies responsible for getting my traffic to their servers

[PaulosV]

OT: Recently I've been in contact with Seznam.cz (the largest Czech website) about a IPv6 connection issue. Turned out to be an issue with their firewall, they were blocking path MTU discovery on one of their servers. I'm thinking if this couldn't be the cause here as well, it looks remarkably similar. Path MTU discovery uses ICMP if I'm not mistaken, is that right?

[kasperd]

Path MTU discovery uses ICMP if I'm not mistaken, is that right?

That is true. And it is practically no different from IPv4. With IPv4 a packet that is too large for a link generates an ICMP error message containing the MTU of that link. With IPv6 an ICMPv6 error message is generated instead, also containing an MTU of that link. The error codes are different between ICMP and ICMPv6. That is because the codes were reordered such that you can always look at the first bit of the code to know if it is an error message or a different kind of ICMPv6 packet. Functionally they behave the same.

On IPv4 the sender could choose to indicate in the header, that the packet can be fragmented in transit, instead of sending an error message back to the sender. However fragmentation while packets are in transit is inefficient due to a number of reasons and that option was eliminated in IPv6. I am not sure if there are still TCP stacks around, which lets IPv4 fragment the packets. Permitting that would avoid MTU problems due to dropped ICMP packets. But using IP fragmentation is less efficient than letting TCP segment data into packets, that don't need to be fragmented.

Dropping the packets indicating that the MTU has been exceeded causes problems on both IPv4 and IPv6, and firewalls should not be configured to do so on either of the protocols.