Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - AndrewButterworth

Pages: [1] 2
1
Looks like this is now working.  Not sure who did what?

2
I have a FTTP connection with PPPoE (IPv4) and negotiate an MRU of 1500 as it uses mini-Jumbo frames (the routers parent Ethernet interface has a MTU of 1508).  The IPv6 Tunnel has a MTU of 1480 and I have reduced the IPv6 MTU to 1440 on the VLAN SVI interface where the Ubuntu Squid servers are (this obviously gets announced in RA's so the hosts know the IPv6 MTU).
I have just been playing around with MTUPATH.exe to try and work out the maximum IPv6 MTU along the path.  I can set the VLAN SVI to 1480 and this works so I guess the Ubuntu hosts are getting the ICMP packet-to-big's locally and this is working around the issue for me. Somewhere along the path the ICMP packet-to-big's are either not being sent or blocked.

3
Found a post on the MS technet forums regarding this as well:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/16e7aa06-9b90-48f8-8370-76c2329b93a8/windows-update-ipv6?forum=ws2016

Looks like it is a MS (or their CDN provider) issue.

4
OK.  So I have a couple of Squid proxy servers that my Windows hosts use via autodiscovery.  These sit on a VLAN where I have lowered the IPv6 MTU to 1280 and Windows Update now works for the Server 2012 R2, 2016 and Windows 10 hosts.

I tried the curl command kriteknetworks posted on a Windows host on a 'normal' VLAN with a 1500 byte MTU and this starts OK but times out:
Code: [Select]
C:\Windows\system32>curl -v -6 https://sls.update.microsoft.com
* Rebuilt URL to: https://sls.update.microsoft.com/
*   Trying 2a01:111:f307:1790::f001:7a5...
* TCP_NODELAY set
* Connected to sls.update.microsoft.com (2a01:111:f307:1790::f001:7a5) port 443
(#0)
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 1/3)

* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 197 bytes...
* schannel: sent initial handshake data: sent 197 bytes
* schannel: SSL/TLS connection with sls.update.microsoft.com port 443 (step 2/3)

* schannel: failed to receive handshake, need more data
* Operation timed out after 300115 milliseconds with 0 out of 0 bytes received
* Closing connection 0
* schannel: shutting down SSL/TLS connection with sls.update.microsoft.com port
443
* schannel: clear security context handle
curl: (28) Operation timed out after 300115 milliseconds with 0 out of 0 bytes r
eceived

On the ubuntu squid host with the lower IPv6 MTU it fails but doesn't timeout (it had the same behaviour as the Windows host before I lowered the MTU)
Code: [Select]
administrator@ubuntu-squid-1:~$ curl -v -6 https://sls.update.microsoft.com
* Rebuilt URL to: https://sls.update.microsoft.com/
*   Trying 2a01:111:f307:1790::f001:7a5...
* Connected to sls.update.microsoft.com (2a01:111:f307:1790::f001:7a5) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 596 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_256_GCM_SHA384
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
administrator@ubuntu-squid-1:~$

It therefore looks like somewhere in the path to the microsoft IPv6 hosts (sls.update.microsoft.com.nsatc.net) there is an MTU issue - a router blocking ICMP packet too big maybe?
I am not quite sure how we get this looked into further as it obviously something outside of my control or influence?

Andy

5
It seems the Windows 2012 R2, Windows 2016 and Windows 10 machines connect to sls.update.microsoft.com (alias to sls.update.microsoft.com.nsatc.net) and Windows 7 connect to fe2.update.microsoft.com (alias to fe2.update.microsoft.com.nsatc.net).  Windows 7 (and server 2008 R2) clients work OK, the others don't.  I can see connections being made and the remote servers responding so I don't think its a routing issue.  It could be a MTU issue along the path (had this before with cisco.com) so I might try lowering the MTU on a client.
There is a mix of OEM & KMS licensed machines - however I don't think this is relevant if it works over IPv4?
Could it be geolocation stuff as my IPv4 address space is UK and my IPv6 is French?

Anyone else seeing this behaviour?

Andy

6
For a few days (I think?) Windows Server 2012 R2, Windows Server 2016 and Windows 10 machines are failing to connect to Windows Update over IPv6.  I get a couple of different errors but looking at the logs it appears it is timing out on connecting to the Windows Update services over IPv6.
If I disable IPv6 and force them to use IPv4 Windows Update works fine.  There are a bunch of DNS AAAA records and Aliases that get resolved so I am not sure which hosts they are failing to connect to.  Connections to other IPv6 sites seem to work fine (google, cisco).
My IPv6 tunnel terminates on the Paris server so was wondering if this is anything related to the hardware failure the other week and the temporary terminating of the Paris tunnels in London?

Andy

7
Questions & Answers / Re: Paris server down?
« on: October 31, 2017, 11:23:16 AM »
The status page has been updated and it now says the Paris node has a 'Hardware issue. Tunnels have been temporarily re-homed to London'.

Does this require me to make any temporary changes on my side or is the IPv4 prefix for the Paris tunnel endpoint being re-routed to London?

Andy

Edit:  Looks like the Paris IPv4 prefix is being re-routed to a node in London so there are no changed to be made on my side.

8
Questions & Answers / Re: Paris server down?
« on: October 31, 2017, 09:06:47 AM »
There was a 'blip' a few minutes ago where one of the London nodes, one of the New York nodes and the African node went 'down'.  They have all now returned but the Paris one is still down...

9
Questions & Answers / Paris server down?
« on: October 31, 2017, 03:51:41 AM »
Any ideas when the Paris server will be back up?  31-10-2017?

10
Questions & Answers / Re: Tunnelbroker.net API Documentation
« on: September 20, 2015, 02:06:46 AM »
Bug in the script.  Should be better.

OK, I have changed the EEM TCL script back to the original (http://ipv4.tunnelbroker.net/ipv4_end.php?ip=IPADDRESS&pass=MD5PASS&user_id=USERID&tid=TUNNELID) and I am now getting '-ERROR: Invalid API key or password'?

EDIT:  Sorry, my bad I changed the password as it had '$' in it that the EEM script was interpreting...    Just re-MD5 hashed the new password and its working again now using the original HTTP method.

Thanks, Andy

11
Questions & Answers / Re: Tunnelbroker.net API Documentation
« on: September 19, 2015, 05:03:58 PM »
I have been using the HTTP method to update my tunnel endpoint IPv4 address for a while now (http://ipv4.tunnelbroker.net/ipv4_end.php?ip=IPADDRESS&pass=MD5PASS&user_id=USERID&tid=TUNNELID) along with the 'ip=AUTO' variable.  This has now stopped working and I get an error of 'INVALID IPV4 ADDRESS' - I assume because the HTTP method has now been depreciated in favour of the HTTPS method.
If I use the preferred HTTPS method via a browser (https://ipv4.tunnelbroker.net/nic/update?username=USERNAME&password=PASSWORD&hostname=TUNNELID), this works fine, however I am automating this on a Cisco IOS router with a TCL script (ipv6-tunnel-update.tcl) triggered by the interface going up.  I have modified the script to use the new API parameters but it appears the TCL script doesn't support HTTPS so it doesn't work.
Has anyone else hit this issue and has a workaround?

Thanks, Andy

12
IPv6 on Routing Platforms / IPv6 access to cisco.com issues?
« on: October 02, 2014, 04:16:50 AM »
I have an interesting issue at home with my IPv6 access.  I have had a tunnel to HE for over 2-years now; all working fine.  I had some initial MTU issues that I have sorted out but on the whole its been working well.  When I originally signed up the tunnel server in London was full (I am in the UK) so I opted for the geographically nearest which was France.  I have a routed /64 & a /48 and I have 'subnetted' the /48 down into various /64's that I have over various VLANs at home and I as say it all seems to work perfectly.  I am using a Cisco 887VA router on a BT Infinity VDSL2 circuit which trains at about 50Mbps down and 5Mbps up.  The only issue I have had is google.com and youtube.com redirecting me to the google.fr and youtube.fr due to my source IPv6 address.
Nothing has changed on my side for ages but about two or three weeks ago access to cisco.com began to be a bit erratic - pages would half load and stop, clicking on links would time out etc.  By default (using Windows GPO) I use a dual-stack IPv4/IPv6 Squid proxy server to access Web sites, however I also have an IPv4-only proxy so forcing my client to use this solves the issue by forcing an IPv4 connection to cisco.com instead of the default IPv6 connection - I manually change the proxy in the Browser to the IPv4-only proxy but GPO refreshes at regular intervals so this reverts every 90-minutes (default GPO refresh).  Connecting to other sites over IPv6 is fine - google.com, youtube.com, facebook.com, linkedin.com etc plus anything I search for with 'ipv6 only sites'.
I access cisco.com a lot as I use it daily in my job so this is beginning to get a pain.  What's odd is it seems to be worse in the morning and then recover in the afternoon without any intervention.

Any ideas?

Andy

13
I'd be interested to see your ZBFW configuration as I have been struggling with this for a while and I keep coming back to it.  I have 'legacy' IPv4 firewalling configured (IP inspect) with the holes poked through to allow the HE tunnel to work - IP protocol 41 to/from 216.66.84.42 and ICMP to/from 66.220.2.74.  I also have legacy IPv6 firewalling configured on my tunnel interface to HE.  All this seems to work OK.  I have made a couple of attempts to get ZBFW working and each time I end up reverting back.
I can get outbound & inbound IPv4 services working (although I had issues with SIP?), as well as traffic to the 'self' zone from the Inside and some sucess from the Outside to Self (I have RA IPSec VPN so allow ESP, AH, ISAKMP (UDP/500 + UDP/4500 for NAT-T), and UDP 1701 for L2TP, I also have inbound SMTP and these all worked).  However I had problems with getting the HE tunnel to work - it seemed to be intermittent so wasn't sure whether it was the ZBFW configuration between Self and Outside or between Inside and the Tunnel?

Andy

14
Questions & Answers / Re: /48 Zone remains as Incomplete?
« on: March 27, 2012, 09:20:08 AM »
Registering a domain costs money.

It does.  Now I have one and onto the next certification tests....   :)

Andy

15
Questions & Answers / Re: /48 Zone remains as Incomplete?
« on: March 26, 2012, 08:30:43 AM »
Bizarrely I have been a CCIE for 10-years and I have never registered a domain...

I thought this was part of the Free DNS service HE offered?

Pages: [1] 2