Question

IPv6 connectivity issues with nginx

Posted January 17, 2017 37.9k views
Nginx IPv6 Ubuntu 16.04

Hi,
I recently turned on IPv6 addresses on one of our droplets hosted in Bangalore. I added a new AAAA entry for this IPv6 address, in addition to the A entry. I now have 2 entries (addresses are obscured here):
A Record: @ 139.59.XX.YY 600 seconds
AAAA record: @ 2400:6180:100:WW::XXX:YYYY 1 Hour

While I am able to load the website on my browser using https (or http which gets redirected to https), I get a webserver unreachable when I test IPv6 connectivity using http://ipv6-test.com/validate.php

Here are some commands I ran on the server to debug the issue, but I couldn’t find anything wrong:

sudo netstat -tulpan | grep nginx
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2705/nginx -g daemo
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2705/nginx -g daemo
tcp6 0 0 :::443 :::* LISTEN 2705/nginx -g daemo
tcp6 0 0 :::80 :::* LISTEN 2705/nginx -g daemo

ufw status
Status: inactive

sudo sysctl -a | grep bindv6only (I explicitly set this to 1 )
net.ipv6.bindv6only = 1
sysctl: reading key “net.ipv6.conf.all.stablesecret”
sysctl: reading key “net.ipv6.conf.default.stablesecret”
sysctl: reading key “net.ipv6.conf.eth0.stablesecret”
sysctl: reading key “net.ipv6.conf.eth1.stablesecret”
sysctl: reading key “net.ipv6.conf.lo.stablesecret”
sysctl: reading key “net.ipv6.conf.lxdbr0.stablesecret”

This is my nginx config (/etc/nginx/sites-enabled/default)

server {
listen 80;
listen [::]:80 ipv6only=on;
server_name example.com www.example.com;
rewrite ^(.*) https://example.com$1 permanent;
}

server {
listen 443 ssl;
listen [::]:443 ipv6only=on;
server_name example.com;

sslcertificate example.com.pem;
sslcertificate_key example.com.key;

:
:
:
}

Am I missing something here?

Best,
Roshan

Add a comment
roshanbaliga
By:
roshanbaliga
Add a comment

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

5 answers
jtittle1 January 17, 2017

@roshanbaliga

When it comes to NGINX, enabling IPv6 should only require that you’re server block contain the lines shown below (I’ve intentionally cut the rest of the sever block out since the important thing is getting IPv6 working for you – the other lines don’t really matter).

server
{
    listen                          80 default_server;
    listen                          [::]:80 ipv6only=on;
}

or

server
{
    listen                          443 default_server;
    listen                          [::]:443 ipv6only=on;
}

The default_server setting isn’t required and simply tells NGINX that if a request for a domain is received and can not be routed, that it should be routed to this server block, i.e. the default server.

If this is a recently deployed Droplet, that should be the only configuration that you need. You should not have to modify any other configuration settings.

To test this, I just compiled NGINX on a dev droplet that I have setup and configured one of my test domains to point to the IPv4 and IPv6 addresses and ran the same test you linked to and it worked instantly.

DNS

In terms of DNS, one thing that would prevent this from working is how you’ve setup DNS. Let’s use the following as examples (as that’s what you included in your OP).

IPv4 IP: 139.59.0.0
IPv6 IP: 2400:6180:100:WW::XXX:YYYY

Now let’s say your Droplet hostname is:

web.domain.com

and your domain is:

domain.com

And you want IPv4 + IPv6 to work on both, of course.

So you should have 2 A entries and 2 AAAA entries – i.e. one of each for both of the above.

For domain.com

A        domain.com        139.59.0.0
AAAA     domain.com        2400:6180:100:WW::XXX:YYYY

and for web.domain.com:

A        web.domain.com    139.59.0.0
AAAA     web.domain.com    2400:6180:100:WW::XXX:YYYY

After making any changes to NGINX, you should either restart or reload.

sudo service nginx restart

or

sudo service nginx reload
Reply Report
jtittle1 January 18, 2017

@roshanbaliga

The only other issue that I can think of would be that NGINX may not be compiled with IPv6 support. Whether or not this is the case depends on the version of NGINX you’re running. The latest versions don’t require the compile option --with-ipv6, however, prior to the newer releases, older version of NGINX did.

You can check the compile options by running the following command from the CLI:

nginx -V

Which will detail every option that NGINX was compiled with for your build. If your version is 1.10.x or 1.11.x, you don’t need that compile option as it’s deprecated. If you’re build is older and it doesn’t show up when running the above, then your build of NGINX may not support IPv6 connections and that’d be why you’re unable to verify it.

The downside is that if you are running an older version and there’s not a newer version in the repo, then the best option is doing a source compile where you’ll have to define each option that NGINX should be compile with.

If that’s the route needed, I can help you there. I actually have a copy & paste solution to help with that, but before doing something like that, you’d need to backup any data in /etc/nginx that you don’t want destroyed (i.e. server block files for your website(s)) as we’d be deleting everything there and starting from scratch.

Reply Report
  • roshanbaliga January 18, 2017

    Here are details of my nginx version. The configure arguments contains –with-ipv6 option. Looks like this should have worked for me.

    nginx version: nginx/1.10.0 (Ubuntu)
    built with OpenSSL 1.0.2g 1 Mar 2016
    TLS SNI support enabled
    configure arguments: –with-cc-opt=’-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -DFORTIFYSOURCE=2’ –with-ld-opt=’-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now’ –prefix=/usr/share/nginx –conf-path=/etc/nginx/nginx.conf –http-log-path=/var/log/nginx/access.log –error-log-path=/var/log/nginx/error.log –lock-path=/var/lock/nginx.lock –pid-path=/run/nginx.pid –http-client-body-temp-path=/var/lib/nginx/body –http-fastcgi-temp-path=/var/lib/nginx/fastcgi –http-proxy-temp-path=/var/lib/nginx/proxy –http-scgi-temp-path=/var/lib/nginx/scgi –http-uwsgi-temp-path=/var/lib/nginx/uwsgi –with-debug –with-pcre-jit –with-ipv6 –with-httpsslmodule –with-httpstubstatusmodule –with-httprealipmodule –with-httpauthrequestmodule –with-httpadditionmodule –with-httpdavmodule –with-httpgeoipmodule –with-httpgunzipmodule –with-httpgzipstaticmodule –with-httpimagefiltermodule –with-httpv2module –with-httpsubmodule –with-httpxsltmodule –with-stream –with-streamsslmodule –with-mail –with-mailsslmodule –with-threads

    Reply Report
    • jtittle1 January 18, 2017

      @roshanbaliga

      Indeed it should have. I’d definitely get in touch with the support team by submitting a ticket to see if there is potentially an issue elsewhere as you shouldn’t need to configure anything else on a newer droplet. If this was a droplet that was deployed before IPv6 was a globally available option, you’d definitely need to configure a few things beyond NGINX, but on new droplets, this shouldn’t be required.

      Reply Report
      • roshanbaliga January 18, 2017

        @jtittle
        Thanks a lot for helping out with this. This was driving me nuts, as it should have been relatively straight forward. Double checked everything from nginx configurations, AAAA records, Firewall ....
        This droplet was created on Jan 02, 2017. But I enabled IPv6 on it a couple of days back

        Reply Report
      • roshanbaliga January 18, 2017

        I just raised a support ticket for this. Thanks again

        Reply Report
        • jtittle1 January 18, 2017

          @roshanbaliga

          No problem! If you don’t mind, please do keep me updated as I wouldn’t mind knowing what the real issue is. I’m a bit mystified.

          Reply Report
          • roshanbaliga January 18, 2017

            Finally debugged the issue with the help of Digital Ocean Support. It turns out that for droplets on which IPv6 was enabled after the droplet creation, there are additional steps that need to be manually run. Merely turning on IPv6 on a droplet using the dashboard is not sufficient. The public IPv6 address & gateway have to be manually configured!
            Enabling IPv6 on an existing droplet

            An inspection of the network interfaces using ip -6 addr show eth0 should have pointed out the problem. The problem is now resolved. Once the http://domain.com & http://www.domain.com were verified, I had to make a minor change highlighted below for https://domain.com. 

            server {
  listen 80;
  listen [::]:80 ipv6only=on;
  server_name example.com www.example.com;
  rewrite ^(.*) https://example.com$1 permanent;
}

server {
   listen 443 ssl;
   listen [::]:443 ipv6only=on ssl;
   server_name example.com;

   sslcertificate example.com.pem;
   sslcertificate_key example.com.key;

     :
     : 
     :
}
            Reply Report
          • moduscode February 7, 2017

            One quirk of nginx site selectors is that if you use the default ipv6only setting in the standard hybrid configuration, the order of the listen arguments matters. So, it should look like:

               listen     [::]:80;
   listen     80;

            Alternatively, you could use the ipv6only=on modifier and drop the IPV6 listen to second in the list.

            It’s been a number of years since I configured my last nginx server, so I’m still going through the mental exercise of why the order matters, but when I logic through it, I’ll reply to this.

            Reply Report
jtittle1 January 18, 2017

@roshanbaliga

Thanks for the update, definitely appreciated!

I was about to suggest that same link, though I was under the impression that the Droplet was setup and deployed with IPv6 enabled from the start. Next time I’ll make sure I lead with that so I can save the next person time and hassle!

That said, I am happy to hear that they were able to help and that you were able to get things up and running as needed!

Reply Report
czearart April 1, 2017

First off great job @jtittle, I really appreciate your consistency and care at handling this issue for @roshanbaliga .
I am currently facing the same issue. So I’ve gone through the tutorial on https://www.digitalocean.com/community/tutorials/how-to-enable-ipv6-for-digitalocean-droplets#enabling-ipv6-on-an-existing-droplet
But I’m stuck here where I have to sudo nano /etc/network/interfacesand add a section for my ipv6 address. Instead I get this file: 

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# Source interfaces
# Please check /etc/network/interfaces.d before changing this file
# as interfaces may have been defined in /etc/network/interfaces.d
# See LP: #1262951
source /etc/network/interfaces.d/*.cfg

I have gone through installing nginx and letsencrypt.

here is my nginx server settings:

server {
    listen 80 ;
    listen [::]:80 ;
    listen 443 ssl http2 ;
    listen [::]:443 ssl http2 ;

    root /var/www/example.com/html;
    server_name example.com www.example.com;
    include snippets/ssl-example.com.conf;
    include snippets/ssl-params.conf;

   location ~ /.well-known {
            allow all;
   }
}

Thanks in advance.

Reply Report
  • jtittle1 April 1, 2017

    @czearart - Which part are you stuck on?

    The networking information required in the guide can be gathered from the DigitalOcean CP. Once you login, click on the Droplet, then from the left sidebar, click on Networking.

    Under the heading Public IPv6 network, you’ll find the IPv6 IP, IPv6 Gateway, and the range.

    You’ll need to modify the values highlighted in red with the information from that page, then add the configuration below:

    iface lo inet loopback

    For NGINX, it’s best to use multiple server blocks, one for each port. For example, if we wanted to redirect all requests on port 80 to 443 (HTTP => HTTPS), then we’d setup something like:

    server {
    listen 80;
    listen [::]:80;
    server_name domain.com www.domain.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name domain.com www.domain.com;

    root /path/to/webroot;

    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";

    resolver 208.67.222.222 208.67.220.220 valid=300s;
    resolver_timeout 5s;

    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    ssl_ecdh_curve secp384r1;
    ssl_prefer_server_ciphers on;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_session_cache shared:SSL:50m;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_session_tickets off;
    ssl_session_timeout 5m;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;

    location /
    {
        try_files $uri $uri/ =404;
    }
}

    In the above, I’m setting ssl_dhparam. This is something you’ll need to generate from the CLI. It takes a while (anywhere from 5-20 minutes), but it’s something you need for proper SSL setup.

    If you don’t already have one, you can generate one using:

    openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

    You’ll see a series of .... and a few + popping up while the command executes. Once it’s done, it’ll drop you back to the command prompt. You can then configure the above server block to match your own domain (replacing domain.com with your domain name) and then restart NGINX.

    The above SSL configuration is also a bit more complete than most configurations, especially most guides. It’s the configuration I use though and what I recommend to others.

    Reply Report
czearart April 1, 2017

Thank you very much @jtittle, with your instructions. Which I judiciously followed I was able to resolve this issue.
I wish I could give you more than 1 like on this Q&A thread. :D.
I knew I made the right decision choosing DO!!

Reply Report
Submit an Answer

Related

Looking for something else?

Ask a new question Search for more help