Posts by outcave

    It will fix your VPN, but will also break binary compatibility with everything else that uses SSL (and expects LibreSSL). Not impossible, but not a quick change either. You energies would be more productive figuring out the patch/hack for LibreSSL ..

    Should I find a patch for LibreSSL? And how? LibreSSL actually do not want to resolve it.... How Can I do?
    I expect LibreELEC should take charge and find a solution for it! As it is now LibreELEC do not "work" for certificate with year after 2038: it's a fact...

    i understood your problem, but im telling you now, i switched from ipvanish to another vpn (they used a >2038 expiry date and couldnt change it) and it works again on LibreELEC v7.90.005 and on the latest kodi 17 millhouse alphas

    i gathered some information about other vpn's if you want to leave hide.me

    these are all in the openvpn manager:
    vpn unlimited - openvpn cert valid until 2023
    ibVPN - 2020
    celo - every 2 years
    AirVPN - 2024

    I don't want to leave Hide.me, now I'm using it without problems with LibreELEC version 7.0.2. For the future? May be I will compile OpenSSL and overwrite to LibreSSL ;)

    Hi guys.
    Please no make confusion :) .

    The Certificate problem is on all versions of LibreELEC v7.90.004 ALPHA and next versions because these versions has inside the newest version of LibreSSL. These new versions of LibreSSL does not work with Certificate that will expire after year 2038 on 32 bit operating system (such as Raspberry Pi 2). It seems that LibreSSL does not want to solve this issue and it seems that also LibreELEC does not want to switch to OpenSSL (OpenSSL works fine also on 32 bit operating system, so OpenSSL is OK on Raspberry Pi).

    So the problem is not Hide.me, is not IPVanish, is not VPNManager addon. The problem is only LibreSSL on 32 bit operating system.

    Now you have various way to follow to solve the issue:

    1. Contact your VPN "provider" and ask to have a new Certificate (CA) that will expire before 2038. Hide.me is "friendly" and I'm quite sure that will give you a new Certificate if you will explain the problem. So open a Support Ticket on Hide.me website.
    2. Contact LibreELEC team to ask to use OpenSSL instead to use LibreSSL (see these my posts and later: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0))
    3. Contact LibreSSL to ask to solve the issue (I think this is useless, see here: Year 2038 bug on LibreSSL 32bit regression between 2.2.x and 2.3.x · Issue #207 · libressl-portable/portable · GitHub)
    4. Use a more old version of LibreELEC (version 7.0.2 works fine because it uses an old version of LibreSSL) or use OpenELEC 6.0.3 that uses OpenSSL

    Actually I'm using LibreELEC version 7.0.2 with the last version of VPNManager addon made by zomboided and I can connect to Hide.me VPN without problems.

    About Hide.me, there WAS a problem on routing table on OpenELEC / LibreELEC (VPN was connected but all traffic does not go via VPN) now solved since VPNManager addon version 1.9 ("redirect-gateway def1" option was added into VPNManager addon).

    More info about my analysis on routing table for Hide.me see this my post: OpenELEC Mediacenter - OpenELEC Forum - VPN Manager for OpenVPN (38/63)


    Enjoy.

    Hi.
    This behavior is on LibreELEC and OpenELEC on Raspberry Pi 2, I don't know if it happens also on others system.
    I don't know why but when I specify DNS (then DNS Server not obtained from the DHCP) by default the system put specific routes of these DNS address into routing table.

    This is the route print of LibreELEC when IP fields (IP, subnet mask, default gateway, DNS...) are given by DHCP (so DNS Servers automatically obtained from DHCP):

    Code
    LibreELEC:~ # route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
    192.168.1.0     *               255.255.255.0   U     0      0        0 eth0


    This is the route print of LibreELEC when I manual configure DNS Servers (8.8.8.8 and 8.8.4.4 in this case):

    Code
    LibreELEC:~ # route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
    8.8.4.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
    8.8.8.8         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
    192.168.1.0     *               255.255.255.0   U     0      0        0 eth0


    As you can see the 8.8.8.8 and 8.8.4.4 (DNS Servers) have their specific routes...

    On my experience this behavior is in OpenELEC 6.x and LibreELEC (Jarvis 16.1) v7.0.2 and also LibreELEC (Krypton) v7.90.004 and next versions.
    I know how to remove that routes, but my question is why the system put these unsefull routes?
    How can say to OS to do not put the DNS Servers route when manually assign DNS Server?

    In a VPN environment this give a DNS leak because the traffic to DNS Servers will go via eth0 (default) and not via the tun0 interface (VPN interface) and on my experience there is a very strange behavior: also if I remove these routes the system (LibreELEC / OpenELEC) will still and always uses these routes for DNS lookup, so the DNS query will go "directly" to DNS Servers (via eth0 interface) not using the VPN tunnel (via tun0 interface); I have checked this strange behavior with "netstat": there are established connection to DNS from eth0 and not from tun0!

    This is the route print of LibreELEC when I manual configure DNS Servers (8.8.8.8 and 8.8.4.4 in this case) and when OpenVPN is up:

    Code
    LibreELEC:~ # route
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    default         10.3.200.254    0.0.0.0         UG    0      0        0 tun0
    8.8.4.4         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
    8.8.8.8         192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
    10.3.200.0      *               255.255.255.0   U     0      0        0 tun0
    159.122.133.197 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
    192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
    192.168.1.1     *               255.255.255.255 UH    0      0        0 eth0

    As you can see, also if the VPN connection is UP and the default gateway (destination) is via VPN, the DNS routes are there and the connection to DNS goes via eth0 interface and not via tun0......

    This the netstat:

    Code
    Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
    udp        0      0 192.168.1.65:44941      google-public-dns-a.google.com:domain ESTABLISHED 294/connmand
    udp        0      0 192.168.1.65:47546      google-public-dns-b.google.com:domain ESTABLISHED 294/connmand
    udp        0      0 192.168.1.65:35954      google-public-dns-a.google.com:domain ESTABLISHED 294/connmand
    udp        0      0 192.168.1.65:58527      google-public-dns-b.google.com:domain ESTABLISHED 294/connmand

    As you can see, ESTABLISHED connections to the DNS Servers are via eth0 and not via tun0.
    This happens also if I manual remove the DNS entry for the routing table ("route del 8.8.8.8" and "route del 8.8.4.4"): the "connmand" process will always goes directly (using eth0) and not via VPN (using tun0).
    If I kill the "connmand" process (with PID 294 in this case), the "connmand" process will automatically starts again and the DNS connection, however, will always goes directly (using eth0) and not via VPN (using tun0).

    I think this is a wrong behavior of connman.

    Any solutions / patch?
    Thanks!

    Hi.
    I'm trying to connect to Hide.me VPN service with OpenVPN on LibreELEC (Krypton) v7.90.004 ALPHA on a Raspberry Pi 2.
    I have this error:


    May be some Root CA missed in LibreSSL?

    Just for your info, with OpenELEC 6.0.3 and with LibreELEC (Jarvis 16.1) v7.0.2 I was able to connect with the exactly same .ovpn file.

    I hope in your help.
    Thanks.