Tracing route to edge-star6-shv-12-frc3.facebook.com [2a03:2880:2130:cf05:face:b00c:0:1] over a maximum of 30 hops:
1 1 ms <1 ms <1 ms pfsense.home [2406:e000:e1e8:0:20c:29ff:fec0:f7a7] 2 9 ms 11 ms 11 ms 2406:e000:97:1::1 3 * * * Request timed out. 4 29 ms 29 ms 33 ms 23655.syd.equinix.com [2001:de8:6::2:3655:1] 5 29 ms 29 ms 29 ms 32934.syd.equinix.com [2001:de8:6::3:2934:1] 6 228 ms 228 ms 228 ms be23.bb01.lax1.tfbnw.net [2620:0:1cff:dead:beef::304] 7 204 ms 204 ms 204 ms ae27.bb02.atl1.tfbnw.net [2620:0:1cff:dead:beef::c68] 8 210 ms 211 ms 210 ms ae5.bb05.frc3.tfbnw.net [2620:0:1cff:dead:beef::f9] 9 247 ms 303 ms 234 ms be35.bb02.frc3.tfbnw.net [2620:0:1cff:dead:beef::ac] 10 210 ms 210 ms 210 ms ae29.dr06.frc3.tfbnw.net [2620:0:1cff:dead:beef::a2b] 11 237 ms 237 ms 237 ms po1020.csw12c.frc3.tfbnw.net [2620:0:1cff:dead:beef::25f] 12 * * * Request timed out. 13 227 ms 227 ms 227 ms edge-star6-shv-12-frc3.facebook.com [2a03:2880:2130:cf05:face:b00c:0:1]
Trace complete.
I will run wireshark and see if i can pick up on anything.
EDIT: I have captured the relevant packets of trying to load the facebook webpage but from here I am not sure what I am looking for - can you point me in the right direction?
The traceroute looks fine - just like mine, which it should as we are both on Snap.
When I go to [2a03:2880:2130:cf05:face:b00c:0:1] in Firefox with Wireshark watching, I see a TCP connection to that address start with a SYN/ACK sequence, then an HTTP Get command is transmitted over the TCP connection and the Facebook site replies with 301 "Moved permanently" response, directing Firefox to fetch another page: "http://www.facebook.com/". Firefox then goes and fetches the new page, on a different IPv6 address: [2a03:2880:2130:7f07:face:b00c:0:1] - it opens a new TCP connection to that address with the usual SYN/ACK sequence, and then starts talking on the TCP connection in TLSv1.2 encrypted traffic as it loads the Facebook front page.
Because of the transfer to a new server address, I had to change the capture filter I was using in Wireshark to include the new address in order to see everything:
ip6 and (icmp6 or host 2a03:2880:2130:cf05:face:b00c:0:1 or host 2a03:2880:2130:7f07:face:b00c:0:1)
But that probably does not matter - if your capture is showing that first IPv6 TCP/HTTP connection to 2a03:2880:2130:cf05:face:b00c:0:1, then IPv6 is working properly, so we need to confirm that first. I have posted a copy of my capture on my web server as:
You can save your Wireshark capture and load mine to see what it looks like to compare with yours. If you have not changed the Wireshark defaults, the first IPv6 TCP/HTTP conversation with 2a03:2880:2130:cf05:face:b00c:0:1 is coloured in light green.
Your capture does not show the HTTP redirection that I get from the initial web server (2a03:2880:2130:cf05:face:b00c:0:1) to the second web server (2a03:2880:2130:7f07:face:b00c:0:1). Instead, your Firefox seems to be talking to both servers at once, using TLS1.2 encrypted HTTPS. The conversation with the initial web server is fairly short, but seems to be complete. The conversation with the second web server looks much like what I got with that server - longer, transferring enough data to be able to display the Facebook front page. So Firefox should have been able to display a page for you. Did you get anything at all displayed? Or was it still twirling its little "I am still downloading" widget on the tab for the page?
I am guessing that you might have been using a bookmark to go to Facebook, and that bookmark used https instead of http and that was what caused the difference between our captures. Is that correct? If so, please try going to http://www.facebook.com and see what happens.
In any case, IPv6 seems to be functioning completely correctly - it is able to do TCP connections to the site. The problem seems to be elsewhere.
PS If you want to follow one TCP conversation in Wireshark, click on a TCP SYN packet that starts a TCP connection, then use Analyze > Follow TCP stream. Close the popup window and then you will just have the data for that one conversation displayed. In the Filter toolbar, click Clear when you want to go back to the full display again.
Firefox is displaying the page title and nothing else, page load never completes, only get the twirling "loading" icon.
Chrome give me the Page title, tells me the page load is complete but page is blank.
Facebok phone app is also not functioning at all.
Any websites with "Like on facebook" etc and some google ads are also failing to display.
I dont think I know enough about inspecting wireshark data to troubleshoot this further. . To add - I was not using a bookmark, manually typing the webpage in and browsing to it each time. Fresh Win7 and Win10 VM is exhibiting the same issue
The symptoms you describe sound very similar to the ones I've had in the past where my router was telling clients the IPv6 MTU was 1500 when it was in fact 1492. When the MTU was set correctly v6 traffic worked without issue.
Looking at your pcap the MTU in the router advertisements is 1500. Try setting the IPv6 MTU on your box to 1492 and see if you can get Facebook to load.
netsh interface ipv6 show subinterfaces netsh interface ipv6 set subinterface "name of adapter" mtu=1492
Spoke too soon. Appears to have fixed the desktop facebook website (only one a single PC it seems) this does not make sence... but same symtoms are being exhibited on mobile devices with the m.facebook.com page. m.facebook.com also fails to load under firefox, chrome and IE on desktop.
Also noticing alot of webpages failing to load completely, geekzone, youtube I have noticed to far. geekzone is stuck on "transferring data from pixel.quantserve.com" and "Waitting for google.com" and "transferring data from pagead2.googlesyndication.com" so looks like some ads are failing to load contributing to page load errors.. grr. Im starting to think I should switch IPv6 off again.
This android phones? I've disabled IPV6 as it seems its broken on Nexus 5 running Android 5.x. Will probably take google a couple of years to acknowledge then another year or so to fix.
Okay I have done a bit of reading on this to try and further my knowledge in this area.
From what I gathered, packets over 1492 (pfsense was autosensing the adapter capabilites and setting this to 1500) in size get fragmented and this is not being handled correctly either by pfsense or the remote server (facebook, google etc). Setting MSS Clamping does not allow the packets to be larger than this value and as such plays nicely with the remote server?
Is there an explanation on why this is only affecting me?
bonkas: Okay I have done a bit of reading on this to try and further my knowledge in this area.
From what I gathered, packets over 1492 (pfsense was autosensing the adapter capabilites and setting this to 1500) in size get fragmented and this is not being handled correctly either by pfsense or the remote server (facebook, google etc). Setting MSS Clamping does not allow the packets to be larger than this value and as such plays nicely with the remote server?
Is there an explanation on why this is only affecting me?
in theory you shouldn't need to configure MSS clamping if PMTUD is working correctly.
in practice PMTUD doesn't work due to over protective filters/firewalls so we need to set MSS.
most 'home' routers (like the Fritzbox) automatically clamp MSS so you'll find you're not alone.
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
