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.
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.
Quote from: cholzhauer on June 03, 2013, 12:06:26 PM
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
Interesting; I'm getting the same DNS info you are, but the little red 4 still shows in my browser window.
Quote from: cholzhauer on June 03, 2013, 12:30:51 PM
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.
Quote from: Dragon2611 on June 03, 2013, 12:01:44 PMAlthough 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.
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.
same here, still no solution
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
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?
Quote from: PaulosV on June 26, 2013, 01:35:01 PMPath 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.