mattkhan
-
Posts
99 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by mattkhan
-
-
I can't find a public repo for openvpn-as & it seems they use a trac instance on their site instead of github for issues so I logged a support ticket.
-
I've added this to my setup recently, v easy to get going so thanks for providing it.
I'm using a 2.4.3 openvpn client and I notice it complains about
WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).'
This seems to be https://community.openvpn.net/openvpn/wiki/SWEET32
The container logs indicate this is a 2.3.17 server
2017-08-04 17:14:46+0100 [-] OVPN 0 OUT: 'Fri Aug 4 17:14:46 2017 OpenVPN 2.3.17 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jun 27 2017'
https://openvpn.net/index.php/open-source/downloads.html indicates this is the old stable version, 2.4.3 is the current stable and this seems to be the fix (e.g. picking some other random docker openvpn container - https://github.com/kylemanna/docker-openvpn/issues/267) .
I notice that your dependency is on https://openvpn.net/index.php/access-server/download-openvpn-as-sw.html for ubuntu 16 and it's not immediately obvious how this relates to the openvpn version. Do you have a plan to close this gap?
-
Over the last few weeks my server has been getting random kernel warnings. I have been trying to figure out why they are happening all of the sudden and I think they have something to do with this plugin. After updating to the latest plugin I started running the initial build and export on both of my disks. This kernel warning happened right after I started that process. Does any of this log mean anything too you?
bts buffer is the branch trace store buffer, google indicates there was a patch last year to reduce the frequency of such logs & whether it happens or not is a function of memory fragmentation. I would think that seeing this is just a sign that this plugin is working your CPU hard. Any other problems noted or just that warn?
-
Thanks for your observation.
I have seen in the past that RFS can have issues in V6 when writing extended attributes and once in a blue moon completely hangs. I am going to put a BIG warning that using this plugin in combination with RFS may lead to instability.
WARNING: USING THIS PLUGIN ON DISKS FORMATTED IN REISERFS MAY LEAD TO SYSTEM INSTABILITY. IT IS ADVISED TO USE XFS.
OK thanks, good to have an explanation for the behaviour.
-
I installed this earlier and it almost immediately triggered the reiser issue described in https://lime-technology.com/forum/index.php?topic=39911.0 which I've never seen before, by "almost immediately" I mean "within a minute or so".
emhttp was then hung and wa times were at ~50% or so & it seems this was due to a bs2sum process being stuck in D state (hence unkillable even by kill -9) as it attempted to calculate the hash for some particular file, the offending disk was thus unmountable and a hard reset was the only way out. The system itself was still responsive through all this, just emhttp and that zombie process was the (big) problem.
The disk in question has been running solidly for a shade over 2yrs and no other disk issues noted until now on that sata controller. reiserfsck has just finished on the offending disk and no issues noted (some journal replay action but nothing else to report), smart report is also completely clear.
It's not obvious how your plugin could trigger this (as opposed to some previously unexploited weakness in my system) but thought I'd mention it anyway.
-
System "Name" - Debian jessie
Xen capable? - Yes
PCI Passthrough capable? - Yes
-
Case - 3u server case
-
CPU - Intel i5-4570
-
Motherboard- asrock z87 extreme 6
-
GPU - Intel hd4600
-
RAM 8G ddr3
-
PSU - thermaltake sp550-m
-
HBA / SAS Card - N/A (Mobo has 2 sata controllers)
-
NIC(s) - dual onboard Intel NICs bonded with ifenslave in 802.3ad LAG mode and assigned to xenbr0
-
Hard drives - Samsung evo 840 + WD Reds 2TB
Brief description of VMs and use cases
Dom0 - debian jessie
DomU1 - unraid
DomU2 - Logitech media server
Sent from my Nexus 7 using Tapatalk
-
Case - 3u server case
-
vt-d is required for passthrough to an HVM and is highly recommended, but not required, for passthrough to a PV.
VT-d (or AMD-Vi) is required for device passthrough PERIOD, regardless of the type of VM you are passing it to.
Perhaps you were referring to VT-x (or AMD-V)? VT-x is required for HVM, but has nothing to do with passthrough. It is not required for PV, nor am I aware of an instance where it's recommended.
i was quoting the xen wiki earlier.
No iommu means a security flaw but this doesn't seem like a massive concern in a home network (opinions may vary of course). Full details on the relevant page - http://wiki.xen.org/wiki/Xen_PCI_Passthrough
A quick Google shows examples of people using this feature recently - http://comments.gmane.org/gmane.comp.emulators.xen.user/80723
-
A few thoughts
* shouldn't this be on the wiki itself? I think a page like this should start with the use cases, i.e. give people a reason to care.
* you start by saying "you need xyz in order to do abc" but then don't say how to determine whether you have xyz
* annotating each section with links to the relevant bits of the xen wiki for further reading would make sense
* a factual inaccuracy
In English, that means your CPU / motherboard must be of a certain standard to make the cut for HVM. Intel requires vt-d (check the ark part of the intel site if you're unsure) and AMD have AMD-V technology (I'm not as familiar with this). Intel K series processors are generally not supported, but in addition to the CPU supporting vt-d, your motherboard and more specifically your exact BIOS revision must as well.
you're conflating HVM and IOMMU, as the xen wiki says
Note that IOMMU/VT-d support is not the same as HVM support; it is possible to have HVM support without an IOMMU, or vice versa.vt-d is required for passthrough to an HVM and is highly recommended, but not required, for passthrough to a PV.
[Support] Linuxserver.io - OpenVPN AS
in Docker Containers
Posted · Edited by mattkhan
No comment from them on when they will upgrade openvpn-as to openvpn 2.4 but it seems it is not necessary anyway as the config options to avoid this are available now. They are described in https://sweet32.info/ as either a client side only option
reneg-bytes 64000000
Alternatively, if you control the server and client, then you can set on both the server and client config directives (via the Advanced VPN page)
cipher AES-256-CBC
It doesn't seem there is a way to set this via the cli or in config so I don't suppose there is anything you can do to set this in the container. I suppose you could add something to the setup docs though.
FWIW further reading suggests to use a few other directives, namely to set server and client as follows for a reasonably hardened config
cipher AES-256-CBC auth SHA512 tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
This seems to work fine for me.
The support guy also commented on the possibility of an attack via the embedded twisted web server which I'll just post here for reference