Jump to content

  • [6.12.5] Unraid services not listening on IPv6 addresses

    mine

    By mine

      • Annoyance

    Since the upgrade from 6.12.3 to 6.12.5, the following services do not listen on the configured (public) IPv6 address:

    • SSH
    • SMB
    • http (Unraid web interface)

    I made the following observations:

    • ping to the Unraid configured IPv6 is working
    • The services mentioned above are not answering to connection requests via the IPv6. IPv4 working fine
    • The file /etc/samba/smb-names.conf contains the following entry:
      interfaces = 192.168.2.2/24 0 127.0.0.1 ::1
      --> IPv6 is missing
    • Adding the following entry to the "Samba extra configuration:" enables IPv6 connections to Samba:
      • interfaces = 192.168.2.2/24 0 127.0.0.1 ::1 2a01:124f:acdf:31b1::100/64
    • At "Settings --> Management Access" I see the following:
      • Local access URLs:
        • http://[2a01:124f:acdf:31b1:]:0100/ redirects to https://[2a01:124f:acdf:31b1:]:0100/
        • The above is obviously wrong. It should be http://[2a01:124f:acdf:31b1::0100]/

     

    Listing the ports that the server listens on gives the following: 

    root@zentrale:/boot/config# ss -tulpn | grep LISTEN
tcp   LISTEN 0      50                      127.0.0.1:139        0.0.0.0:*    users:(("smbd",pid=18417,fd=35))                          
tcp   LISTEN 0      50                      127.0.0.1:445        0.0.0.0:*    users:(("smbd",pid=18417,fd=34))                          
tcp   LISTEN 0      1                         0.0.0.0:5700       0.0.0.0:*    users:(("qemu-system-x86",pid=20299,fd=42))               
tcp   LISTEN 0      1                         0.0.0.0:5900       0.0.0.0:*    users:(("qemu-system-x86",pid=20299,fd=41))               
tcp   LISTEN 0      5                     0.0.0.0%br0:5355       0.0.0.0:*    users:(("wsdd2",pid=18430,fd=12))                         
tcp   LISTEN 0      5                     0.0.0.0%br0:3702       0.0.0.0:*    users:(("wsdd2",pid=18430,fd=8))                          
tcp   LISTEN 0      5                         0.0.0.0:3551       0.0.0.0:*    users:(("apcupsd",pid=6374,fd=5))                         
tcp   LISTEN 0      128                       0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=28391,fd=3))                           
tcp   LISTEN 0      511                       0.0.0.0:80         0.0.0.0:*    users:(("nginx",pid=12508,fd=8),("nginx",pid=8709,fd=8))  
tcp   LISTEN 0      511                       0.0.0.0:443        0.0.0.0:*    users:(("nginx",pid=12508,fd=9),("nginx",pid=8709,fd=9))  
tcp   LISTEN 0      1000                    127.0.0.1:16509      0.0.0.0:*    users:(("libvirtd",pid=19904,fd=14))                      
tcp   LISTEN 0      50                    192.168.2.2:445        0.0.0.0:*    users:(("smbd",pid=18417,fd=36))                          
tcp   LISTEN 0      50                    192.168.2.2:139        0.0.0.0:*    users:(("smbd",pid=18417,fd=37))                          
tcp   LISTEN 0      32                  192.168.122.1:53         0.0.0.0:*    users:(("dnsmasq",pid=20108,fd=6))                        
tcp   LISTEN 0      5                        [::]%br0:5355          [::]:*    users:(("wsdd2",pid=18430,fd=13))                         
tcp   LISTEN 0      5                        [::]%br0:3702          [::]:*    users:(("wsdd2",pid=18430,fd=9))                          
tcp   LISTEN 0      50                          [::1]:445           [::]:*    users:(("smbd",pid=18417,fd=32))                          
tcp   LISTEN 0      511                         [::1]:443           [::]:*    users:(("nginx",pid=12508,fd=11),("nginx",pid=8709,fd=11))
tcp   LISTEN 0      50                          [::1]:139           [::]:*    users:(("smbd",pid=18417,fd=33))                          
tcp   LISTEN 0      511                         [::1]:80            [::]:*    users:(("nginx",pid=12508,fd=10),("nginx",pid=8709,fd=10))
tcp   LISTEN 0      50     [2a01:124f:acdf:31b1::100]:139           [::]:*    users:(("smbd",pid=18417,fd=31))                          
tcp   LISTEN 0      50     [2a01:124f:acdf:31b1::100]:445           [::]:*    users:(("smbd",pid=18417,fd=30))

     

    You can see in this listing, that no service of Unraid is listening on IPv6 addresses, but Samba, that I manually added to listen at the configured IPv6 address.

    I would appreciate to get this fixed ASAP, as I heavily relay on IPv6 in my network.

    Thanks

     

    Go to reports Stable Releases

    User Feedback

    Recommended Comments

    Leseratte10

    Can confirm, something is broken in 6.12.x.

     

    In 6.11.5, the nginx webserver was simply configured to listen on "0.0.0.0" for IPv4 and "[::]" for IPv6 which made it listen on all IPs: 

      

        listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    Since the 6.12.0 update, it's listening on hardcoded addresses: 

      

        listen 10.0.2.140:443 ssl http2 default_server; # eth0
    listen [2001:db8:1234:5678:1234:56ff:fe78:90ab]:443 ssl http2 default_server; # eth0

     

    Same for the SSH server:  

    #Port 22
AddressFamily any
ListenAddress 10.0.2.140 # eth0
ListenAddress 2001:db8:1234:5678:1234:56ff:fe78:90ab # eth0

     

    This is terrible. My network uses global IPv6 addresses for outgoing internet connections and ULAs for internal access. This change, when I updated from 6.11.5 to 6.12.6, made it so I was unable to access my Unraid server since it's no longer listening on the correct addresses. Also, hardcoding the address itself is terrible for dynamic IPv6 prefixes since it requires some daemon to A) notice the prefix change, B) rewrite the nginx/SSH/SMB/whatever config, then C) reload the server. 

     

    Can this be fixed somehow? I checked the new "Interface extra" section in the Network Settings that was mentioned in the release notes, but that's useless. It looks like Unraid just checks for the current IPv4 and IPv6 address on the interface that's entered there, and puts that into the Nginx config. 

     

    So, that will probably break when the IPv6 prefix changes, and it *definitely* breaks for ULAs and when there's more than one IPv6 address on an interface. This looks like yet another case where new network "features" again weren't properly tested with IPv6 prior to release.

     

    Can the priority for this bug be increased? In my opinion, no longer being able to access the WebGUI AND the SSH server over IPv6 is more than an "annoyance that doesn't affect functionality". Thank god I did that OS update in person instead of over a remote connection, otherwise I would have been locked out.

     

    Can you just give us a toggle to revert back to the old behaviour of just listening on "::"?

     

    EDIT: 

     

    Looks like I can enter an ULA into the "Include listening interfaces" and thankfully that'll get added to the SSHD and Nginx config files (so I can access the server remotely again), but still, that'll break when the ULA or GUA prefix changes as then I'd need to manually alter the config again. 

     

    How does something like this end up in a release?

    Edited by Leseratte10
    Link to comment
    Leseratte10

    In case anyone else runs into this issue, too, I've opened a bug report, and created a small Unraid plugin that works around this issue: https://github.com/Leseratte10/unraid-plugin-bind-all 

     

    This should make all services listen on [::] (IPv6) and 0.0.0.0 (IPv4) just like in 6.11.5. 

     

    Note that this plugin isn't really tested that much and it's my first plugin so make sure you can access the server if this breaks networking somehow. You can install it by going to Plugins -> Install Plugin and entering this URL: 

    https://github.com/Leseratte10/unraid-plugin-bind-all/blob/master/leseratte.patch.listen-on-all-ips.plg

    Edited by Leseratte10
    • Like 1
    Link to comment
    JackieWu
    On 1/1/2024 at 6:22 PM, Leseratte10 said:

    In case anyone else runs into this issue, too, I've opened a bug report, and created a small Unraid plugin that works around this issue: https://github.com/Leseratte10/unraid-plugin-bind-all 

     

    This should make all services listen on [::] (IPv6) and 0.0.0.0 (IPv4) just like in 6.11.5. 

     

    Note that this plugin isn't really tested that much and it's my first plugin so make sure you can access the server if this breaks networking somehow. You can install it by going to Plugins -> Install Plugin and entering this URL: 

    https://github.com/Leseratte10/unraid-plugin-bind-all/blob/master/leseratte.patch.listen-on-all-ips.plg

     

    Thank you @Leseratte10 , it helps !

    Link to comment
    flybrys

    Thanks for this plugin. I hope unraid fix the networking issues for good in the near future.

    I prefer to access my devices using the hostname rather than remembering everything's IP address, and when I'd enter in tower.local it would resolve to the IPv6 ULA which it wasn't even listening on.

    The included and excluded listening interfaces/ips doesn't seem to do anything for me so thanks for providing it :)

    Link to comment
    Dagot

    How can I install the Plugin?

     

    I cannot reach my server outside my home network since a couple of weeks which is quite annoying.

    Is there going to be a fix soon?

    Link to comment


    Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.
    Note: Your post will require moderator approval before it will be visible.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.

    ×

  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.

    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.

×
×
  • Create New...