Beiträge von ozboss

    wgnet0.conf:


    [Interface]
    Address = 10.192.122.1/24
    SaveConfig = true
    PostUp = iptables -A FORWARD -i wgnet0 -j ACCEPT; iptables -A FORWARD -o wgnet0 -j ACCEPT; iptables -t nat -A POSTROUTING -o enp7s7f1 -j MASQUERADE
    PostDown = iptables -D FORWARD -i wgnet0 -j ACCEPT; iptables -D FORWARD -o wgnet0 -j ACCEPT; iptables -t nat -D POSTROUTING -o $enp7s7f1 -j MASQUERADE
    ListenPort = 51820
    PrivateKey = <private key server>



    [Peer]
    PublicKey = <public key client>
    AllowedIPs = 10.192.122.2/32




    wgnet_client.conf:


    [Interface]
    Address = 10.192.122.2/32
    PrivateKey = <private key client>



    [Peer]
    PublicKey = <public key server>
    Endpoint = <my>.duckdns.org:51820
    AllowedIPs = 0.0.0.0/0



    So the AllowedIPs is all open and my client should be able to access all my network devices.
    When I scan the QR code everything shows up correct in my WireGuard app.
    Only the public key is different but that is generated on my client, as far as I understand it.
    I don't know why here the files are called wgnet (e.g. wgnet0) and not wg (e.g. wg0), but I don't think it matters.


    Edit:
    And yes enp7s7f1 is the network card that I'm connected to.
    I don't know why it has the leading $ in PostDown though.

    Thanks for the help @ryecoaaron.
    Installing the headers allows to complete the plugin installation without errors.
    I still don't get a connection though...
    The endpoint is my puplic IP / DDNS and I know for sure that the DDNS I set up works because I was using it with Unraid.
    The same for the port forwarding, I know that it worked before.
    I also checked the config files and everything seems to be correct....
    So right now I'm out of options :D

    Nope. I don't want it to be a commonly used repo. I won't post anymore about it but you should be able to figure out how to enable it by looking at /etc/apt/sources.list.d/omvextras.list.

    Any reason why not? If so I won't use it, it is working though thanks
    Just not really, I still get some errors.
    Log from installing plugin:


    The GUI shows up though, but when I want to enable it I get this error:

    Also not sure about the endpoint.
    Is that the IP of my server?
    Edit:
    Should by my public IP / DNS, right?
    Sorry for the mess :D

    Ok thanks is there a guide on how to enable the beta repo?
    I guess it would be better doing it with the beta repo as it will automatically find new version when they release, right?
    I first thought it was the testing repo but obviously not.

    So I really like Wireguard as I have used it on my Unraid server where it is implemented beautifuly and performs really well.
    I tried the script but couldn't get it to work, I get the same errors as @aykaydub.
    At first I also didn't set my network device.
    Then I uninstalled everything like this (don't know if correct):

    • rm -r /etc/wireguard
    • apt purge wireguard
    • apt purge qrencode
    • apt purge miniupnpc
    • rm /etc/apt/sources.list.d/unstable-wireguard.list
    • rm /etc/apt/preferences.d/limit-unstable
    • apt autoremove

    Then I run the script again with the correct network device, but I still couldn't get the script to finish...


    I also tried @ryecoaarons plugin but this says there are unmet dependencies.
    Doesn't mention which but I figured it might be the wirguard-tools from @Morlans post.
    I am running OMV5 on amd64 though...
    So I tried uploading wireguard-tools_0.0.20190702-3_amd64.deb but it says its not matching the naming convention.


    So I would be really happy for some advice :)


    Edit:
    Tried to install wireguard tools manually:
    apt install /sharedfolders/data/wireguard-tools_0.0.20190702-3_amd64.deb
    Then tried to install the plugin again, but still no luck...

    This isn't Windows. The drivers are builtin to the kernel. Installing from the ISO doesn't install the backports kernel. So, if you install omv-extras BEFORE updating anything, it has an option to disable backports. Then updates *shouldn't* break things since it will keep using the 4.19 kernel which seems to work.

    Ok well I ordered a new network card, lets hope this will work :D Thanks for the help :)

    So lsmod still seems to list the same.
    When I call lspci -v the bottom entry for the device is:


    Kernel driver in use: r8169
    Kernel modules: r8169


    This is the same as before, but all the other information for this device is gone and it only says:


    !!! Unkown header type 7f

    Yes I tried both the automatic and manual way.
    The manual didn't work as it wants to install to driver to the kernel 4 folder and the automatic worked but I still lost the connection after the upgrade.
    lsmod lists a whole bunch of stuff but the r8169 shows up in the list (be aware of the difference of r8168 and r8169).
    Let me know if I can tell you some more specific.

    So I wanted to try out OMV 5 and the setup process worked flawelessly and everything works as expected.
    Only problem:
    After I run an upgrade (upgrade / dist-upgrade doesn't matter) I lose my network connection.


    I expect this to be an driver issue with some newer kernel version, but I am too much of a noob to pin that down exactly.
    My network adapter is Realtek RTL8111/8168/8411 (8111 to be exact) and according to this post it needs the rt8168 driver which is only available up to kernel version 4.15.


    As OMV 5 is using kernel 5 this obviously doesn't work.


    Now the thing is that it all works out of the box when installing OMV.
    It installs the rt8169 driver which isn't recommended but at least works.
    Until I run the upgrade....


    So basically the question is if anybody can help me pin this issue down, so I can tell what part of the update is causing this and how to prevent the update from killing my network.