Posts by Pollux

    I got an email report this morning saying this:


    Code
    CRON-APT RUN [/etc/cron-apt/config]: Sun Apr 26 04:00:01 CEST 2015
    CRON-APT SLEEP: 3025, Sun Apr 26 04:50:26 CEST 2015
    CRON-APT ACTION: 3-download
    CRON-APT LINE: /usr/bin/apt-get -o Acquire::http::Dl-Limit=25 autoclean -y
    Reading package lists...
    E: The value 'stable' is invalid for APT::Default-Release as such a release is not available in the sources
    CRON-APT LINE: /usr/bin/apt-get -o Acquire::http::Dl-Limit=25 dist-upgrade -d -y -o APT::Get::Show-Upgraded=true
    Reading package lists...
    E: The value 'stable' is invalid for APT::Default-Release as such a release is not available in the sources


    It looks like the same issue as this thread, but since the OMV release is different, I thought it would be better to have another dedicated thread.


    I am guessing this issue has to do with the release of Jessie which is the new stable as of yesterday. I have replaced "stable" with "wheezy" in the file /etc/apt/apt.conf.d/99openmediavault-release and now omv-update command doesn't show any issue.


    Does anyone else got this problem?


    edit
    See here for the solution:

    By the way, this is only affects systems upgraded from 0.5. Just remove apt.conf rm -f /etc/apt/apt.conf and it should be fine. The file isn't used anymore.

    Client to client option is not relevant in this case as it is used to allow VPN client to reach another VPN client.


    Default gateway option should only be used to route all traffic from VPN client toward VPN server, including internet traffic. If unchecked a route to the LAN subnet will be pushed to VPN clients.


    No extra options should be needed for external clients to reach LAN clients because an iptables NAT rule is set that will NAT VPN client traffic to the LAN VPN server IP. If no iptables NAT rule is set, a route to the VPN network would be required on each LAN clients.
    You can check iptables NAT status with the following command (with a typical output):

    Code
    root@NAS:~# iptables -t nat -S
    -P PREROUTING ACCEPT
    -P INPUT ACCEPT
    -P OUTPUT ACCEPT
    -P POSTROUTING ACCEPT
    -A POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source 192.168.10.30
    root@NAS:~#


    In my case, 192.168.10.30 being the IP of my NAS on the LAN (subnet 192.168.10.0/24) and 10.8.0.0/24 being the subnet of the VPN.


    I see one case where there could be an issue: if the VPN client is on a private LAN prior to access the Internet and if that private LAN subnet is identical to the private LAN subnet where the VPN server resides, there will probably be issues for the VPN client to access the LAN clients behind the VPN server.

    Sorry for the issue, update to the latest openvpn plugin (it was released this morning) which contains the bugfix.


    If you are interested, see the last part of this thread for the gory details.

    It should be fixed now :)


    Thanks.


    To be completely thorough, there is still one case where this could mess up the configuration. If for whatever reason the iptables rule is not present in the iptables nat table (table flushed by another process for example), the iptables rule deletion will fail and mkconf will fail.


    We could solve this by adding '|| true' to the command:

    Code
    iptables -t nat -D $(tail -1 ${SERVICE_IPTABLES_CONF} | cut -c20-) || true

    Ok I reproduced the issue. It indeed happens on initial setup because the file is not created.


    For the story, I added that line to delete the previous iptables nat rule because everytime a change is made (and saved), the nat rule was added, whether or not you change the VPN subnet. For instance, if you do 10 configuration changes, you will end up with 10 iptables line in the nat table (and it could be the same that appears 10 times if you did not change the VPN subnet).


    As a quick fix, in the /usr/share/openmediavault/mkconf/openvpn replace the following line:

    Code
    iptables -t nat -D $(tail -1 ${SERVICE_IPTABLES_CONF} | cut -c20-)


    By this:

    Code
    if [ -f ${SERVICE_IPTABLES_CONF} ]; then
    iptables -t nat -D $(tail -1 ${SERVICE_IPTABLES_CONF} | cut -c20-)
    fi


    This should check first if the file exists before running the deletion of the iptables rule. You can also remove/comment that line and you will have the same behavior as before (i.e. iptables rule added everytime a configuration change is made to openvpn).

    Those are take from the openvpn doc website. So i was thinking as an improvement to add a checkbox to the certificate items to config the bundle as this (no redirect traffic and only available if the in the general redirect gateway is checked)


    That seems pretty confusing. I'm not sure that I exactly get what you want. If the purpose is to make different client configuration that coexist with each others, I think having an extra field which can be freely populated for each certificate entry is preferable. This way it would be less confusing for the end-user: one unique configuration/behaviour for each clients, and the possibility for 'power-users' to customize/tune a specific client. This evolution doesn't look easy from my bad developer skill point of view.



    Another improvement has to do with the bundle file (zip with certs, keys and conf), just to use a single config file (.ovpn extension) with the embedded certificates and keys like this:
    [...]
    In some clients just a double click will install it.


    May be another time ;) . From a quick look perspective, it would require quite some changes.


    On a side note, I just submitted a pull requested with the following changes:


    * Fixed cannot input domain in 'DNS search domain' field
    * Fixed cannot input multiple entries separated with commas
    * Fixed log entries missing for date from 1 to 9
    * Restricted 'Common Name' field in certificate tab to alphanum
    * Fixed iptables rule not added upon boot/reboot
    * Refined iptables to remove previous rule before adding new rule
    * Added 'PAM authentication' checkbox


    We'll need to wait for the pull request to be reviewed and accepted, then wait for the plugin to be released.

    If Default Gateway option is checked, all network traffic of the client (including internet) will be routed to the VPN Server, via the following parameter in the config file:

    Code
    push "redirect-gateway def1 bypass-dhcp"


    If Default Gateway option is not checked, a route to the private network (i.e. your LAN where you NAS is located, in most cases something like 192.168.1.0/24), is pushed to the client. In this case, only the traffic to that specific network is routed to the VPN Server, the remaining traffic is routed to the default gateway of the client. This is done via the following parameter in the config file:

    Code
    push "route 192.168.1.0 255.255.255.0"


    These are mutually exclusive, but in any cases traffic from client to private LAN should be routed to the VPN server. And btw, whichever option you choose, the ip forwarding is enabled in sysctl.


    After looking into this, it may be because the iptables NAT rules are not applied on startup (I saw an error in openvpn mkconf script). If you start-up your NAS, the iptables rules will not be applied until you do and apply a configuration modification to the openvpn plugin via webgui.
    Thanks to you, that's one more to the bugfix list :D

    1. This is already implemented via the Default Gateway option.
    2. Thanks for reporting this. I'll see what I can do.


    Btw: when I pass my mouse over the bottom right of each post I see five buttons: quote, report, like, dislike, go to top.

    so a few questions to help me understand what's going on here (networking is completely foreign to me)


    1. What does that Default Gateway option in the plugin do? i.e. what does it mean for clients to redirect their default network gateway through the vpn?
    2. I have set, in openvpn plugin options, my DNS server to be the internal IP of my router (192.168.1.1). What does it mean to have my router be a DNS server?
    3. Why does it work when I map \\192.168.1.109\Media, but not when I map \\24.84.42.76\Media (public IP), or \\10.8.0.0\Media (VPN network)
    4. Do my clients use the internet connection that it is connected to? Or the internet connection that my NAS/vpn server is connected to? Which bandwidth does it take up?


    Regarding 1 and 4, if Default Gateway option is checked, all network traffic of the client (including internet) will be routed to the VPN Server (which acts as a gateway), in this case it is preferable to set the DNS Server IP in the OpenVPN options.
    If Default Gateway option is not checked, a route to the private network (i.e. your LAN where you NAS is located), in your case 192.168.1.0/24, is pushed to the client. In this case, only the traffic to that specific network is routed to the VPN Server, the remaining traffic is routed to the default gateway of the client, therefore it should not be needed to set the DNS Server IP in the OpenVPN options.

    Awsome information subzero79!


    I banged my head last night trying to make a script which check username/password with pwauth until I found out that only www-data (or root) is allowed to run pwauth (which is hard-coded into pwauth). Since I did not want to re-compile pwauth, I gave up.


    The plugin method is so much easier. In the end, to sum up, the server only need the following in the Extra field:

    Code
    plugin /usr/lib/openvpn/openvpn-auth-pam.so login


    (I think it also makes it more secure since nothing is written on disk, even temporarily)


    And on client side, the following needs to be added to the config file:

    Code
    auth-user-pass

    As ppfdez said, but for the server part, you will need to put the following in the 'extra options' of OpenVPN plugin:

    Code
    auth-user-pass-verify pass.sh via-env
    script-security 3


    pass.sh should also be executable

    Code
    chmod +x /etc/openvpn/pass.sh

    It is probably possible but my developer skill really sucks. Unless official developer is interested in adding this feature, I don't see it coming anytime soon.


    You may want to try the openmediavault-openvpnas plugin, it may offer more tunable options.

    resize2fs is exclusively for ext2/3/4 file systems. For xfs you would indeed use the xfs_growfs command. The command should be available on OMV.


    Procedure is almost identical to your previous topic (Extend Raid5) minus the last part :


    Code
    mdadm --grow /dev/mdX --raid-devices=4 --add /dev/sdY
    pvresize /dev/mdX
    vgdisplay
    lvextend -l +100%FREE <logical vol path>
    xfs_growfs <logical vol path>


    As stated in the above mentionned topic, you should be able to grow the raid by adding the disk in the webgui, but you won't be able to resize the Physical Volume since the LVM plugin only allows creation/deletion of a PV. For that part you will have to do it from command line. The rest (extend LV then grow FS) should be possible from webgui.


    :!: Warning: after issuing the mdadm grow command, you should wait for the raid array to complete rebuilding before extending the lvm and filesystem. It could take several hours or a couple of days depending on your array size.

    Did you launch the OpenVPN gui on Windows as Administrator ?


    Because if you don't, OpenVPN won't be able to add routes and therefore you will not be able to access private IPs.


    You should be able to see if OpenVPN was able to add routes or not in the log window of OpenVPN. You can also check your Windows routes in a terminal window by typing 'route print'.

    I do not have that issue nor am I able to reproduce it.


    Can you give the output of the following command:

    Code
    cat /etc/proftpd/proftpd.conf | grep PassivePorts


    If it does not output anything, you can try to force the regeneration of proftpd.conf file with the following command:

    Code
    omv-mkconf proftpd


    If you have checked the Passive FTP 'Use the following port range' flag, it should add the following line in the proftpd.conf file:

    Code
    PassivePorts 49152 49202