OMV5 static IPv6 not possible!

  • Hello,


    currently OMV4 is running as VM in a small Proxmox setup, all fine including dual-stack IPv4/IPv6 static IP addresses for OMV VM.

    Want to update to OMV5, decided to go for a fresh installation using openmediavault_5.3.9-amd64.iso.


    Problem 1: IPv6 is not working at all

    After a fresh installation, console explains how to login. This information is wrong as it says:

    To manage the system visit the openmediavault web control panel


    enp52s0: 192.168.178.5

    enp52s0: fe80::xxx

    virbr0: 192.168.122.1

    vmnet1: 172.16.167.1

    vmnet1: fe80::xxx

    vmnet8: 192.168.39.1

    vmnet8: fe80:xxx


    However, the network interface name is ens18 and in fact "ip a" shows that a valid IPv4 address has been received from my DHCP server. It doesn´t show any IPv6 address, which is weird as in my network it should get an address (confirmed by other hosts, e.g. a fresh VM using Debian 10 ISO).

    I proceeded by setting the desired IP addresses in web interface - both IPv4 and IPv6 static IPs.

    IPv4 works, but still no IPv6 appears.


    Problem 2: System Information -> Network doesn´t show any graph (other graphs work)


    I assume both problems somehow are connected.

    Updating OMV from web interfaces to latest version 5.5.9 didn´t change the stiuation.

    I assume I´m not the first and only one to install OMV5 on Proxmox. NIC hardware is VirtIO.

    Any ideas?

    Thank you!

  • After tinkering many more hours, I found out this is not a problem of OMV on Proxmox, but seems to be a general issue.

    I verified this by installing OMV5 on VMware, and experienced the very same results.


    Once I tried to set IPv6 to auto, there suddenly appeared IP addresses! Even the NIC graph in Systeminformation was visible!


    I tried to set IPv6 address by using the CLI tool omv-firstaid. When setting the IPv6 address to static, the following error appeared and afterwards both IPv4 and IPv6 addresses were gone.

    Configuring network interface. Please wait ...

    {'response': None, 'error': {'code': 0, 'message': 'netmask6: The value "64" is not an integer.', 'trace': 'OMV\\Json\\SchemaValidationException: netmask6: The value "64" is not an integer. in /usr/share/php/openmediavault/json/schema.inc:342\nStack trace:\n#0 /usr/share/php/openmediavault/json/schema.inc(293): OMV\\Json\\Schema->validateInteger(\'64\', Array, \'netmask6\')\n#1 /usr/share/php/openmediavault/json/schema.inc(631): OMV\\Json\\Schema->validateType(\'64\', Array, \'netmask6\')\n#2 /usr/share/php/openmediavault/json/schema.inc(399): OMV\\Json\\Schema->checkProperties(Object(stdClass), Array, \'\')\n#3 /usr/share/php/openmediavault/json/schema.inc(289): OMV\\Json\\Schema->validateObject(Object(stdClass), Array, \'\')\n#4 /usr/share/php/openmediavault/json/schema.inc(261): OMV\\Json\\Schema->validateType(Object(stdClass), Array, \'\')\n#5 /usr/share/php/openmediavault/rpc/paramsvalidator.inc(59): OMV\\Json\\Schema->validate(Object(stdClass))\n#6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(179): OMV\\Rpc\\ParamsValidator->validate(\'{"uuid":"fa4b1c...\')\n#7 /usr/share/openmediavault/engined/rpc/network.inc(544): OMV\\Rpc\\ServiceAbstract->validateMethodParams(Array, \'rpc.network.set...\')\n#8 [internal function]: Engined\\Rpc\\Network->setEthernetIface(Array, Array)\n#9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)\n#10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\\Rpc\\ServiceAbstract->callMethod(\'setEthernetIfac...\', Array, Array)\n#11 /usr/sbin/omv-engined(537): OMV\\Rpc\\Rpc::call(\'Network\', \'setEthernetIfac...\', Array, Array, 1)\n#12 {main}', 'http_status_code': 400}}

    ERROR: netmask6: The value "64" is not an integer.

    The netmask value of 64 is already filled in the form and is correct, so I don´t know why it´s causing problems now.

    But this seems to be the cause for my problems.


    Since a static IPv6 address makes much sense for a server, I consider sthis a bug and hope it can be fixed soon.


    BTW the network interfaces and IP addresses show at console seem to be from before last restart, so they only show valid entries if nothing has changed. If you changed to a static IP or DHCP server offered different IP, the addresses shown will be wrong. A little confusing, this led me to totally wrong path whiel searching for the cause.

  • ardent45

    Hat den Titel des Themas von „OMV5 as Proxmox VM, NIC issues, no IPv6“ zu „OMV5 static IPv6 not possible!“ geändert.
  • It's likely that your ISP does not assign IPv6 addresses statically to you, so you can't use that method to configure.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • No, this has nothing to do with ISPs addresses. It´s all about internal IPv6 addresses. My OMV is located in an internal network.


    Depending on your network setup, you can assign static IPv6 addresses internally as you wish, e.g. by using ULA (Unique local addresses, similar to private addresses in IPv4) or by actually having a public IPv6 range (like I do, through a tunnel provider).


    In my case, my internal networks are fully dual-stack, mainly to get used to IPv6 on a daily basis and learn about it. So obviously I want my OMV to be reachable by IPv6, which only makes sense if the server address is static.


    The error seems to originate from some script not being able to accept the correct IPv6 network mask or the like.


    Edit: dual-stack setup works perfectly in OMV4, this bug has been introduced in OMV5, probably Debian10.

  • thank you very much, this helped already quite a bit, but not 100%!


    I changed/added lines 303/304 in /usr/share/openmediavault/firstaid/modules.d/10configure_network.py. Afterwards I could use omv-firstaid to configure a static IPv6 address.


    However, there are still a bunch of temporary/dynamic IPv6 addresses left (additional to the one static IPv6 address).

    For the sake of a clean system (and the ability to configure proper firewall rules according to the one static IPv6 address), I tried to get rid of the temporary/dynamic IPv6 addresses, but don´t know how to achieve that.


    So I reinstalled OMV 5.3.9 completely, and found out that netplan seems to be used only in newer versions. But after updating the system, setting desired addresses by using omv-firstaid, I still ended up with temporary/dynamic IPv6 addresses.


    Out of curiosity, after changing the 10configure_network.py I tried to use the webgui to set a static IPv6 address, but obviously this was not successful as the script really seems to be only used by omv-firstaid.


    I couldn´t find out how to manually configure /etc/netplan/20-openmediavault-ens18.yaml to not generate these temporary/dynamic IPv6 addresses.

    This is the main issue left and from my understanding, we need to figure out how to set the options correctly in this yaml file.

  • Are these fe80 link local addresses you wish to eliminate?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • No, these link local addresses are mandatory for IPv6 to work.


    I´d like to get rid of the addresses marked in red:

    2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 2e:fe:1c:54:af:fe brd ff:ff:ff:ff:ff:ff

    inet 192.168.19.102/24 brd 192.168.19.255 scope global ens18

    valid_lft forever preferred_lft forever

    inet6 2003:4a70:af56:19:c129:308e:9387:fe43/128 scope global dynamic noprefixroute

    valid_lft 39649sec preferred_lft 23449sec

    inet6 2003:4a70:af56:19:e08b:d9df:99c4:97ca/64 scope global temporary dynamic

    valid_lft 535902sec preferred_lft 17024sec

    inet6 2003:4a70:af56:19:2c36:1cff:fe54:b2a8/64 scope global dynamic mngtmpaddr noprefixroute

    valid_lft 2591808sec preferred_lft 604608sec

    inet6 2003:4a70:af56:19::102/64 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::2cfe:1cff:fe54:affe/64 scope link

    valid_lft forever preferred_lft forever


    /etc/netplan/20-openmediavault-ens18.yaml looks as follows

    network:

    ethernets:

    ens18:

    match:

    macaddress: 2e:36:1c:54:b2:a8

    addresses:

    - 192.168.19.102/24

    - 2003:4a70:af56:19::102/64

    gateway4: 192.168.19.100

    gateway6: 2003:4a70:af56:19::1

    ipv6-privacy: true

    dhcp4: false

    dhcp6: false

    nameservers:

    addresses:

    - 2003:4a70:af56:19::127

    search: [intern.lan]


    Once I add "accept-ra: false" to 20-openmediavault-ens18.yaml I get what I want:

    2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 2e:fe:1c:54:af:fe brd ff:ff:ff:ff:ff:ff

    inet 192.168.19.102/24 brd 192.168.19.255 scope global ens18

    valid_lft forever preferred_lft forever

    inet6 2003:4a70:7c18:9::102/64 scope global

    valid_lft forever preferred_lft forever

    inet6 fe80::2cfe:1cff:fe54:affe/64 scope link

    valid_lft forever preferred_lft forever


    Disabling to accept Router Advertisements might not be the elegant solution as there could be negative implications, as discussed e.g. here: https://superuser.com/question…guration-on-ipv6-in-linux

    Then again, sysctl -w net.ipv6.conf.all.autoconf=0 doesn´t survive a reboot, so that´s no solution either.


    But for comparison, in a standard Debian 10 machine, I configure the IPv6 address in /etc/network/interfaces as static and the result is as desired (only this one IPv6 address + the link local , of course). Interestingly, also in Debian the setting results into "net.ipv6.conf.ens18.accept_ra = 0".


    So I´d be happy with this solution. Now we´d just need OMV5 to provide this configuration through the Web interface (and omv-firstaid).

  • Hello,


    is there any change to get this fixed?

    Each time I change something network-related in the web interface, the configuration gets overwritten and I end up with a bunch of temporary IPv6 addresses contrary to the configuration.


    The solution to get ONLY static IP addresses as configured in the web interface is to append the parameter "accept-ra: false" to 20-openmediavault-ens18.yaml


    I hope development can fix this issue easily.


    Thank you!

    • Offizieller Beitrag

    According to the netplan.io documentation the kernel default settings are used when accept-ra is not set. OMV does not set this option for static IP addresses because of that reason to allow the users to customize this behavior to their needs. If we set accept-ra: false we will cut-off this ability for the users. So it is on you to customize this to your needs. Simply create a file in /etc/sysctl.d to set your sysctl settings permanently.

  • Thank you, but whatever I try to set in /etc/sysctl.d, it won´t work.


    After researching for a while, I actually landed back at the link I posted above, stating:

    also by last, if you are using netplan, seems that it may override it all.
    only solution I found was to disable RA, by adding the flag to /etc/netplan/xxx.yaml

    accept-ra: false


    If this is true (and my tests indicate that), then the setting has to be in netplan, but netplan is handled by OMV, so there´s no solution than to manually change the yaml file each time something (network-related) has been changed in the web interface.


    Well, I accept your decision, it´s not that changes are made on a daily basis in network web interface and I have added this additional step in my own documentation.


    But it sucks, so I want to say my opinion :saint::

    If I set a static IPv6 address in web interface, I actually expect to have only this one static address and no other temporary dynamic addresses. Otherwise I would have used the setting "auto".

    Having a bunch of temporary addresses breaks other stuff, such as ACLs on a firewall, NFS etc., everything that depends on a certain static address.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!