Re: [Openvpn-users] surf the internet through openvpn

[Joe]

On Sat, 5 Jun 2021 07:59:40 +0200
Stella Ashburne  wrote:

> Hi guys,
> 
> This mailing list is for discussions concerning Debian.
> 
> For discussions on specific topics such as openvpn, please post your
> questions on https://forums.openvpn.net/ or
> https://www.reddit.com/r/OpenVPN/ 
> 
> 

In general, yes, particularly with standalone applications.

But most applications when supplied through a distribution are
customised to some degree, and this is particularly true of networky
things like openvpn. The things that get customised are the fine
details of how the program interacts with the rest of the distribution,
and that is often where people need help, particularly if they are
familiar with a different distribution. Different distributions may
well have different policies about /etc/resolv.conf, for example, a
file often central to vpn issues.

So I'd agree that openvpn forums are the best place to get information
on openvpn, but there may be questions about it that only users of both
Debian and openvpn can answer. If I had recently had doings with
openvpn, I could probably have answered this one, but the last time was
too long ago. Configurations often change between Debian versions. There
are two broad applications of openvpn, either pure point-to-point for
secure remote access or, as in this case, route everything through the
tunnel to place the client effectively within the server's network.
I've always used it for the latter function, and I know that the advice
given so far has been necessary, but I couldn't say from recent
knowledge if it is sufficient.

It does seem likely in this case that the trouble is in the
configuration file. There are many of these around the Net, but it is
likely that most of the Debian-specific tweaks to openvpn affect this
file and a Debian-compatible example is vital. 

It is also possible that someone using a firewall generating
application may need to do something to it, or that may happen
automatically, while someone using raw iptables or nftables will already
know they have to do this themselves. An entirely new kind of interface
appears with openvpn, and the firewall may be written to reject
anything from previously-unknown interfaces. Some firewall issues may be
Debian-dependent as they are also networky things.

-- 
Joe

Re: [Openvpn-users] surf the internet through openvpn

[Stella Ashburne]

Hi guys,

This mailing list is for discussions concerning Debian.

For discussions on specific topics such as openvpn, please post your questions 
on https://forums.openvpn.net/ or https://www.reddit.com/r/OpenVPN/
 


Sent: Saturday, June 05, 2021 at 7:04 AM
From: "Bonno Bloksma" 
To: "debian-user list" 
Cc: "Fermin Francisco" 
Subject: Re: [Openvpn-users] surf the internet through openvpn

Please keep the discussion on the list.
And sorry for top posting, this client refuses todo otherwise :-(
 
Make sure traffic coming from the openvpn client can indeed access the 
internet, test with ping.  If that does not work solve that problem first. Look 
at routing and NAT on your openvpn server.
 
Once that works try what happens with a browser, go to whatismyip.com or a 
similar website. The client ip the website sees should the ip of your openvpn 
server.
If ping works but http(s) does not you probably have a firewall issue.
 
If that works then SMTP should work as well as long as the receiving server has 
no problem with the discrepency in the ip number, hostname and PTR record.
 

Bonno Bloksma (mobile)
 
 Op 4 jun. 2021 om 22:01 heeft Fermin Francisco  het volgende 
geschreven:
 


Hi!
My problems are two:
 
After I putted the push "redirect-gateway local def1" in server conf file.
 
1. OpenVPN Linux's clients can't surf into the internet (Windows clients can 
surf into the internet), but can connect to remote software.
2. SMTP cannot worked (Thunderbird).
 
 
Sorry, my english is not good.
 
 
José Fermín Francisco Ferreras Registered User #579535 (LinuxCounter.net)
 
 

El viernes, 4 de junio de 2021 02:05:40 a. m. AST, Bonno Bloksma 
 escribió:
 
 

Hello

> How can I make openvpn clients (Linux clients) surf the internet through 
> openvpn using the public ip of the openvpn server

The client config should contain the line
redirect-gateway local def1

This will let OpenVpn add some lines to you routing table that make sure that:
- your client can still reach the OpenVPN server via the normal internet 
connection.
- All other traffic will leave the client via the openVPN tunnel.

Make sure the routing on your openVPN server and your firewall are set up 
correctly.

>(the openvpn server is on Windows)? And also that emails using Thunderbird can 
>work with this method (that emails can enter and leave without problems).
This is just routing via another node, it has no influence on the protocol as 
the client still initiates all traffic sessions.

Ps. If you want you can push the line from the servers if you want to have it 
configures on all clients.

Bonno Bloksma
 

Re: [Openvpn-users] surf the internet through openvpn

[Bonno Bloksma]

Please keep the discussion on the list.
And sorry for top posting, this client refuses todo otherwise :-(

Make sure traffic coming from the openvpn client can indeed access the 
internet, test with ping.  If that does not work solve that problem first. Look 
at routing and NAT on your openvpn server.

Once that works try what happens with a browser, go to whatismyip.com or a 
similar website. The client ip the website sees should the ip of your openvpn 
server.
If ping works but http(s) does not you probably have a firewall issue.

If that works then SMTP should work as well as long as the receiving server has 
no problem with the discrepency in the ip number, hostname and PTR record.

Bonno Bloksma (mobile)


Op 4 jun. 2021 om 22:01 heeft Fermin Francisco  het volgende 
geschreven:


Hi!
My problems are two:

After I putted the push "redirect-gateway local def1" in server conf file.

1. OpenVPN Linux's clients can't surf into the internet (Windows clients can 
surf into the internet), but can connect to remote software.
2. SMTP cannot worked (Thunderbird).


Sorry, my english is not good.



José Fermín Francisco Ferreras Registered User #579535 (LinuxCounter.net)


El viernes, 4 de junio de 2021 02:05:40 a. m. AST, Bonno Bloksma 
 escribió:


Hello

> How can I make openvpn clients (Linux clients) surf the internet through 
> openvpn using the public ip of the openvpn server

The client config should contain the line
redirect-gateway local def1

This will let OpenVpn add some lines to you routing table that make sure that:
- your client can still reach the OpenVPN server via the normal internet 
connection.
- All other traffic will leave the client via the openVPN tunnel.

Make sure the routing on your openVPN server and your firewall are set up 
correctly.


>(the openvpn server is on Windows)? And also that emails using Thunderbird can 
>work with this method (that emails can enter and leave without problems).

This is just routing via another node, it has no influence on the protocol as 
the client still initiates all traffic sessions.

Ps. If you want you can push the line from the servers if you want to have it 
configures on all clients.

Bonno Bloksma

Re: Openvpn 2fa google

[Gokan Atmaca]

the error is as follows.  Verification code is correct.

-% error:
openvpn(pam_google_authenticator)[16239]: Invalid verification code for usi21

On Wed, Jun 2, 2021 at 10:58 PM Gokan Atmaca  wrote:
>
> Hello
>
> I use Google for 2FA. My configuration is as follows. However, I could
> not log in. Stn. When I configure it with TLS I am able to login. But
> unfortunately it doesn't work when I add 2fa. What could be the
> problem ?
>
> -% error:
> TLS Auth Error: Auth Username/Password verification failed for peer
>
> -% Pam_config:
> auth required /usr/lib/x86_64-linux-gnu/security/pam_google_authenticator.so
> secret=/etc/openvpn/google-authenticator/${USER} forward_pass
> accountrequired pam_permit.so
>
> -% usr_create:
> sudo su -c "google-authenticator -t -d -r3 -R30 -f -l \"My VPN\" -s
> /etc/openvpn/google-authenticator/client2981" - gauth
>
>
>
> Thanks.
>
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄

Re: OpenVpn Mac Address Filter

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-02 8:45 a.m., Gokan Atmaca wrote:
> Hello
> 
> There I am trying to compile openvpn. I am getting an error as below.
> 
> What can be the problem ?
> 
> -% error:
> /usr/bin/install: cannot stat './openvpn.8': No such file or directory
> make[4]: *** [Makefile:515: install-man8] Error 1
> make[4]: Leaving directory '/root/openvpn/doc'
> make[3]: *** [Makefile:773: install-am] Error 2
> make[3]: Leaving directory '/root/openvpn/doc'
> make[2]: *** [Makefile:606: install-recursive] Error 1
> make[2]: Leaving directory '/root/openvpn/doc'
> make[1]: *** [Makefile:615: install-recursive] Error 1
> make[1]: Leaving directory '/root/openvpn'
> make: *** [Makefile:915: install] Error 2
> 

Maybe you could get more help...
But please give more information...

What version ?
Are you compiling from the upstream source code (author) ?
Are you compiling from a debian source code package ?
What platform are you using ?

Give as much information you can so we can try to reproduce what you are
trying. This way we'll be able to solve this problem.

I presume you are using a debian source code package (DSC) ?
Are you compiling the stable ? the unstable ? testing ?

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: OpenVpn Mac Address Filter

[Gokan Atmaca]

Hello

There I am trying to compile openvpn. I am getting an error as below.

What can be the problem ?

-% error:
/usr/bin/install: cannot stat './openvpn.8': No such file or directory
make[4]: *** [Makefile:515: install-man8] Error 1
make[4]: Leaving directory '/root/openvpn/doc'
make[3]: *** [Makefile:773: install-am] Error 2
make[3]: Leaving directory '/root/openvpn/doc'
make[2]: *** [Makefile:606: install-recursive] Error 1
make[2]: Leaving directory '/root/openvpn/doc'
make[1]: *** [Makefile:615: install-recursive] Error 1
make[1]: Leaving directory '/root/openvpn'
make: *** [Makefile:915: install] Error 2

On Mon, May 31, 2021 at 12:18 PM Gokan Atmaca  wrote:
>
> > Mac address is available only on the local network. You usually do not
> > get the mac address of the openvpn client but the mac address of nic of
> > the last router facing your openvpn server.
>
> You are right. I will try Google 2fa.
>
>
>
> On Sat, May 29, 2021 at 9:57 PM Erwan David  wrote:
> >
> > Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> > > Hello
> > >
> > > Can we filter MAC addresses of Openvpn clients ?
> > >
> > > Thanks.
> > >
> > >
> > >
> > Mac address is available only on the local network. You usually do not
> > get the mac address of the openvpn client but the mac address of nic of
> > the last router facing your openvpn server.
> >

Re: OpenVpn Mac Address Filter

[Gokan Atmaca]

> Mac address is available only on the local network. You usually do not
> get the mac address of the openvpn client but the mac address of nic of
> the last router facing your openvpn server.

You are right. I will try Google 2fa.



On Sat, May 29, 2021 at 9:57 PM Erwan David  wrote:
>
> Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> > Hello
> >
> > Can we filter MAC addresses of Openvpn clients ?
> >
> > Thanks.
> >
> >
> >
> Mac address is available only on the local network. You usually do not
> get the mac address of the openvpn client but the mac address of nic of
> the last router facing your openvpn server.
>

Re: OpenVpn Mac Address Filter

[Erwan David]

Le 29/05/2021 à 20:09, Gokan Atmaca a écrit :
> Hello
>
> Can we filter MAC addresses of Openvpn clients ?
>
> Thanks.
>
>
>
Mac address is available only on the local network. You usually do not
get the mac address of the openvpn client but the mac address of nic of
the last router facing your openvpn server.

Re: openvpn --route-up et --route-pre-down

[no way]

Salut,

Il te manque pas le shebang (#!/bin/bash) dans ton script bash ??

On Sat, Jan 2, 2021 at 12:02 AM Jean-Marc  wrote:

> Le 1/01/21 à 18:28, NoSpam a écrit :
> > Perso j'utilise
> >
> > script-security 2
> > up "/etc/openvpn/update-routeAndmask"
> > down "/etc/openvpn/update-routeAndmask"
>
> À peu de chose près, ce que j'ai fait aussi :
> script-security 2
>
> up /etc/openvpn/client/neutrinet/neutrinet-test
>
>
> $ cat /etc/openvpn/client/neutrinet/neutrinet-test
>
> /bin/echo test logging > /tmp/openvpn.log
>
>
> $ cat /tmp/openvpn.log
>
> test logging
>
>
> Ce simple script n'est jamais exécuté quand le client openvpn démarre.
>
> Les dernières lignes du log sont celles-ci :
> [...]
> /etc/openvpn/client/neutrinet/neutrinet-test tun0 1500 1570
> 80.67.181.137 255.255.255.128 init
>
> WARNING: Failed running command (--up/--down): could not execute
> external program
>
> Exiting due to fatal error
>
>
>
>
> --
> Jean-Marc
>
>

Re: openvpn --route-up et --route-pre-down

[Jean-Marc]

Le 1/01/21 à 18:28, NoSpam a écrit :
> Perso j'utilise
> 
> script-security 2
> up "/etc/openvpn/update-routeAndmask"
> down "/etc/openvpn/update-routeAndmask"

À peu de chose près, ce que j'ai fait aussi :
script-security 2

up /etc/openvpn/client/neutrinet/neutrinet-test


$ cat /etc/openvpn/client/neutrinet/neutrinet-test

/bin/echo test logging > /tmp/openvpn.log


$ cat /tmp/openvpn.log

test logging


Ce simple script n'est jamais exécuté quand le client openvpn démarre.

Les dernières lignes du log sont celles-ci :
[...]
/etc/openvpn/client/neutrinet/neutrinet-test tun0 1500 1570
80.67.181.137 255.255.255.128 init

WARNING: Failed running command (--up/--down): could not execute
external program

Exiting due to fatal error




-- 
Jean-Marc



OpenPGP_signature
Description: OpenPGP digital signature

Re: openvpn --route-up et --route-pre-down

[NoSpam]

Bonjour et bonne année à tous

Le 01/01/2021 à 16:09, Jean-Marc a écrit :

salut la liste,

quelqu'un connaît un peu openvpn ?

J'ai un serveur Debian stable avec un client openvpn.

J'essaie sans succès d'appeler 2 scripts pendant l'init de mon vpn.

J'utilise les paramètres route-up et route-pre-down pour ce faire, j'ai,
comme indiqué dans le man, changé la valeur de script-security à 2 pour
permettre l'appel de scripts persos mais ça ne fonctionne pas.

Je me retrouve avec l'erreur suivante :

WARNING: Failed running command (--route-up): could not execute external
program

Si j'exécute les scripts à la main, pas de soucis.

J'ai cherché sur le net mais je n'ai rien trouvé de bien probant.

Toute suggestion bienvenue.

Debian 10.7
Linux 4.19.0-13-armmp #1 SMP Debian 4.19.160-2 (2020-11-28) armv7l GNU/Linux

openvpn 2.4.7-1


Perso j'utilise

script-security 2
up "/etc/openvpn/update-routeAndmask"
down "/etc/openvpn/update-routeAndmask"

--
Daniel

Re: OpenVPN

[Erwan David]

Le 18/03/2020 à 21:12, Damien TOURDE a écrit :
> Bonjour,
> 
> En effet, tap c'est de la propagation de L2, et tun, de L3.
> 
> C'est pas le même usage, mais il faut bien avoir en tête que tout le
> broadcast dans le domaine (de broadcast...), va transiter avec tap.
> De même que tout le reste de l'ARP.
> 
> Sur un gros réseau, ça risque de faire beaucoup d'overhead.
> Pensez aussi à votre Chromecast et votre imprimante qui floodent
> constamment (en multicast et broadcast).
> 
> Sur ces réseaux d'overlay, on est généralement en UDP, mais le TCP est
> aussi possible pour OpenVPN avec l'overhead qui va avec aussi.
> 
> A mon sens, le tun répond a tous les usages courants.
> Et pour le tap, il faut en avoir besoin, mais aussi en comprendre les
> contraintes.
> 
> Pour resumer, le tun c'est du routage classique, le tap c'est du "câble
> VPN".
> 
> 
> PS: je pense également que le multicast ne passe pas au travers d'une
> interface tun, je veux bien un avis sur la question.

Dans mon souvenir, ça passe, mais le multicats routé. Et le routage
multicast c'est assez complexe. Donc ça passe si on fait du pim ou autre
protocole de routage multicast sur l'interface tun, et ça c'est pas
standard du tout

Re: OpenVPN

[Damien TOURDE]

Bonjour,

En effet, tap c'est de la propagation de L2, et tun, de L3.

C'est pas le même usage, mais il faut bien avoir en tête que tout le broadcast 
dans le domaine (de broadcast...), va transiter avec tap.
De même que tout le reste de l'ARP.

Sur un gros réseau, ça risque de faire beaucoup d'overhead.
Pensez aussi à votre Chromecast et votre imprimante qui floodent constamment 
(en multicast et broadcast).

Sur ces réseaux d'overlay, on est généralement en UDP, mais le TCP est aussi 
possible pour OpenVPN avec l'overhead qui va avec aussi.

A mon sens, le tun répond a tous les usages courants.
Et pour le tap, il faut en avoir besoin, mais aussi en comprendre les 
contraintes.

Pour resumer, le tun c'est du routage classique, le tap c'est du "câble VPN".


PS: je pense également que le multicast ne passe pas au travers d'une interface 
tun, je veux bien un avis sur la question.

Cordialement,
Damien TOURDE




Le 17 mars 2020 12:58:48 GMT+01:00, "BERTRAND Joël"  
a écrit :
>NoSpam a écrit :
>> 
>> Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :
>>> David BERCOT a écrit :
 Bonsoir,
>>> Bonjour,
>>>
 En cette période un peu... difficile, je vous propose de revenir
>aux
 fondamentaux, à savoir Debian ;-)

 Bref, je voudrais installer OpenVPN sur mon serveur OVH.
 Après quelques recherches, j'ai trouvé notamment cette
>documentation :
 https://wiki.debian.org/fr/OpenVPN

 Les premières étapes (installation du package et génération de la
>clé
 statique) sont OK mais je ne vois pas bien comment remplir le
>tun0.conf
 et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
 En effet, sauf erreur, la première IP est celle de mon serveur et
>la
 seconde est celle du "client". Mais, dans le subnet, je ne maîtrise
>pas
 du tout les adresses IP et leur utilisation.

 Auriez-vous une piste ?
>>> Utiliser une interface tap ?
>>>
>>> La question est sérieuse, je n'ai jamais compris l'intérêt
>d'utiliser
>>> l'interface tun. tap se comporte comme une réelle interface réseau
>avec
>>> tous les avantages d'ethernet (contrairement à tun qui ne cause
>qu'IP).
>>> On peut donc faire de la tolérance de panne, de l'agrégation et tout
>ce
>>> qui est supporté par ethernet. Mais il faut router soi-même par
>derrière.
>> 
>> tap a l'énorme désavantage de faire passer out le trafic y compris
>arp &
>> co De plus,  si les réseaux connectés gèrent des postes sous Windows,
>la
>> propagation des logiciels malveillants est aisée.
>> 
>> J'ai abandonné tap pour tun depuis quelques mois et les routeurs,
>> commutateurs et autres outils de surveillance me disent merci ;)
>
>Je ne veux pas être bégueule, mais concernant les protocoles à la noix
>Windows, ça se filtre (d'autant plus qu'il y en a un bon paquet qui
>causent IP).

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Re: OpenVPN

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :
>> David BERCOT a écrit :
>>> Bonsoir,
>> Bonjour,
>>
>>> En cette période un peu... difficile, je vous propose de revenir aux
>>> fondamentaux, à savoir Debian ;-)
>>>
>>> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
>>> Après quelques recherches, j'ai trouvé notamment cette documentation :
>>> https://wiki.debian.org/fr/OpenVPN
>>>
>>> Les premières étapes (installation du package et génération de la clé
>>> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
>>> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
>>> En effet, sauf erreur, la première IP est celle de mon serveur et la
>>> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
>>> du tout les adresses IP et leur utilisation.
>>>
>>> Auriez-vous une piste ?
>> Utiliser une interface tap ?
>>
>> La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
>> l'interface tun. tap se comporte comme une réelle interface réseau avec
>> tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
>> On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
>> qui est supporté par ethernet. Mais il faut router soi-même par derrière.
> 
> tap a l'énorme désavantage de faire passer out le trafic y compris arp &
> co De plus,  si les réseaux connectés gèrent des postes sous Windows, la
> propagation des logiciels malveillants est aisée.
> 
> J'ai abandonné tap pour tun depuis quelques mois et les routeurs,
> commutateurs et autres outils de surveillance me disent merci ;)

Je ne veux pas être bégueule, mais concernant les protocoles à la noix
Windows, ça se filtre (d'autant plus qu'il y en a un bon paquet qui
causent IP).

Re: OpenVPN

[NoSpam]

Le 17/03/2020 à 11:32, BERTRAND Joël a écrit :

David BERCOT a écrit :

Bonsoir,

Bonjour,


En cette période un peu... difficile, je vous propose de revenir aux
fondamentaux, à savoir Debian ;-)

Bref, je voudrais installer OpenVPN sur mon serveur OVH.
Après quelques recherches, j'ai trouvé notamment cette documentation :
https://wiki.debian.org/fr/OpenVPN

Les premières étapes (installation du package et génération de la clé
statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
En effet, sauf erreur, la première IP est celle de mon serveur et la
seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
du tout les adresses IP et leur utilisation.

Auriez-vous une piste ?

Utiliser une interface tap ?

La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
l'interface tun. tap se comporte comme une réelle interface réseau avec
tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
qui est supporté par ethernet. Mais il faut router soi-même par derrière.


tap a l'énorme désavantage de faire passer out le trafic y compris arp & 
co De plus,  si les réseaux connectés gèrent des postes sous Windows, la 
propagation des logiciels malveillants est aisée.


J'ai abandonné tap pour tun depuis quelques mois et les routeurs, 
commutateurs et autres outils de surveillance me disent merci ;)


--

Daniel

Re: OpenVPN

[BERTRAND Joël]

David BERCOT a écrit :
> Bonsoir,

Bonjour,

> En cette période un peu... difficile, je vous propose de revenir aux
> fondamentaux, à savoir Debian ;-)
> 
> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
> Après quelques recherches, j'ai trouvé notamment cette documentation :
> https://wiki.debian.org/fr/OpenVPN
> 
> Les premières étapes (installation du package et génération de la clé
> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
> En effet, sauf erreur, la première IP est celle de mon serveur et la
> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
> du tout les adresses IP et leur utilisation.
> 
> Auriez-vous une piste ?

Utiliser une interface tap ?

La question est sérieuse, je n'ai jamais compris l'intérêt d'utiliser
l'interface tun. tap se comporte comme une réelle interface réseau avec
tous les avantages d'ethernet (contrairement à tun qui ne cause qu'IP).
On peut donc faire de la tolérance de panne, de l'agrégation et tout ce
qui est supporté par ethernet. Mais il faut router soi-même par derrière.

Bien cordialement,

JKB

Re: OpenVPN

[Belaïd]

Bonjour,

Ta configuration pour tun0 est correct du moment que ces adresses IP
n'entrent pas en conflit avec les adresses IP du côté serveur (si y'en a).
Tu peux aussi remplacer la ligne ifconfig en question par une ligne du
genre: server 10.8.9.0 255.255.255.0 si tu veux que le serveur VPN puisse
donner/gérer les adresses IP automatiquement aux clients

Le lun. 16 mars 2020 12:04, David BERCOT  a écrit :

> Bonsoir,
>
> En cette période un peu... difficile, je vous propose de revenir aux
> fondamentaux, à savoir Debian ;-)
>
> Bref, je voudrais installer OpenVPN sur mon serveur OVH.
> Après quelques recherches, j'ai trouvé notamment cette documentation :
> https://wiki.debian.org/fr/OpenVPN
>
> Les premières étapes (installation du package et génération de la clé
> statique) sont OK mais je ne vois pas bien comment remplir le tun0.conf
> et notamment la ligne : ifconfig 10.9.8.1 10.9.8.2
> En effet, sauf erreur, la première IP est celle de mon serveur et la
> seconde est celle du "client". Mais, dans le subnet, je ne maîtrise pas
> du tout les adresses IP et leur utilisation.
>
> Auriez-vous une piste ?
>
> Dans l'intervalle, j'ai installé OpenVPN-AS qui marche très bien mais je
> préfère les solutions "propres", purement Debian ;-)
>
> Merci d'avance.
>
> David.
>
>

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 16:41:17 +0100
Paul van der Vlis  wrote:

> Jawel, Networkmanager doet dat.
> 
> > Vandaar dat ik er
> > een link van zou maken die naar een andere dir wijst.
> 
> Het overschrijft dan het file in die ander dir lijkt me.

Of hij zet een file neer ipv die symlink

> > Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
> > met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
> > verwacht-ie natuurlijk niet...
> 
> Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops,
> maar die Freedombox-software gebruikt het nogal intensief dus vandaar.
> 
> En nee, het crashed niet, geeft zelfs geen melding in de logs dat
> schrijven niet kan.

Tsja...

> Ik vond dit overigens nog:
> https://github.com/wknapik/vpnfailsafe

Ja, ik zou dan toch liever m'n eigen scripts gebruiken en policy routing
gebruiken, dan hoef je niet zo moeilijk te doen. Zodra de
tunnel opkomt gewoon een andere routetabel kiezen en die heeft z'n
eigen [ip|nf]tables scripts. Overigens draait openvpn bij hen wel als
root, ik ben daar niet zo'n voorstander van.

Misschien is het handig het eindpunt van de tunnel in /etc/hosts te
zetten, als de DNS het een keer om wat voor reden het niet doet kun je
wel een tunnel opbouwen.

Maar waarom draai je niet unbound die direct de rootservers benadert?
Zo vindt de provider het niet in de logs van de DNS, maar met een dump
kun je altijd zien wat er gevraagd wordt, maar dat zie je aan het eind
van de tunnel ook. Dus wat win je ermee?

Overigens is dat ge-VPN ook maar een hype. Mensen denken dat ze veilig
zitten. Maar wie garandeert dat? Zonder vpn ziet je provider het, met
een vpn ziet de vpn aanbieder het. Een vpn is niets meer dan een
virtueel stuk draad die je ergens in een switch steekt.

Als je iets wilt uitvreten gebruik dan Tor. En dan nog.

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 14:07 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 13:35:55 +0100
> Paul van der Vlis  wrote:
> 
> Dat is wel erg bot. 
>>
>> Het is bot, maar geeft niet eens een foutmelding in de logs.
>> En wat is er erg aan bot?
> 
> Nou, zelfs root krijgt dan een permission denied, en als resolvconf
> verwijderd is zou niemand er meer aan mogen zitten. 

Jawel, Networkmanager doet dat.

> Vandaar dat ik er
> een link van zou maken die naar een andere dir wijst.

Het overschrijft dan het file in die ander dir lijkt me.

>>> ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf
>>
>> Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
>> zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In
>> de praktijk doet hij dat niet, maar als de andere uitvalt wel.
> 
> Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
> met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
> verwacht-ie natuurlijk niet...

Inderdaad, dat ding bedoel ik. Gebruik ik normaal alleen op laptops,
maar die Freedombox-software gebruikt het nogal intensief dus vandaar.

En nee, het crashed niet, geeft zelfs geen melding in de logs dat
schrijven niet kan.

>>> Ja ok, het gaat dus niet om security maar om het verbergen van
>>> illegale activiteiten :-)
>>
>> Een vertrouwde DNS server willen gebruiken is ook security.
> 
> Maar ook van die resolver kun je volgen wat-ie opvraagt...
> 
>> Er zijn vele mensen die een VPN willen gebruiken om verschillende
>> redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
>> opgelost, maar op de commandline gaat het niet goed.
> 
> Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"?

Goed mogelijk...

Ik vond dit overigens nog:
https://github.com/wknapik/vpnfailsafe

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 13:35:55 +0100
Paul van der Vlis  wrote:

> >>> Dat is wel erg bot. 
> 
> Het is bot, maar geeft niet eens een foutmelding in de logs.
> En wat is er erg aan bot?

Nou, zelfs root krijgt dan een permission denied, en als resolvconf
verwijderd is zou niemand er meer aan mogen zitten. Vandaar dat ik er
een link van zou maken die naar een andere dir wijst.

> > ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf
> 
> Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
> zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In
> de praktijk doet hij dat niet, maar als de andere uitvalt wel.

Brr, dat ding. Networkdestroyer bedoel je. Maar als je de boel
met chattr te lijf gaat, crasht dat ding dan niet? Want zoiets
verwacht-ie natuurlijk niet...

> > Ja ok, het gaat dus niet om security maar om het verbergen van
> > illegale activiteiten :-)
> 
> Een vertrouwde DNS server willen gebruiken is ook security.

Maar ook van die resolver kun je volgen wat-ie opvraagt...

> Er zijn vele mensen die een VPN willen gebruiken om verschillende
> redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
> opgelost, maar op de commandline gaat het niet goed.

Huh? Dat lijkt me onlogisch. Of heeft Poettering weer iets "gefixt"?

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 13:18 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 12:11:37 +0100
> Paul van der Vlis  wrote:
> 
>>> Dat is wel erg bot. 

Het is bot, maar geeft niet eens een foutmelding in de logs.
En wat is er erg aan bot?

> Je kunt openvpn ook de resolv.conf laten
>>> aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb
>>> je sudo voor nodig.
>>
>> Heb je daar een mooi scriptje voor?
> 
> Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of
> policy routing aan te sturen, maar dat hoeft alleen maar bij het "up"
> komen van het device want als het device verdwijnt ruimt de kernel de
> bijbehorende routes op.
> 
> In de config:
> 
> up /path/to/script start
> down /path/to/script stop
> 
> Het "up" script draait als "root", maar bij "down" moet je wel sudo
> gebruiken omdat de tunnel default dan onder de user nobody draait (ik
> zou daar een aparte user voor nemen iig)
> 
> Je zou simpelweg een
> 
> /etc/openvpn/resolv/resolv-ovpn.conf
> /etc/openvpn/resolv/resolv-default.conf
> 
> kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die
> writable is voor de user openvpn) een "ln -sf  resolv.conf" op
> kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak
> je als root in de /etc/ dir een link naar
> 
> ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf

Networkmanager heeft de neiging om /etc/resolv.conf te veranderen. Het
zet er bij IPv6 een lokale nameserver bij die DNS-leaks kan geven. In de
praktijk doet hij dat niet, maar als de andere uitvalt wel.

>>> En je vertrouwt de DNS aan de andere kant van de tunnel wel?
>>
>> Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
>> naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
>> rechtsstreeks bij de root-servers navraagt.
> 
> Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat
> terzijde.
> 
>>> Verplaats je niet gewoon het probleem?
>>
>> Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
>> kan de ISP niet meer zien wat voor naam je resolved.
>>
>> En als er een andere nameserver gebruikt zou worden dan ziet die ook
>> alleen het IP van de VPN.
> 
> Ja ok, het gaat dus niet om security maar om het verbergen van illegale
> activiteiten :-)

Een vertrouwde DNS server willen gebruiken is ook security.

Er zijn vele mensen die een VPN willen gebruiken om verschillende
redenen, en dat DNS-leak ergerde mij.  In de GUI clients schijnt het
opgelost, maar op de commandline gaat het niet goed.

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 12:11:37 +0100
Paul van der Vlis  wrote:

> > Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten
> > aanpassen, up is niet zo'n probleem (dan is-ie nog root), down heb
> > je sudo voor nodig.
> 
> Heb je daar een mooi scriptje voor?

Nee, ik gebruik die optie nooit, alhoewel ja, om routes toe te voegen of
policy routing aan te sturen, maar dat hoeft alleen maar bij het "up"
komen van het device want als het device verdwijnt ruimt de kernel de
bijbehorende routes op.

In de config:

up /path/to/script start
down /path/to/script stop

Het "up" script draait als "root", maar bij "down" moet je wel sudo
gebruiken omdat de tunnel default dan onder de user nobody draait (ik
zou daar een aparte user voor nemen iig)

Je zou simpelweg een

/etc/openvpn/resolv/resolv-ovpn.conf
/etc/openvpn/resolv/resolv-default.conf

kunnen aanmaken en daar in die specifieke dir /etc/openvpn/resolv (die
writable is voor de user openvpn) een "ln -sf  resolv.conf" op
kunnen loslaten door dat script dat openvpn aanstuurt. En dan maak
je als root in de /etc/ dir een link naar

ln -s /etc/openvpn/resolv/resolv.conf /etc/resolv.conf

> > En je vertrouwt de DNS aan de andere kant van de tunnel wel?
> 
> Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
> naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
> rechtsstreeks bij de root-servers navraagt.

Ik zou unbound gebruiken, dat is een recursive only resolver. Maar dat
terzijde.

> > Verplaats je niet gewoon het probleem?
> 
> Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
> kan de ISP niet meer zien wat voor naam je resolved.
> 
> En als er een andere nameserver gebruikt zou worden dan ziet die ook
> alleen het IP van de VPN.

Ja ok, het gaat dus niet om security maar om het verbergen van illegale
activiteiten :-)

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 26-02-2020 om 11:39 schreef Richard Lucassen:
> On Wed, 26 Feb 2020 11:27:18 +0100
> Paul van der Vlis  wrote:
> 
>> Wat ik uiteindelijk maar heb gedaan is het volgende:
>> Ik heb resolvconf verwijderd.
>> Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
>> chattr +i /etc/resolv.conf
> 
> Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen,
> up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor
> nodig.

Heb je daar een mooi scriptje voor?

>> Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal
>> wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.
>>
>> Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .
> 
> En je vertrouwt de DNS aan de andere kant van de tunnel wel?

Dat is mijn eigen DNS-server. Op het moment nog DNSmasq die verwijst
naar mijn eigen DNS-servers maar ik wil er Bind9 van maken wat
rechtsstreeks bij de root-servers navraagt.

> Verplaats je niet gewoon het probleem?

Iemand wil vaak een VPN omdat hij films download o.i.d. Op deze manier
kan de ISP niet meer zien wat voor naam je resolved.

En als er een andere nameserver gebruikt zou worden dan ziet die ook
alleen het IP van de VPN.

Groeten,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: OpenVPN en "dns leakage"

[Richard Lucassen]

On Wed, 26 Feb 2020 11:27:18 +0100
Paul van der Vlis  wrote:

> Wat ik uiteindelijk maar heb gedaan is het volgende:
> Ik heb resolvconf verwijderd.
> Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
> chattr +i /etc/resolv.conf

Dat is wel erg bot. Je kunt openvpn ook de resolv.conf laten aanpassen,
up is niet zo'n probleem (dan is-ie nog root), down heb je sudo voor
nodig.

> Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal
> wat ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.
> 
> Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .

En je vertrouwt de DNS aan de andere kant van de tunnel wel? Verplaats
je niet gewoon het probleem?

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: OpenVPN en "dns leakage"

[Paul van der Vlis]

Op 24-02-2020 om 18:50 schreef Paul van der Vlis:
> Hoi,
> 
> Ik probeer OpenVPN zo op te zetten dat er geen "dns leakage" is.
> 
> Als ik de VPN start dan wordt netjes de dns gewijzigd in
> /etc/resolv.conf door update-resolv-conf. Echter, er wordt hier alleen
> een DNS toegevoegd, de oude is er ook nog. Ik wil dat alleen de DNS
> wordt gebruikt die door OpenVPN wordt gepushed.
> 
> Heeft iemand hier een mooie CLI oplossing voor?
> 
> Het gaat om een Freedombox, dit gebruikt networkmanager en firewalld.
> Ik heb "resolvconf" geinstalleerd om update-resolv-conf werkend te
> krijgen, dit was niet standaard geinstalleerd.

Wat ik uiteindelijk maar heb gedaan is het volgende:
Ik heb resolvconf verwijderd.
Ik heb /etc/resolv.conf niet te wijzigen gemaakt met:
chattr +i /etc/resolv.conf

Tja, nu is alleen de nameserver wel statisch geworden, niet helemaal wat
ik wou. Ik gebruik het VPN-IP van VPN-server als nameserver.

Geen DNS leakage meer volgens https://www.dnsleaktest.com/ .

Groet,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn-systemd-resolved vs gui

[Andrea Borgia]

Il 02/09/19 19:52, john doe ha scritto:


Those messages are error messages, if I were you I would put the missing
file 'scripts/update-systemd-resolved' in the directory
'/etc/openvpn/scripts' or look in your openvpn config file for the '--up
script' directive.


They sure behave like warnings, though: the bulk of traffic goes through 
the vpn interface ;)


Anyhow, given the sheer amount of those errors it looks like I've been 
bitten by this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933987


I moved the script from /etc/openvpn to /etc/openvpn/scripts and now I 
get a different error:
ovpn-update-systemd-resolved[6820]: disabling NCP mode (--ncp-disable) 
because not in P2MP client or server mode


Next, I saw the dependency from openvpn was just "Suggest" so I removed 
it altogether and now there are no errors. I will note in the system log 
this thread and for the moment I'll leave it at that.


Thanks for your help.

Re: openvpn-systemd-resolved vs gui

[john doe]

On 9/2/2019 7:08 PM, Andrea Borgia wrote:
> Il 01/09/19 19:09, john doe ha scritto:
>
>
>
>>> After seeing some warnings in the system logs, I decided to
>>> investigate and
>> It would help if we could see those warnings as well.
>
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Service RestartSec=5s expired,
> scheduling restart.
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Scheduled restart job, restart
> counter is at 266.
> Sep  2 16:59:40 clarisse systemd[1]: Stopped OpenVPN connection to
> update-systemd-resolved.
> Sep  2 16:59:40 clarisse systemd[1]: Starting OpenVPN connection to
> update-systemd-resolved...
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
> error: --up script fails with
> '/etc/openvpn/scripts/update-systemd-resolved': No such file or
> directory (errno=2)
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
> error: Please correct this error.
> Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Use --help
> for more information.
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Main process exited,
> code=exited, status=1/FAILURE
> Sep  2 16:59:40 clarisse systemd[1]:
> openvpn@update-systemd-resolved.service: Failed with result 'exit-code'.
> Sep  2 16:59:40 clarisse systemd[1]: Failed to start OpenVPN connection
> to update-systemd-resolved.
>
>
>
>>> found out that I am supposed to enable this script to integrate the dns
>> Which script are you refering to?
>
> In package openvpn-systemd-resolved, there is a config file which also
> installed under /etc/openvpn. This config references a script to be
> installed as /etc/openvpn/scripts/update-systemd-resolved
>
>
>
>>> Do I really have to do it if I am not worried about dns leaks? I'm
>>> actually
>>> ok with using whatever server the local network has, as long as the
>>> traffic
>>> itself is encrypted I'm fine.
>> If you are happy with how things are working, that is up to you to
>> ignore the warnings.
>> In my view, warnings are to be dealt with! :)
>
> Once I am sure I understand the implications, ignoring them is not a bad
> idea. That said, my main concern was integrating the config with the n-m
> gui... now that I think about it, the warnings are proof that this is a
> non-issue :)
>
>

From your logs above:

"Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
error: --up script fails with
'/etc/openvpn/scripts/update-systemd-resolved': No such file or
directory (errno=2)
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options
error: Please correct this error."


Those messages are error messages, if I were you I would put the missing
file 'scripts/update-systemd-resolved' in the directory
'/etc/openvpn/scripts' or look in your openvpn config file for the '--up
script' directive.

--
John Doe

Re: openvpn-systemd-resolved vs gui

[Andrea Borgia]

Il 01/09/19 19:09, john doe ha scritto:




After seeing some warnings in the system logs, I decided to investigate and

It would help if we could see those warnings as well.


Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Service RestartSec=5s expired, 
scheduling restart.
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Scheduled restart job, restart 
counter is at 266.
Sep  2 16:59:40 clarisse systemd[1]: Stopped OpenVPN connection to 
update-systemd-resolved.
Sep  2 16:59:40 clarisse systemd[1]: Starting OpenVPN connection to 
update-systemd-resolved...
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options 
error: --up script fails with 
'/etc/openvpn/scripts/update-systemd-resolved': No such file or 
directory (errno=2)
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Options 
error: Please correct this error.
Sep  2 16:59:40 clarisse ovpn-update-systemd-resolved[12327]: Use --help 
for more information.
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Main process exited, 
code=exited, status=1/FAILURE
Sep  2 16:59:40 clarisse systemd[1]: 
openvpn@update-systemd-resolved.service: Failed with result 'exit-code'.
Sep  2 16:59:40 clarisse systemd[1]: Failed to start OpenVPN connection 
to update-systemd-resolved.





found out that I am supposed to enable this script to integrate the dns

Which script are you refering to?


In package openvpn-systemd-resolved, there is a config file which also 
installed under /etc/openvpn. This config references a script to be 
installed as /etc/openvpn/scripts/update-systemd-resolved





Do I really have to do it if I am not worried about dns leaks? I'm actually
ok with using whatever server the local network has, as long as the traffic
itself is encrypted I'm fine.

If you are happy with how things are working, that is up to you to
ignore the warnings.
In my view, warnings are to be dealt with! :)


Once I am sure I understand the implications, ignoring them is not a bad 
idea. That said, my main concern was integrating the config with the n-m 
gui... now that I think about it, the warnings are proof that this is a 
non-issue :)



Thanks,
Andrea.

Re: openvpn-systemd-resolved vs gui

[john doe]

On 9/1/2019 6:33 PM, Andrea Borgia wrote:
> Hi.
>
> After seeing some warnings in the system logs, I decided to investigate and

It would help if we could see those warnings as well.

> found out that I am supposed to enable this script to integrate the dns

Which script are you refering to?

> information supplied from the server into the local configuration.
>
> Do I really have to do it if I am not worried about dns leaks? I'm actually
> ok with using whatever server the local network has, as long as the traffic
> itself is encrypted I'm fine.
>

If you are happy with how things are working, that is up to you to
ignore the warnings.
In my view, warnings are to be dealt with! :)

--
John Doe

Re: openvpn privatvpn

[Daniel Huhardeaux]

Le 12/07/2019 à 06:02, Daniel Caillibaud a écrit :

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :

Une analyse par Wireshark indique seulement que les DNS ne
fonctionnent pas.


Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)


Attention si c'est systemd-resolved qui gère le DNS la valeur 127.0.0.1 
est à mettre dans /etc/systemd/resolved cle [Resolve] => DNS


--
Daniel

Re: openvpn privatvpn

[Daniel Caillibaud]

Le 11/07/19 à 18h50, MERLIN Philippe  a
écrit :
> Une analyse par Wireshark indique seulement que les DNS ne
> fonctionnent pas.

Je ne connais pas l'origine du pb, mais tu peux installer un resolver
local, c'est très léger et ça rend pas mal de services (ça évite les dns
parfois menteurs des FAI, mais surtout ça marche toujours alors que
suivant les FAI la résolution dns laisse parfois à désirer, et en prime tu
va gagner un poil en perfs).

apt install unbound

et dans /etc/resolv.conf mettre
nameserver 127.0.0.1

(ou bien l'indiquer dans le network manager, ou ton système de gestion de
la résolution locale)



-- 
Daniel

La mode est ce que l’on porte. 
Ce qui est démodé, c’est ce que portent les autres.
Oscar Wilde

Re: openvpn privatvpn

[MERLIN Philippe]

Le jeudi 11 juillet 2019, 19:20:06 CEST Daniel Huhardeaux a écrit :
> Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :
> > Bonsoir,
> 
> Bonsoir
> 
> > Je suis confronté à un problème surprenant et j'ai besoin d'aides pour
> > essayer de  le résoudre.
> > Sur mon ordinateur système Debian AMD 64 je lance un script en étant root
> > pour activer un VPN privatVPN cette procédure fonctionne parfaitement à
> > Paris ou je suis connecté à une Freebox Mini 4K mais par contre ne
> > fonctionne pas aux environs de Royan connecté à une Freebox V5. Aucun
> > message d'erreur au lancement de la procédure mais je me retrouve sans
> > réseau. Une analyse par Wireshark indique seulement que les DNS ne
> > fonctionnent pas.
> > Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
> > A l'avance merci pour votre aide.
> > Philippe Merlin
> 
> Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également
> le status.
Merci pour ta réponse, malheureusement je n'arrive pas à les interpréter à vue 
de nez je ne vois pas d'erreur, n'étant pas un spécialiste réseau . Si 
quelqu'un peut se pencher sur les petits fichiers qui ont été créés à cette 
occasion, je ne peux les mettre en pj car elles ne seront pas acceptées par la 
liste. Je les enverrai personnellement.
Philippe Merlin

Re: openvpn privatvpn

[Daniel Huhardeaux]

Le 11/07/2019 à 18:50, MERLIN Philippe a écrit :

Bonsoir,


Bonsoir


Je suis confronté à un problème surprenant et j'ai besoin d'aides pour essayer
de  le résoudre.
Sur mon ordinateur système Debian AMD 64 je lance un script en étant root pour
activer un VPN privatVPN cette procédure fonctionne parfaitement à Paris ou je
suis connecté à une Freebox Mini 4K mais par contre ne fonctionne pas aux
environs de Royan connecté à une Freebox V5. Aucun message d'erreur au
lancement de la procédure mais je me retrouve sans réseau. Une analyse par
Wireshark indique seulement que les DNS ne fonctionnent pas.
Le script lancé est simple : openvpn /xx/xx/privatvpn.conf
A l'avance merci pour votre aide.
Philippe Merlin



Mettre le mode verbose 8 par ex. et regarder les logs. Loguer également 
le status.


--
Daniel

Re: Openvpn cli vs. Openvpn Networkmanager

[Reco]

Hi.

On Wed, May 29, 2019 at 03:22:34PM +0200, basti wrote:
> Then I setup it with networkmanger the connection is established, but
> resolv.conf looks different with the result that i cant resolve hosts on
> the other site of vpn.
> 
> cat /etc/resolv.conf
> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
> resolvconf(8)
> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
> nameserver 192.168.0.1<-- local
> nameserver 192.168.30.2   <-- from VPN
> nameserver 192.168.30.6   <-- from VPN
> search my.localdomain.com localdomain.com vpn vpn.example.com
> 
> Is there a way to fix this?

You could try. The order of "nameserver" entries in /etc/resolv.conf are
defined by IFACE.PROG entries passed to resolvconf, which consults
/etc/resolvconf/interface-order .
Look for whatever Notwork Manager added to /run/resolvconf/interfaces
for openvpn, add it at the top of interface-order.

Reco

Re: Openvpn with brainpoolP256r1 works for debian clients only

[Dan Ritter]

Dominik wrote: 
> Hi all,
> 
> I'm using openvpn with certificates based on elliptic curves form the
> brainpoolP256r1 group. This works fine if the server and the clients run
> with debian as operating system.
> 
> If I try to connect with a client based on windows or centos using the
> same client.conf, the handshake fails and the server logs show the
> following:
> 
> TLS error: The server has no TLS ciphersuites in common with the client.
> Your --tls-cipher setting might be too restrictive.
> 
> If I compare the ClientHello messages, the client in debian lists the
> brainpoolP256r1 in the Supported Group section, while the client on
> windows and centos do not. (See below).
> 
> My question:
> 
> Why does debian send this extended list of supported groups compared to
> the other operating systems? Are there special compile options for
> openvpn or openssl?

There are many different options, and openssl tries to support
many so that something can be found to work.

Incompatibility across operating systems and versions is
expected. Pick something that works for your situation.

-dsr-

Re: openvpn fails to run a learn-address script

[Dominik]

On 27.02.19 14:37, Curt wrote:

On 2019-02-27, Dominik  wrote:

I'm looking for help related to three questions:

1) How do I get additional information about what is causing the error?
Why is systemd blocking sudo despite the modifications in the override.conf

2) More generally: How can I run openvpn in a daemon as user vpn with
the ability to use sudo in a learn-address-script?

3) Would it be appropriate to file a bug report against systemd at this
stage?

Thanks in advance,

kind regards

Dominik


I can't grok your /etc/systemd/system/openvpn@.service.d/override.conf
file.


Sorry, this was a mistake. The override.conf I used are

version 1:


ProtectSystem=yes
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE
CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE
CAP_AUDIT_WRITE


version 2:


ProtectSystem=no
CapabilityBoundingSet=~
My understanding is that for this workaround it should contain something like:

  Service]
  CapabilityBoundingSet=CAP_AUDIT_WRITE

Another approach is to run

  systemctl editopenvpn@.service

and in your $EDITOR write and save the same, i.e.

  [Service]
  CapabilityBoundingSet=CAP_AUDIT_WRITE

Apparently "CapabilityBoundingSet=" (empty) also works.

If that's what you've already done or I've misunderstood any or everything,
sorry, mate.



Thanks for pointing this out. My mistake was the missing [Service]

Greetings

Dominik

Re: openvpn fails to run a learn-address script

[Curt]

On 2019-02-27, Dominik  wrote:
>
> I'm looking for help related to three questions:
>
> 1) How do I get additional information about what is causing the error?
> Why is systemd blocking sudo despite the modifications in the override.conf
>
> 2) More generally: How can I run openvpn in a daemon as user vpn with
> the ability to use sudo in a learn-address-script?
>
> 3) Would it be appropriate to file a bug report against systemd at this
> stage?
>
> Thanks in advance,
>
> kind regards
>
> Dominik
>

I can't grok your /etc/systemd/system/openvpn@.service.d/override.conf 
file.

My understanding is that for this workaround it should contain something like:

 Service]
 CapabilityBoundingSet=CAP_AUDIT_WRITE

Another approach is to run

 systemctl edit openvpn@.service

and in your $EDITOR write and save the same, i.e.

 [Service]
 CapabilityBoundingSet=CAP_AUDIT_WRITE

Apparently "CapabilityBoundingSet=" (empty) also works.

If that's what you've already done or I've misunderstood any or everything,
sorry, mate.

-- 
When you have fever you are heavy and light, you are small and swollen, you
climb endlessly a ladder which turns like a wheel. 
Jean Rhys, Voyage in the Dark

Re: OpenVPN. Certificat ca.crt expiré. Comment éviter une redistribution de ca.crt

[Daniel Huhardeaux]

Le 28/01/2019 à 12:28, Olivier a écrit :

Bonjour,


Bonjour

[...]


2. Avez-vous mis en place une procédure particulière pour éviter ce 
genre de contre-temps ?


Reverse ssh
--
Daniel

Re: openvpn

[Paul van der Vlis]

Op 06-01-19 om 12:24 schreef Fred:

>> Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met
>> "default". Dat is je default gateway.
> Dat is dus het adres van mijn router..

Dan gaat het overige verkeer niet via de VPN.

Als je echter je Pi wilt benaderen kun je een IP als 10.8.0.1 gebruiken,
dat verkeer gaat wel via de VPN. Ook kun je je Pi zo configureren dat
hij als router kan fungeren naar b.v. apparaten in je lokale netwerk.

>> "ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb
>> wel gehad dat ipv6 een andere gateway had dan IPv4.
>>
>> Je zult weinig last hebben van de VPN als alleen verkeer naar jouw
>> apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten
>> en alleen als nodig aan, zoals boven beschreven.
>>
>>> Is er overigens ook nog een mogelijkheid om te testen of de vpn
>>> betrouwbaar werkt..?
>> Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel
>> merken. Misschien begrijp ik je vraag niet helemaal goed.
> Eigenlijk doelde ik op bijv. een site (whatismyipaddress) die het
> gebruikte ip-adres laat zien.
> Deze geeft trouwens wel het ipv6 adres terug...

Nu zul je je gewone IP zien.

Als je al je verkeer via de VPN wilt sturen zul je de boel iets anders
moeten configureren. Maar dat kan ook. Je ziet dan het IP van de Pi,
waarschijnlijk dus je IP thuis.

>> Er zullen echter plekken zijn waar het niet werkt, omdat men daar de
>> poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en
>> 443 TCP doorlaat. Sommige gastnetwerken doen dat.
> Het valt mij al op dat er vanaf de laptop met de kabel al veel sites
> zijn die niet weer gegeven worden.
> Maar dit kan natuurlijk toeval zijn.

Ik denk dat je bij dat soort sites helemaal niet werkt via de VPN, en
dat het dus toeval is moet zijn.

>> Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de
>> VPN. Je kunt er dus niet opkomen als de VPN niet zou werken.
>> Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal.
> Ok, iptables oid..? Weer iets uit te zoeken ;-)

Inderdaad, iptables. Al heb je tegenwoordig ook iets nieuws.

Verder port-forwarding op je router naar je Pi van poort 1194 UDP.

Groeten,
Paul




-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Fred]

Op 05-01-19 om 22:36 schreef Paul van der Vlis:

Op 05-01-19 om 20:36 schreef Fred:> Op 03-01-19 om 20:42 schreef Paul
van der Vlis:

Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/  zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.

Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".

Dit werkt inderdaad.
In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds
door de vpn server heen.
Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?

Default gaat alleen dataverkeer naar je eigen apparatuur door de VPN en
ander internetverkeer niet. Waarom denk je dat al het verkeer door de
VPN gaat?
Vermoedelijk door een gebrek aan kennis en door de veronderstelling dat 
je juist in het netwerkbeheer van Gnome de VPN uit kan zetten wanneer je 
VPN niet nodig acht. Andersom ging ik er dus vanuit dat als je VPN niet 
uit zet dat alle verkeer dus door de VPN gaat. Met alle verkeer bedoel 
ik ook een bericht zoals deze.

Maar zoals ik al begon; ... een gebrek aan kennis.

Er zijn wel mogelijkheden dit te veranderen met het commando
"redirect-gateway" maar dat zag ik niet in je configfile.

Mijn ervaring met NetworkManagers OpenVPN-plugin is, dat het daar anders
is, dat implementeerd OpenVPN niet correct naar mijn mening! (getest met
de versie uit Debian Stable). Het default is daar dat al het verkeer via
de VPN gaat, tenzij je dit wijzigt.

Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met
"default". Dat is je default gateway.

Dat is dus het adres van mijn router..


"ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb
wel gehad dat ipv6 een andere gateway had dan IPv4.

Je zult weinig last hebben van de VPN als alleen verkeer naar jouw
apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten
en alleen als nodig aan, zoals boven beschreven.


Is er overigens ook nog een mogelijkheid om te testen of de vpn
betrouwbaar werkt..?

Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel
merken. Misschien begrijp ik je vraag niet helemaal goed.
Eigenlijk doelde ik op bijv. een site (whatismyipaddress) die het 
gebruikte ip-adres laat zien.

Deze geeft trouwens wel het ipv6 adres terug...

Er zullen echter plekken zijn waar het niet werkt, omdat men daar de
poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en
443 TCP doorlaat. Sommige gastnetwerken doen dat.
Het valt mij al op dat er vanaf de laptop met de kabel al veel sites 
zijn die niet weer gegeven worden.

Maar dit kan natuurlijk toeval zijn.


Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de
VPN. Je kunt er dus niet opkomen als de VPN niet zou werken.
Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal.

Ok, iptables oid..? Weer iets uit te zoeken ;-)

Gr Fred

Re: openvpn

[Paul van der Vlis]

Op 05-01-19 om 20:36 schreef Fred:> Op 03-01-19 om 20:42 schreef Paul
van der Vlis:
>> Je zou het ook zonder de network-manager plugin kunnen doen.
>> Gewoon het configfile in /etc/openvpn/  zetten en renamen (.ovpn moet
>> .conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
>> als er een netwerkverbinding is.
>>
>> Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
>> hand starten ("openvpn --config /path/configfile".
> Dit werkt inderdaad.
> In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds
> door de vpn server heen.
> Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?

Default gaat alleen dataverkeer naar je eigen apparatuur door de VPN en
ander internetverkeer niet. Waarom denk je dat al het verkeer door de
VPN gaat?

Er zijn wel mogelijkheden dit te veranderen met het commando
"redirect-gateway" maar dat zag ik niet in je configfile.

Mijn ervaring met NetworkManagers OpenVPN-plugin is, dat het daar anders
is, dat implementeerd OpenVPN niet correct naar mijn mening! (getest met
de versie uit Debian Stable). Het default is daar dat al het verkeer via
de VPN gaat, tenzij je dit wijzigt.

Geef eens "ip r" terwijl je VPN open is, en kijk naar de regel met
"default". Dat is je default gateway.

"ip -6 r" is interessant voor IPv6, als er IPv6 is gaat dat voor. Ik heb
wel gehad dat ipv6 een andere gateway had dan IPv4.

Je zult weinig last hebben van de VPN als alleen verkeer naar jouw
apparatuur er door gaat. Maar je kunt de VPN ook default niet aanzetten
en alleen als nodig aan, zoals boven beschreven.

> Is er overigens ook nog een mogelijkheid om te testen of de vpn
> betrouwbaar werkt..?
Mijn ervaring is dat het betrouwbaar werkt, maar dat zul je zelf wel
merken. Misschien begrijp ik je vraag niet helemaal goed.

Er zullen echter plekken zijn waar het niet werkt, omdat men daar de
poort waarop OpenVPN werkt blokkeert en bijvoorbeeld alleen poort 80 en
443 TCP doorlaat. Sommige gastnetwerken doen dat.

Verder lijkt me dat je op je Pi de poorten dichtzet, behalve die van de
VPN. Je kunt er dus niet opkomen als de VPN niet zou werken.
Overweeg dat niet alleen tegenover internet te doen, maar ook lokaal.

Groet,
Paul



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Fred]

Op 03-01-19 om 20:42 schreef Paul van der Vlis:


Op 03-01-19 om 19:45 schreef Fred:


Op 03-01-19 om 19:01 schreef Paul van der Vlis:

Op 03-01-19 om 17:45 schreef Fred:

Op 03-01-19 om 17:39 schreef Paul van der Vlis:

Op 03-01-19 om 15:05 schreef Fred:

Op 02-01-19 om 20:53 schreef Paul van der Vlis:

Hoi,

Op 02-01-19 om 20:00 schreef Fred:

Beste,

Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
mijn mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.

Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder
van
Gnome geïmporteerd echter met uitzondering van het 
gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
toevoegen.

Bedoel je wellicht het  gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.

Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;


#
#
# 2048 bit OpenVPN static key
#
#-BEGIN OpenVPN Static key V1-

Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
regels van n comment out # heb voorzien wel.
Het gaat volgens mij dus wel om  i,p,v  (?)

Maar in jou methode om een .opvn bestand te genereren zie ik juist die
tag niet terug.
Wellicht dat dat juist het probleem is. De log verwijst in elk
geval wel
naar een tls issue.

Ik zie dus zoiets en dat werkt:


#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-

(...)

-END OpenVPN Static key V1-



Probeer het misschien eens aan te passen.

Dat heb ik juist geprobeerd maar levert ook niet het gewenste
resultaat op;
De log laat dan dit zien;
Jan  3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
packet authentication failed
Jan  3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
unwrapping failed from [AF_INET]

Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
kunnen dat networkmanager in Debian het nog niet ondersteund.
Hmm, ik zie dat er ook een backports-versie van is.

Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
require the user to set --key-direction."

Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.

Networkmanager importeert alles nu netjes?

Ja, als ik  van   maak dan wordt het ovpn config
bestand wel geïmporteerd, maar wel geeft dus toch in de log van de
server een foutmelding zoals hierboven. Het bestand word ook
geïmporteerd als ik de  regels out comment.

Wat staat er op de tls-auth regel in je client-configfile?
Bij mij staat er dit:
tls-auth ta.key 1

Die komt in mijn client-configfile niet voor.

-
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_KLsSwJCOaYqwbKIp name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
---
En hierna de certificaten en keys...

Ik heb op de client dit, daarna de certificaten en keys:
---
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
-

Volgens mij verschilt de cipher en heb jij "auth" waar ik "tls-auth"
heb, en dan de "direction".


Dit staat er bij mij in het server configfile:
tls-auth /etc/openvpn/keys/ta.key 0
Let op die laatste 0 en 1, dat is de direction.

Bij mij;
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key

Dus zonder toevoeging van 0 of 1

Bovenstaande regel lijkt me geschikt voor tls-crypt en niet voor tls-auth.

Je zult moeten kiezen tussen tls-auth en tls-crypt.
Met dat laatste heb ik nog geen ervaring.
En of de network-manager openvpn plugin daarmee werkt weet ik niet.

Je zou het ook eerst zonder tls-crypt of tls-auth aan de praat kunnen
brengen om te zien of het dan werkt.

Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/  zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.

Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".

Dit werkt inderdaad.
In tegenstelling tot de optie met de netwerkmanager moet/ga ik nu steeds 
door de vpn server heen.

Wellicht is dat geen probleem, maar is hier nog een alternatief voor..?
Is er overigens ook nog een mogelijkheid om te testen of de vpn 
betrouwbaar werkt..?


Gr Fred

Re: openvpn

[Paul van der Vlis]

Op 03-01-19 om 19:45 schreef Fred:
> 
> 
> Op 03-01-19 om 19:01 schreef Paul van der Vlis:
>> Op 03-01-19 om 17:45 schreef Fred:
>>>
>>> Op 03-01-19 om 17:39 schreef Paul van der Vlis:
 Op 03-01-19 om 15:05 schreef Fred:
> Op 02-01-19 om 20:53 schreef Paul van der Vlis:
>> Hoi,
>>
>> Op 02-01-19 om 20:00 schreef Fred:
>>> Beste,
>>>
>>> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
>>> mijn mobiel een verbinding kan krijgen.
>>> Vanaf mijn laptop lukt dit echter niet.
>>>
>>> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder
>>> van
>>> Gnome geïmporteerd echter met uitzondering van het 
>>> gedeelte.
>>> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
>>> toevoegen.
>> Bedoel je wellicht het  gedeelte?
>> Als je dat op de server hebt, moet je het ook op de client hebben.
>> Je kunt het dus ook weghalen aan zowel de server als de client kant.
> Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;
>
>> #
>> #
>> # 2048 bit OpenVPN static key
>> #
>> #-BEGIN OpenVPN Static key V1-
> Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
> regels van n comment out # heb voorzien wel.
> Het gaat volgens mij dus wel om  i,p,v  (?)
>
> Maar in jou methode om een .opvn bestand te genereren zie ik juist die
> tag niet terug.
> Wellicht dat dat juist het probleem is. De log verwijst in elk
> geval wel
> naar een tls issue.
 Ik zie dus zoiets en dat werkt:
 
 
 #
 # 2048 bit OpenVPN static key
 #
 -BEGIN OpenVPN Static key V1-

 (...)

 -END OpenVPN Static key V1-
 
 

 Probeer het misschien eens aan te passen.
>>> Dat heb ik juist geprobeerd maar levert ook niet het gewenste
>>> resultaat op;
>>> De log laat dan dit zien;
>>> Jan  3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
>>> packet authentication failed
>>> Jan  3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
>>> unwrapping failed from [AF_INET]
>> Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
>> ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
>> kunnen dat networkmanager in Debian het nog niet ondersteund.
>> Hmm, ik zie dat er ook een backports-versie van is.
>>
>> Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
>> require the user to set --key-direction."
>>
>> Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.
>>
>> Networkmanager importeert alles nu netjes?
> Ja, als ik  van   maak dan wordt het ovpn config
> bestand wel geïmporteerd, maar wel geeft dus toch in de log van de
> server een foutmelding zoals hierboven. Het bestand word ook
> geïmporteerd als ik de  regels out comment.
>>
>> Wat staat er op de tls-auth regel in je client-configfile?
>> Bij mij staat er dit:
>> tls-auth ta.key 1
> Die komt in mijn client-configfile niet voor.
> 
> -
> client
> dev tun
> proto udp
> remote xx.xx.xx.xx 1194
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
> remote-cert-tls server
> tls-version-min 1.2
> verify-x509-name server_KLsSwJCOaYqwbKIp name
> cipher AES-256-CBC
> auth SHA256
> auth-nocache
> verb 3
> ---
> En hierna de certificaten en keys...

Ik heb op de client dit, daarna de certificaten en keys:
---
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
-

Volgens mij verschilt de cipher en heb jij "auth" waar ik "tls-auth"
heb, en dan de "direction".

>> Dit staat er bij mij in het server configfile:
>> tls-auth /etc/openvpn/keys/ta.key 0
>> Let op die laatste 0 en 1, dat is de direction.
> Bij mij;
> tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
> 
> Dus zonder toevoeging van 0 of 1

Bovenstaande regel lijkt me geschikt voor tls-crypt en niet voor tls-auth.

Je zult moeten kiezen tussen tls-auth en tls-crypt.
Met dat laatste heb ik nog geen ervaring.
En of de network-manager openvpn plugin daarmee werkt weet ik niet.

Je zou het ook eerst zonder tls-crypt of tls-auth aan de praat kunnen
brengen om te zien of het dan werkt.

Je zou het ook zonder de network-manager plugin kunnen doen.
Gewoon het configfile in /etc/openvpn/  zetten en renamen (.ovpn moet
.conf worden). Daarna reboot ik normaal, de VPN start dan automatisch
als er een netwerkverbinding is.

Je kunt hem echter ook uitzetten in /etc/default/openvpn en hem met de
hand starten ("openvpn --config /path/configfile".

Groet,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Fred]

Op 03-01-19 om 19:01 schreef Paul van der Vlis:

Op 03-01-19 om 17:45 schreef Fred:


Op 03-01-19 om 17:39 schreef Paul van der Vlis:

Op 03-01-19 om 15:05 schreef Fred:

Op 02-01-19 om 20:53 schreef Paul van der Vlis:

Hoi,

Op 02-01-19 om 20:00 schreef Fred:

Beste,

Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
mijn mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.

Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
Gnome geïmporteerd echter met uitzondering van het 
gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
toevoegen.

Bedoel je wellicht het  gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.

Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;


#
#
# 2048 bit OpenVPN static key
#
#-BEGIN OpenVPN Static key V1-

Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
regels van n comment out # heb voorzien wel.
Het gaat volgens mij dus wel om  i,p,v  (?)

Maar in jou methode om een .opvn bestand te genereren zie ik juist die
tag niet terug.
Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel
naar een tls issue.

Ik zie dus zoiets en dat werkt:


#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-

(...)

-END OpenVPN Static key V1-



Probeer het misschien eens aan te passen.

Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op;
De log laat dan dit zien;
Jan  3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
packet authentication failed
Jan  3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
unwrapping failed from [AF_INET]

Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
kunnen dat networkmanager in Debian het nog niet ondersteund.
Hmm, ik zie dat er ook een backports-versie van is.

Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
require the user to set --key-direction."

Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.

Networkmanager importeert alles nu netjes?
Ja, als ik  van   maak dan wordt het ovpn config 
bestand wel geïmporteerd, maar wel geeft dus toch in de log van de 
server een foutmelding zoals hierboven. Het bestand word ook 
geïmporteerd als ik de  regels out comment.


Wat staat er op de tls-auth regel in je client-configfile?
Bij mij staat er dit:
tls-auth ta.key 1

Die komt in mijn client-configfile niet voor.

-
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
tls-version-min 1.2
verify-x509-name server_KLsSwJCOaYqwbKIp name
cipher AES-256-CBC
auth SHA256
auth-nocache
verb 3
---
En hierna de certificaten en keys...


Dit staat er bij mij in het server configfile:
tls-auth /etc/openvpn/keys/ta.key 0
Let op die laatste 0 en 1, dat is de direction.

Bij mij;
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key

Dus zonder toevoeging van 0 of 1

gr Fred

Re: openvpn

[Paul van der Vlis]

Op 03-01-19 om 17:45 schreef Fred:
> 
> 
> Op 03-01-19 om 17:39 schreef Paul van der Vlis:
>> Op 03-01-19 om 15:05 schreef Fred:
>>>
>>> Op 02-01-19 om 20:53 schreef Paul van der Vlis:
 Hoi,

 Op 02-01-19 om 20:00 schreef Fred:
> Beste,
>
> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
> mijn mobiel een verbinding kan krijgen.
> Vanaf mijn laptop lukt dit echter niet.
>
> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
> Gnome geïmporteerd echter met uitzondering van het 
> gedeelte.
> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
> toevoegen.
 Bedoel je wellicht het  gedeelte?
 Als je dat op de server hebt, moet je het ook op de client hebben.
 Je kunt het dus ook weghalen aan zowel de server als de client kant.
>>> Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;
>>>
 #
 #
 # 2048 bit OpenVPN static key
 #
 #-BEGIN OpenVPN Static key V1-
>>> Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
>>> regels van n comment out # heb voorzien wel.
>>> Het gaat volgens mij dus wel om  i,p,v  (?)
>>>
>>> Maar in jou methode om een .opvn bestand te genereren zie ik juist die
>>> tag niet terug.
>>> Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel
>>> naar een tls issue.
>> Ik zie dus zoiets en dat werkt:
>> 
>> 
>> #
>> # 2048 bit OpenVPN static key
>> #
>> -BEGIN OpenVPN Static key V1-
>>
>> (...)
>>
>> -END OpenVPN Static key V1-
>> 
>> 
>>
>> Probeer het misschien eens aan te passen.
> Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op;
> De log laat dan dit zien;
> Jan  3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error:
> packet authentication failed
> Jan  3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt
> unwrapping failed from [AF_INET]
Ik heb nog wat verder gekeken, tls-auth is wat anders dan tls-crypt. Als
ik me niet vergis is tls-crypt nieuwer/beter, maar het zou best eens
kunnen dat networkmanager in Debian het nog niet ondersteund.
Hmm, ik zie dat er ook een backports-versie van is.

Uit de manual: "In contrast to --tls-auth, --tls-crypt does *not*
require the user to set --key-direction."

Met tls-crypt heb ik nog geen ervaring. Hieronder ga ik in op tls-auth.

Networkmanager importeert alles nu netjes?

Wat staat er op de tls-auth regel in je client-configfile?
Bij mij staat er dit:
tls-auth ta.key 1
Dit staat er bij mij in het server configfile:
tls-auth /etc/openvpn/keys/ta.key 0
Let op die laatste 0 en 1, dat is de direction.

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Fred]

Op 03-01-19 om 17:39 schreef Paul van der Vlis:

Op 03-01-19 om 15:05 schreef Fred:


Op 02-01-19 om 20:53 schreef Paul van der Vlis:

Hoi,

Op 02-01-19 om 20:00 schreef Fred:

Beste,

Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
mijn mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.

Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
Gnome geïmporteerd echter met uitzondering van het  gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
toevoegen.

Bedoel je wellicht het  gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.

Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;


#
#
# 2048 bit OpenVPN static key
#
#-BEGIN OpenVPN Static key V1-

Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
regels van n comment out # heb voorzien wel.
Het gaat volgens mij dus wel om  i,p,v  (?)

Maar in jou methode om een .opvn bestand te genereren zie ik juist die
tag niet terug.
Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel
naar een tls issue.

Ik zie dus zoiets en dat werkt:


#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-

(...)

-END OpenVPN Static key V1-



Probeer het misschien eens aan te passen.

Dat heb ik juist geprobeerd maar levert ook niet het gewenste resultaat op;
De log laat dan dit zien;

Jan  3 15:37:00 raspberrypi ovpn-server[338]: tls-crypt unwrap error: 
packet authentication failed
Jan  3 15:37:00 raspberrypi ovpn-server[338]: TLS Error: tls-crypt 
unwrapping failed from [AF_INET]


gr Fred

Re: openvpn

[Paul van der Vlis]

Op 03-01-19 om 15:05 schreef Fred:
> 
> 
> Op 02-01-19 om 20:53 schreef Paul van der Vlis:
>> Hoi,
>>
>> Op 02-01-19 om 20:00 schreef Fred:
>>> Beste,
>>>
>>> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
>>> mijn mobiel een verbinding kan krijgen.
>>> Vanaf mijn laptop lukt dit echter niet.
>>>
>>> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
>>> Gnome geïmporteerd echter met uitzondering van het  gedeelte.
>>> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil
>>> toevoegen.
>> Bedoel je wellicht het  gedeelte?
>> Als je dat op de server hebt, moet je het ook op de client hebben.
>> Je kunt het dus ook weghalen aan zowel de server als de client kant.
> Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;
> 
>> #
>> #
>> # 2048 bit OpenVPN static key
>> #
>> #-BEGIN OpenVPN Static key V1-
> Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de
> regels van n comment out # heb voorzien wel.
> Het gaat volgens mij dus wel om  i,p,v  (?)
> 
> Maar in jou methode om een .opvn bestand te genereren zie ik juist die
> tag niet terug.
> Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel
> naar een tls issue.

Ik zie dus zoiets en dat werkt:


#
# 2048 bit OpenVPN static key
#
-BEGIN OpenVPN Static key V1-

(...)

-END OpenVPN Static key V1-



Probeer het misschien eens aan te passen.

Groet,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Fred]

Op 02-01-19 om 20:53 schreef Paul van der Vlis:

Hoi,

Op 02-01-19 om 20:00 schreef Fred:

Beste,

Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
mijn mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.

Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
Gnome geïmporteerd echter met uitzondering van het  gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen.

Bedoel je wellicht het  gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.

Onderstaande heb ik uit het .ovpn configuratie bestand gekopieerd;


#
#
# 2048 bit OpenVPN static key
#
#-BEGIN OpenVPN Static key V1-
Deze sectie wordt niet aanvaart door de netwerkmanager, dat dat ik de 
regels van n comment out # heb voorzien wel.

Het gaat volgens mij dus wel om  i,p,v  (?)

Maar in jou methode om een .opvn bestand te genereren zie ik juist die 
tag niet terug.
Wellicht dat dat juist het probleem is. De log verwijst in elk geval wel 
naar een tls issue.


Gr Fred

Re: openvpn

[Fred]

Jan  2 20:25:07 raspberrypi ovpn-server[338]: tls-crypt unwrap error: 
packet too short
Jan  2 20:25:07 raspberrypi ovpn-server[338]: TLS Error: tls-crypt 
unwrapping failed from [AF_INET]


Fred

Op 02-01-19 om 20:58 schreef Geert Stappers:

On Wed, Jan 02, 2019 at 08:00:14PM +0100, Fred wrote:

Beste,

Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn
mobiel een verbinding kan krijgen.
Vanaf mijn laptop lukt dit echter niet.

Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome
geïmporteerd echter met uitzondering van het  gedeelte.
Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen.

het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar er
word geen verbinding gemaakt.
Ik heb geen idee waar ik nu verder kan/moet zoeken om te kunnen achterhalen
wat er mis gaat.

Wat komt er in logging van de server in kwestie?


Groeten
Geert Stappers

Re: openvpn

[Paul van der Vlis]

Hoi,

Op 02-01-19 om 20:00 schreef Fred:
> Beste,
> 
> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van
> mijn mobiel een verbinding kan krijgen.
> Vanaf mijn laptop lukt dit echter niet.
> 
> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van
> Gnome geïmporteerd echter met uitzondering van het  gedeelte.
> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen.

Bedoel je wellicht het  gedeelte?
Als je dat op de server hebt, moet je het ook op de client hebben.
Je kunt het dus ook weghalen aan zowel de server als de client kant.

Bij mij werkt het met een .ovpn file in network-manager, maar ik gebruik
het niet meer. Vooral omdat network-manager rare dingen doet met de DNS.
Dat is wel te wijzigen, maar dat vind ik lastig.

Ik werk nu direct met openvpn. Je moet het .ovpn file renamen naar
.conf, maar dan werkt het meteen. En de DNS is dan ook te configureren
via het configfile.

> het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar
> er word geen verbinding gemaakt.> Ik heb geen idee waar ik nu verder kan/moet 
> zoeken om te kunnen
> achterhalen wat er mis gaat.
> 
> iemand..?

Mijn rare ervaring met openvpn: reboot de machine. Daarna komt er pas
van alles in /var/log/syslog en dat kan je verder helpen.

Misschien heb je hier nog iets aan, hoe ik een .ovpn-file maak:
--
cd /etc/openvpn/easy-rsa/keys/
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ./
pas in client.conf de servername aan (zoek op "remote")
naam=vpn   #naam is belangrijk, want zie je in network-manager
cp -a client.conf $naam.ovpn
echo "" >> $naam.ovpn
echo "" >> $naam.ovpn
cat ca.crt >> $naam.ovpn
echo "" >> $naam.ovpn
echo "" >> $naam.ovpn
cat $naam.crt >> $naam.ovpn
echo "" >> $naam.ovpn
echo "" >> $naam.ovpn
cat $naam.key >> $naam.ovpn
echo "" >> $naam.ovpn
echo "" >> $naam.ovpn
cat ta.key >> $naam.ovpn
echo "" >> $naam.ovpn
--


Groet,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: openvpn

[Geert Stappers]

On Wed, Jan 02, 2019 at 08:00:14PM +0100, Fred wrote:
> Beste,
> 
> Ik heb op een RBP een VPN servertje draaien waarmee ik via de ap van mijn
> mobiel een verbinding kan krijgen.
> Vanaf mijn laptop lukt dit echter niet.
> 
> Ik heb wel het .ovpn configuratie bestand in de netwerk beheerder van Gnome
> geïmporteerd echter met uitzondering van het  gedeelte.
> Deze lijkt namelijk niet geaccepteerd te worden als in n VPN wil toevoegen.
> 
> het .ovpn bestand word zo door het netwerkbeheer wel geaccepteerd maar er
> word geen verbinding gemaakt.
> Ik heb geen idee waar ik nu verder kan/moet zoeken om te kunnen achterhalen
> wat er mis gaat.

Wat komt er in logging van de server in kwestie?


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: openvpn over ipv6 /65

[Steve Kemp]

>   Hi.
> 
> >   This will need to be repeated at every reboot,
> 
> No, it won't. OP has two stanzas regarding eth0 in e/n/i already - one
> for inet and another one for inet6.

  You're right; I'm clearly not having a good day!  Thank-you
 for the correction.

Steve
-- 
https://www.steve.org.uk/

Re: openvpn over ipv6 /65

[Reco]

Hi.

On Fri, Nov 23, 2018 at 03:39:16PM +, Steve Kemp wrote:
> > with this:
> > 
> > iface eth0 inet6 static
> >address 2a03:9800:10:54::2
> >netmask 65
> >gateway 2a03:9800:10:54::1
> > 
> > Leave all the other entries intact.
> > Then invoke this as root (one-time only):
> > 
> > ip a d dev eth0 2a03:9800:10:54::2/64
> > ip a a dev eth0 2a03:9800:10:54::2/65
> > ip ro d default via 2a03:9800:10:54::1
> 
>   This will need to be repeated at every reboot,

No, it won't. OP has two stanzas regarding eth0 in e/n/i already - one
for inet and another one for inet6.
The whole point of this exercise is to get persistent configuration for
/65 netmask *and* to avoid ifdown/ifup sequence to implement it now.
And, of course, do the thing without the reboot.

Reco

Re: openvpn over ipv6 /65

[Steve Kemp]

> with this:
> 
> iface eth0 inet6 static
>address 2a03:9800:10:54::2
>netmask 65
>gateway 2a03:9800:10:54::1
> 
> Leave all the other entries intact.
> Then invoke this as root (one-time only):
> 
> ip a d dev eth0 2a03:9800:10:54::2/64
> ip a a dev eth0 2a03:9800:10:54::2/65
> ip ro d default via 2a03:9800:10:54::1

  This will need to be repeated at every reboot, better to use `up`, for
 example:

iface eth0 ...
...
gateway ...
up ip -6 addr  ..

  "up" will run the given command after the interface is brought up, as
 per "man 5 interfaces".

Steve
-- 

Re: openvpn over ipv6 /65

[Reco]

HI.

On Fri, Nov 23, 2018 at 03:07:01PM +0100, tony wrote:
> Thanks for your quick response, Reco,
> 
> On 23/11/2018 13:33, Reco wrote:
> > Hi.
> > 
> > On Fri, Nov 23, 2018 at 01:18:45PM +0100, tony wrote:
> >> Hi,
> >>
> >> I have a Stretch VPServer with a /64 netbloch, of which only the first 2
> >> addresses are used. I've been struggling for some time to get the right
> >> stanza to split that into two /65s, using the upper half for openvpn.
> > 
> > I'd check first that some other addresses from this /64 range are routed
> > by your VPS provider.
> > 
> I'm not sure I understand what you mean. As far as I'm aware, my VPS
> provider furnishes a full native /64 netblock for my exclusive use.
> They'll provide more, at a cost, but I see no point in that.
> > 
> [snip]

Assign some other IPv6 address from your range to your VPS.
Ensure that it's reachable from the outside world.
For instance, I do not get any response from your gateway while I'm
pinging 2a03:9800:10:54::dead (which you do not have), and get a reply
from 2a03:9800:10:54::2 (which belongs to your VPS).


> > Ad-hoc configuration:
> > 
> > ### check this on your OS!
> > # ip a d igb0 2001:db8:0:123::/64
> > # ip a a igb0 2001:db8:0:123::/65
> > ###
> > ### re-assign the other aliases previously set under the /64 block
> > # ip a a igb0 2001:db8:0:123::dead/128
> > # ip a a igb0 2001:db8:0:123::ea:beef/128
> > 
> I'm not using any addresses other than the ::1 and ::2 in the /64 block,
> so presumably the last two lines are redundant.

Yes, you do not need them.


> > As for the persistent configuration, that depends on the contents of
> > /etc/network/interfaces. Can be static (it's straightforward then),
> > DHCPv6 (you won't be able to do the split) or RA (ditto).
> > 
> No, it's all static:

That simplifies things greatly.
Replace this:

iface eth0 inet6 static
   address 2a03:9800:10:54::2
   netmask 64
   gateway 2a03:9800:10:54::1

with this:

iface eth0 inet6 static
   address 2a03:9800:10:54::2
   netmask 65
   gateway 2a03:9800:10:54::1

Leave all the other entries intact.
Then invoke this as root (one-time only):

ip a d dev eth0 2a03:9800:10:54::2/64
ip a a dev eth0 2a03:9800:10:54::2/65
ip ro d default via 2a03:9800:10:54::1


> So what is igb0?

A name of interface that's used in OpenVPN documentation. Yours is called eth0.


> What do you mean by ad-hoc and persistent configuration?

ad-hoc means that you're using certain OS binaries (in this case - ip)
to create a network configuration that does not survive the reboot.
persistent means the opposite - you're trying to create a configuration
that should reproduce itself after the reboot (in this case - e/n/i).

Reco

Re: openvpn over ipv6 /65

[tony]

Thanks for your quick response, Reco,

On 23/11/2018 13:33, Reco wrote:
>   Hi.
> 
> On Fri, Nov 23, 2018 at 01:18:45PM +0100, tony wrote:
>> Hi,
>>
>> I have a Stretch VPServer with a /64 netbloch, of which only the first 2
>> addresses are used. I've been struggling for some time to get the right
>> stanza to split that into two /65s, using the upper half for openvpn.
> 
> I'd check first that some other addresses from this /64 range are routed
> by your VPS provider.
> 
I'm not sure I understand what you mean. As far as I'm aware, my VPS
provider furnishes a full native /64 netblock for my exclusive use.
They'll provide more, at a cost, but I see no point in that.
> 
[snip]

> Ad-hoc configuration:
> 
> ### check this on your OS!
> # ip a d igb0 2001:db8:0:123::/64
> # ip a a igb0 2001:db8:0:123::/65
> ###
> ### re-assign the other aliases previously set under the /64 block
> # ip a a igb0 2001:db8:0:123::dead/128
> # ip a a igb0 2001:db8:0:123::ea:beef/128
> 
I'm not using any addresses other than the ::1 and ::2 in the /64 block,
so presumably the last two lines are redundant.

> As for the persistent configuration, that depends on the contents of
> /etc/network/interfaces. Can be static (it's straightforward then),
> DHCPv6 (you won't be able to do the split) or RA (ditto).
> 
No, it's all static:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 188.246.204.210
netmask 255.255.255.0
gateway 188.246.204.1


iface eth0 inet6 static
   address 2a03:9800:10:54::2
   netmask 64
   gateway 2a03:9800:10:54::1

So what is igb0? What do you mean by ad-hoc and persistent configuration?

Thanks again, Tony

Re: openvpn over ipv6 /65

[Reco]

Hi.

On Fri, Nov 23, 2018 at 01:18:45PM +0100, tony wrote:
> Hi,
> 
> I have a Stretch VPServer with a /64 netbloch, of which only the first 2
> addresses are used. I've been struggling for some time to get the right
> stanza to split that into two /65s, using the upper half for openvpn.

I'd check first that some other addresses from this /64 range are routed
by your VPS provider.


> There are many 'quick config' tutorials on the web, but none seem to
> suit my objectives, the most enlightened being
> https://community.openvpn.net/openvpn/wiki/IPv6, but I'm tripping over
> the stanza:
> 
> ### check this on your OS!
> # ifconfig igb0 inet6 2001:db8:0:123::/64 -alias
> # ifconfig igb0 inet6 2001:db8:0:123::/65
> ###
> ### re-assign the other aliases previously set under the /64 block
> # ifconfig igb0 inet6 2001:db8:0:123::dead/128 alias
> # ifconfig igb0 inet6 2001:db8:0:123::ea:beef/128 alias
> # ...
> 
> which seems to apply to FreeBSD.

Yep.


> Could some knowledgeable person please give me the equivalent contents
> and where to put them for Debian Linux.

Ad-hoc configuration:

### check this on your OS!
# ip a d igb0 2001:db8:0:123::/64
# ip a a igb0 2001:db8:0:123::/65
###
### re-assign the other aliases previously set under the /64 block
# ip a a igb0 2001:db8:0:123::dead/128
# ip a a igb0 2001:db8:0:123::ea:beef/128

As for the persistent configuration, that depends on the contents of
/etc/network/interfaces. Can be static (it's straightforward then),
DHCPv6 (you won't be able to do the split) or RA (ditto).

Reco

Re: OpenVPN sous Stretch avec systemd

[Erwan David]

On Wed, Sep 12, 2018 at 02:04:14PM CEST, daniel huhardeaux  
said:
> Le 12/09/2018 à 10:53, roger.tar...@free.fr a écrit :
> > Bonjour
> Bonjour
> > [...]
> > Quel est le comportement normal que doit avoir un client VPN qui se met en 
> > veille/hibernation ?
> > Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
> Pour quelle-s raison-s ?

Pour ne pas bouffer un slot de connexion et les ressources associées
sur le serveur de VPN pendant qu'il dormira par exemple


-- 
Erwan

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 12/09/2018 à 10:53, roger.tar...@free.fr a écrit :

Bonjour

Bonjour

[...]
Quel est le comportement normal que doit avoir un client VPN qui se met en 
veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?

Pour quelle-s raison-s ?

Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à 
vérifier plus souvent que le client connecté est présent sur le réseau ou s'il 
est juste inactif.

Quel est l'intérêt ?


* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre 
l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System 
settings/Network.
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du 
système soient gérées par systemd, manuellement ou par network-manager de 
manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager 
apparemment pour les mêmes raisons.
Ceci est un autre débat. Il y a quelques temps NM était une catastrophe, 
je trouve qu'il c'est stabilisé. Cela dit je continue à la mano avec le 
fichier interfaces et Wicd.


Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par 
network-manager ?

Option VPN du menu de NM en ayant pris soin d'installer nm-openvpn


Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien 
network-manager ?

à toi de tester et choisir ce qui te conviens le mieux.

- Original Message -
From: daniel huhardeaux 
To: debian-user-french@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :

[...] et un message d'erreur ("Authenticate/Decrypt packet error:
cipher final failed") trop discrets d'OpenVPN

Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un
niveau inférieur lorsque le VPN est validé fonctionnel.


[...]

Il semble que l'absence d'accès au réseau internet était causée par
cette "transaction en échec en boucle" qui se prolongeait entre le
client et le server OpenVPN.

Non, elle est dûe au fait que le routage était en place mais le VPN non
fonctionnel (route par défaut vers le VPN)


2/ la connaissance du système de configuration des réseaux avec
Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est
crucial de savoir ce qui se passe.
Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.

Comment faudrait-il procéder pour savoir dans quel état se trouve la
configuration de composants logiciels réseaux et la configuration
réseau d'une machine Stretch ?

Il n'y a pas de différences (peu éventuellement) entre la gestion réseau
Jessie et Stretch. Les programmes et configurations ont éventuellement
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu
cherches dans le fichier interfaces alors que c'est network-manager qui
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il
faudrait pour être cohérent faire gérer le VPN également par
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).


--
Daniel

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

Bonjour 

* 
En ce qui concerne la mise en veille ou en hibernation durables, cad 
suffisamment longue pour que le serveur déconnecte le client, lorsque la 
machine cliente se réveille, elle se reconnecte comme lors du démarrage. 
Si c'est plus rapide, je crois que ça marche aussi. Je vais refaire le test. 

Quel est le comportement normal que doit avoir un client VPN qui se met en 
veille/hibernation ?
Ne devrait-il pas au préalable se déconnecter du serveur VPN ?
Je vais examiner les paramètres du serveur pour voir si on peut l'obliger à 
vérifier plus souvent que le client connecté est présent sur le réseau ou s'il 
est juste inactif. 

* network-manager
Il me semble que l'état des connexions du système est parfois incohérent entre 
l'état réel, ce qu'affiche le menu graphique et ce qu'affiche le System 
settings/Network. 
Est-ce network-manager qui est responsable de ça ?
Peut-on le configurer (ou d'autres composants) pour que les connexions du 
système soient gérées par systemd, manuellement ou par network-manager de 
manière cohérente ?
J'ai entendu quelquefois des informaticiens se plaindre de network-manager 
apparemment pour les mêmes raisons. 

Concrètement, comment dois-je procéder pour faire gérer le client OpenVPN par 
network-manager ?

Qu'est-ce qui est le plus robuste à l'utilisation ?
Configuration manuelle de /etc/network/interfaces et d'OpenVPN ou bien 
network-manager ?

Merci
Bonne journée 






- Original Message -
From: daniel huhardeaux 
To: debian-user-french@lists.debian.org
Sent: Sun, 09 Sep 2018 23:14:24 +0200 (CEST)
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :
> [...] et un message d'erreur ("Authenticate/Decrypt packet error: 
> cipher final failed") trop discrets d'OpenVPN

Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose 
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un 
niveau inférieur lorsque le VPN est validé fonctionnel.

> [...]
>
> Il semble que l'absence d'accès au réseau internet était causée par 
> cette "transaction en échec en boucle" qui se prolongeait entre le 
> client et le server OpenVPN.

Non, elle est dûe au fait que le routage était en place mais le VPN non 
fonctionnel (route par défaut vers le VPN)

>
> 2/ la connaissance du système de configuration des réseaux avec 
> Stretch est encore plus d'actualité.
> En effet, quand ça marche c'est bien, mais quand ça foire il est 
> crucial de savoir ce qui se passe.
> Et là,rien n'a indiqué ce qui était en train de clocher.
> De plus, je comprends que ce serait un système en cours de transition.
>
> Comment faudrait-il procéder pour savoir dans quel état se trouve la 
> configuration de composants logiciels réseaux et la configuration 
> réseau d'une machine Stretch ?

Il n'y a pas de différences (peu éventuellement) entre la gestion réseau 
Jessie et Stretch. Les programmes et configurations ont éventuellement 
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu 
cherches dans le fichier interfaces alors que c'est network-manager qui 
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il 
faudrait pour être cohérent faire gérer le VPN également par 
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).

-- 
Daniel

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 09/09/2018 à 20:28, roger.tar...@free.fr a écrit :
[...] et un message d'erreur ("Authenticate/Decrypt packet error: 
cipher final failed") trop discrets d'OpenVPN


Il n'y a rien de discret dans OpenVPN, il suffit de mettre un verbose 
élevé (=5 par ex) lorsque l'on rencontre des soucis et de le passer à un 
niveau inférieur lorsque le VPN est validé fonctionnel.



[...]

Il semble que l'absence d'accès au réseau internet était causée par 
cette "transaction en échec en boucle" qui se prolongeait entre le 
client et le server OpenVPN.


Non, elle est dûe au fait que le routage était en place mais le VPN non 
fonctionnel (route par défaut vers le VPN)




2/ la connaissance du système de configuration des réseaux avec 
Stretch est encore plus d'actualité.
En effet, quand ça marche c'est bien, mais quand ça foire il est 
crucial de savoir ce qui se passe.

Et là,rien n'a indiqué ce qui était en train de clocher.
De plus, je comprends que ce serait un système en cours de transition.

Comment faudrait-il procéder pour savoir dans quel état se trouve la 
configuration de composants logiciels réseaux et la configuration 
réseau d'une machine Stretch ?


Il n'y a pas de différences (peu éventuellement) entre la gestion réseau 
Jessie et Stretch. Les programmes et configurations ont éventuellement 
évoluées, il s'agit surtout de savoir qui fait quoi. Dans ton cas, tu 
cherches dans le fichier interfaces alors que c'est network-manager qui 
semble gérer le réseau (qui n'utilise pas le fichier interfaces). Il 
faudrait pour être cohérent faire gérer le VPN également par 
network-manage (ou rien et utiliser interfaces + conf OpenVPN à la mano).


--
Daniel

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

Waouh !... 

1/ Voilà ce que je viens de découvrir en analysant ma configuration OpenVPN de 
la machine Stretch : 
j'utilisais un fichier de configuration OpenVPN un poil trop âgé encore en 
AES128, alors que j'utilisais le nouveau fichier de conf en AES256 pour la 
machine Jessie (le serveur a été passé en AES256). 
Cela provoquait un Warning ( 'cipher' is used inconsistently, local='cipher 
AES-128-CBC', remote='cipher AES-256-CBC') et un message d'erreur 
("Authenticate/Decrypt packet error: cipher final failed") trop discrets 
d'OpenVPN : ce qui expliquait le comportement bizarre du client qui cherchait à 
se reconnecter régulièrement et n'était en fait pas connecté comme l'indiquait 
faussement le serveur. 



Dès que j'ai remis le bon fichier de conf en AES256 (au même bon endroit) le 
comportement de la machine Stretch est redevenu normal, cad identique à celui 
de la machine Jessie avec les commandes suivantes : $ sudo systemctl start 
openvpn@monserveur.service 
$ sudo systemctl restart openvpn@monserveur.service 
$ sudo systemctl stop openvpn@monserveur.service 
On voit sur le serveur OpenVPN que le client se connecte et se déconnecte 
_immédiatement_. 
Et le ping via VPN entre les deux machines Jessie et Stretch fonctionne à 
nouveau. 

$ ip r 
default via 212.27.38.253 dev tun0 
< mon -ip-fixe-masquée> via 192.168.0.1 dev wlp32s0 
169.254.0.0/16 dev tun0 scope link metric 1000 
192.168.0.0/24 via 212.27.38.253 dev tun0 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 metric 600 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68 

$ sudo ifconfig 
enp8s0: flags=4099 mtu 1500 
ether 00:17:42:7a:c8:74 txqueuelen 1000 (Ethernet) 
RX... 

lo: flags=73 mtu 65536 
inet 127.0.0.1 netmask 255.0.0.0 
inet6 ::1 prefixlen 128 scopeid 0x10 
loop txqueuelen 1 (Local Loopback) 
RX... 

tun0: flags=4305 mtu 1500 
inet 192.168.27.68 netmask 255.255.255.255 destination 212.27.38.253 
inet6 fe80::bb3e:ca65:f4bc:9df3 prefixlen 64 scopeid 0x20 
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) 
RX... 

wlp32s0: flags=4163 mtu 1500 
inet 192.168.0.102 netmask 255.255.255.0 broadcast 192.168.0.255 
inet6 fe80::728e:fd77:36f1:a585 prefixlen 64 scopeid 0x20 
ether 00:21:6a:35:c6:a4 txqueuelen 1000 (Ethernet) 
RX... 

Il semble que l'absence d'accès au réseau internet était causée par cette 
"transaction en échec en boucle" qui se prolongeait entre le client et le 
server OpenVPN. 



2/ la connaissance du système de configuration des réseaux avec Stretch est 
encore plus d'actualité. 
En effet, quand ça marche c'est bien, mais quand ça foire il est crucial de 
savoir ce qui se passe. 
Et là,rien n'a indiqué ce qui était en train de clocher. 


De plus, je comprends que ce serait un système en cours de transition. 


Comment faudrait-il procéder pour savoir dans quel état se trouve la 
configuration de composants logiciels réseaux et la configuration réseau d'une 
machine Stretch ? 

Daniel, merci beaucoup pour le temps que tu as passé pour m'aider à régler ce 
problème. 

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 09/09/2018 à 19:02, roger.tar...@free.fr a écrit :

[...]
- machine Stretch en WiFi :
$ sudo ifconfig
enp8s0: flags=4099  mtu 1500
 ether 00:17:42:7a:c8:74  txqueuelen 1000  (Ethernet)
 RX packets 16979  bytes 7973796 (7.6 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 15730  bytes 2772306 (2.6 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 device interrupt 16

lo: flags=73  mtu 65536
 inet 127.0.0.1  netmask 255.0.0.0
 inet6 ::1  prefixlen 128  scopeid 0x10
 loop  txqueuelen 1  (Local Loopback)
 RX packets 5253  bytes 417199 (407.4 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 5253  bytes 417199 (407.4 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
 inet6 fe80::728e:fd77:36f1:a585  prefixlen 64  scopeid 0x20
 ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
 RX packets 287447  bytes 231604167 (220.8 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 221935  bytes 36433522 (34.7 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
[...]


Y'a un problème, pas d'IP !

--
Daniel

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

Bonjour,
Suite à tes remarques, j'ai ajouté mes observations concernant les deux 
machines (Jessie qui fonctionne et Stretch qui râle).
Merci

- Original Message -
From: "daniel huhardeaux" 
To: debian-user-french@lists.debian.org
Sent: Sunday, September 9, 2018 3:05:48 PM
Subject: Re: OpenVPN sous Stretch avec systemd

Le 09/09/2018 à 02:20, roger.tar...@free.fr a écrit :
> [...]
> $ sudo ifconfig -a
> enp8s0: flags=4099  mtu 1500
>  ether 00:17:42:7a:c8:74  txqueuelen 1000  (Ethernet)
>  RX packets 0  bytes 0 (0.0 B)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 0  bytes 0 (0.0 B)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>  device interrupt 16
>
> lo: flags=73  mtu 65536
>  inet 127.0.0.1  netmask 255.0.0.0
>  inet6 ::1  prefixlen 128  scopeid 0x10
>  loop  txqueuelen 1  (Local Loopback)
>  RX packets 4811  bytes 384593 (375.5 KiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 4811  bytes 384593 (375.5 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> tun0: flags=4305  mtu 1500
>  inet 192.168.27.68  netmask 255.255.255.255  destination 
> 212.27.38.253
>  inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
>  unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 
> 100  (UNSPEC)
>  RX packets 0  bytes 0 (0.0 B)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 16  bytes 1031 (1.0 KiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>
> wlp32s0: flags=4163  mtu 1500
>  inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
>  inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
>  ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
>  RX packets 246563  bytes 210114507 (200.3 MiB)
>  RX errors 0  dropped 0  overruns 0  frame 0
>  TX packets 185695  bytes 29883060 (28.4 MiB)
>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Daniel dit :
Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0 
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant 
que le masque est en /24 et que le serveur VPN est de type server. Je ne 
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE: 
pourquoi via VPN ?

Roger dit :
sur mon autre machine en Jessie, j'ai aussi 212.27.38.253 comme ça ;
inet 192.168.27.67 peer 212.27.38.253/32 scope global tun0
tandis que sur la machine en Stretch, j'ai :
inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253


machine Jessie (réseaux fonctionnels) :
$ sudo ifconfig
eth0  Link encap:Ethernet  HWaddr 00:23:26:3b:9f:15  
  inet addr:192.168.0.152  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::223:26ff:fe3b:9f15/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:3954 errors:0 dropped:1 overruns:0 frame:0
  TX packets:1586 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:2354094 (2.2 MiB)  TX bytes:209838 (204.9 KiB)
  Interrupt:16 

loLink encap:Local Loopback  
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:221 errors:0 dropped:0 overruns:0 frame:0
  TX packets:221 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0 
  RX bytes:23287 (22.7 KiB)  TX bytes:23287 (22.7 KiB)

tun0  Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
  inet addr:192.168.27.67  P-t-P:212.27.38.253  Mask:255.255.255.255
  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
  RX packets:1063 errors:0 dropped:0 overruns:0 frame:0
  TX packets:716 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:100 
  RX bytes:1356357 (1.2 MiB)  TX bytes:46040 (44.9 KiB)


toujours la machine Jessie :
$ ip r
default via 212.27.38.253 dev tun0 
default via 212.27.38.253 dev tun0  proto static  metric 1024 
 via 192.168.0.1 dev eth0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.152 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0  proto kernel  scope link  src 192.168.27.67



> et
> $ cat /etc/network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
>
> source /etc/network/interfaces.d/*
>
> # The loopback network interface
> auto lo
> iface lo inet l

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 09/09/2018 à 02:20, roger.tar...@free.fr a écrit :

[...]
$ sudo ifconfig -a
enp8s0: flags=4099  mtu 1500
 ether 00:17:42:7a:c8:74  txqueuelen 1000  (Ethernet)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 0  bytes 0 (0.0 B)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 device interrupt 16

lo: flags=73  mtu 65536
 inet 127.0.0.1  netmask 255.0.0.0
 inet6 ::1  prefixlen 128  scopeid 0x10
 loop  txqueuelen 1  (Local Loopback)
 RX packets 4811  bytes 384593 (375.5 KiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 4811  bytes 384593 (375.5 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305  mtu 1500
 inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253
 inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100 
 (UNSPEC)
 RX packets 0  bytes 0 (0.0 B)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 16  bytes 1031 (1.0 KiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
 inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
 inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
 ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
 RX packets 246563  bytes 210114507 (200.3 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 185695  bytes 29883060 (28.4 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Donc connecté en WIFI, pas de liaison filaire. L'IP destination de tun0 
ne correspond pas: elle devrait etre de type 192.168.27.1 en imaginant 
que le masque est en /24 et que le serveur VPN est de type server. Je ne 
comprends pas l'adresse 212.27.38.253 qui est une IP publique de FREE: 
pourquoi via VPN ?



et
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Tiens, c'est bizarre puisqu'aucune interface n'est configurée ici (par rapport 
à mon habitude avec Jessie).


Tout dépend si tu utilises network-manager ou non. Si non, les 
définitions sont dans interfaces.d



Voilà ce que j'obtiens :
$ ip r
default via 212.27.38.253 dev tun0


??? Incohérent

 via 192.168.0.1 dev wlp32s0
Si la Freebox est en mode routeur elle prend en général l'IP 
192.168.0.254. As tu modifié? Si elle est en mode bridge 
 est attribuée à wlp32s0. Pour moi, tout semble 
incohérent.




169.254.0.0/16 dev tun0 scope link metric 1000
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
metric 600


2 fois la même route ...

[...]

On/je ne comprends pas quel est le but de ton VPN même le but tout court 
des manipulations. Vérifie que la table de routage et la liste des 
interfaces lorsque le VPN n'est pas monté (ifconfig sans option) sont 
cohérent et que le réseau local fonctionne.


--
Daniel

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

- Original Message -
From: "daniel huhardeaux" 
To: debian-user-french@lists.debian.org
Sent: Sunday, September 9, 2018 12:51:25 AM
Subject: Re: OpenVPN sous Stretch avec systemd

Le 08/09/2018 à 21:59, roger.tar...@free.fr a écrit :
> [...]
>
> Roger dit :
> ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip

Ah, chez moi elle existe! Peu importe, c'est le résultat qui compte


> Peux-tu préciser ce que tu entends par "conformes" ?

Que les informations affichées soient celles qui correspondent à 
l'environnement. On ne peut en dire plus puisqu'aucune info réseau n'a 
été divulguée: combien de cartes réseau, identification des cartes, vpn 
en mode tun ou tapo, etc.


Roger dit :
$ ls /sys/class/net/  
enp8s0  lo  tun0  wlp32s0

Installons net-tools !
$ sudo apt-get install net-tools
Et :
$ sudo ifconfig -a
enp8s0: flags=4099  mtu 1500
ether 00:17:42:7a:c8:74  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 16  

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1  (Local Loopback)
RX packets 4811  bytes 384593 (375.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 4811  bytes 384593 (375.5 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305  mtu 1500
inet 192.168.27.68  netmask 255.255.255.255  destination 212.27.38.253
inet6 fe80::fffe:d16a:8dbb:72cd  prefixlen 64  scopeid 0x20
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  
(UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 16  bytes 1031 (1.0 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp32s0: flags=4163  mtu 1500
inet 192.168.0.5  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::8ef3:422:1504:638f  prefixlen 64  scopeid 0x20
ether 00:21:6a:35:c6:a4  txqueuelen 1000  (Ethernet)
RX packets 246563  bytes 210114507 (200.3 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 185695  bytes 29883060 (28.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


et 
$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Tiens, c'est bizarre puisqu'aucune interface n'est configurée ici (par rapport 
à mon habitude avec Jessie).


> Voilà ce que j'obtiens :
> $ ip r
> default via 212.27.38.253 dev tun0
>  via 192.168.0.1 dev wlp32s0
> 169.254.0.0/16 dev tun0 scope link metric 1000
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
> 192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
> metric 600
> 192.168.27.64/27 via 212.27.38.253 dev tun0
> 212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68
>
> Ça vous parle ?
> Je cherche une solution pour cet autre problème de routage.

Donc le VPN devient la route par défaut: ne me semble pas logique car je 
suppose que l'IP  212.27.38.253 est celle de la box du réseau local côté 
WAN. Cela dépend également de la configuration de la box, mode routeur 
ou bridge. Lorsque le VPN n'est *PAS* monté relance cette commande pour 
vérifier les routes affichées et compare.

Roger dit :
Le VPN est en mode routé.

http://monip.fr/212.27.38.253
Adresse IP: 212.27.38.253
PTR enregistrement de ressource:freeplayer.freebox.fr
Organisation:   Free SAS
...


[...]
>
> CONSTAT INTERESSANT :
> systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom 
> client.conf) qui n'existe pas puisque j'ai le fichier de configuration 
> suivant :
> /etc/openvpn/*client*/config_openvpn_routed_debian.conf

J'ai toujours connu OpenVPN cherchant par défaut les fichiers de config 
dans /etc/openvpn pour Debian. Le répertoire de travail est dans le 
fichier de conf, /etc/init.d/openvpn: CONFIG_DIR=/etc/openvpn
En lancant manuellement (openvpn ) on peut 
définir n'importe quel chemin pour le fichier.

Roger dit : 
Oui, avec Jessie, je fais comme ça.
Je ne comprends pas l'objectif des répertoires /etc/openvpn/server et 
/etc/openvpn/client 
Je me suis dit bêtement que c'était dans /etc/openvpn/client qu'il fallait 
lancer le fichier de configuration du client...


> Je peux bricoler en copiant mon fichier de configuration client ici 
> avec ce nom client.conf (j'ai fait le test : et la commande $ sudo 
> systemctl status openvpn@client.service fonctionne)
> M

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 08/09/2018 à 21:59, roger.tar...@free.fr a écrit :

[...]

Roger dit :
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip


Ah, chez moi elle existe! Peu importe, c'est le résultat qui compte


Peux-tu préciser ce que tu entends par "conformes" ?


Que les informations affichées soient celles qui correspondent à 
l'environnement. On ne peut en dire plus puisqu'aucune info réseau n'a 
été divulguée: combien de cartes réseau, identification des cartes, vpn 
en mode tun ou tapo, etc.



Voilà ce que j'obtiens :
$ ip r
default via 212.27.38.253 dev tun0
 via 192.168.0.1 dev wlp32s0
169.254.0.0/16 dev tun0 scope link metric 1000
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
metric 600

192.168.27.64/27 via 212.27.38.253 dev tun0
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68

Ça vous parle ?
Je cherche une solution pour cet autre problème de routage.


Donc le VPN devient la route par défaut: ne me semble pas logique car je 
suppose que l'IP  212.27.38.253 est celle de la box du réseau local côté 
WAN. Cela dépend également de la configuration de la box, mode routeur 
ou bridge. Lorsque le VPN n'est *PAS* monté relance cette commande pour 
vérifier les routes affichées et compare.


[...]


CONSTAT INTERESSANT :
systemd cherche à utiliser */etc/openvpn/client.conf* (avec le nom 
client.conf) qui n'existe pas puisque j'ai le fichier de configuration 
suivant :

/etc/openvpn/*client*/config_openvpn_routed_debian.conf


J'ai toujours connu OpenVPN cherchant par défaut les fichiers de config 
dans /etc/openvpn pour Debian. Le répertoire de travail est dans le 
fichier de conf, /etc/init.d/openvpn: CONFIG_DIR=/etc/openvpn
En lancant manuellement (openvpn ) on peut 
définir n'importe quel chemin pour le fichier.


Je peux bricoler en copiant mon fichier de configuration client ici 
avec ce nom client.conf (j'ai fait le test : et la commande $ sudo 
systemctl status openvpn@client.service fonctionne)
Mais quelles sont les règles à respecter pour utiliser systemd avec 
OpenVPN ?


Celles des développeurs DEBIAN, donc dans /etc/openvpn


$ sudo journalctl -xe
[...]
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In 
[CMD-LINE]:1: Error opening configuration file: /etc/openvpn/client.conf

[...]


Dit la même chose, il cherche dans /etc/openvpn

Pouvez-vous me recommander un document de référence sur systemd que je 
me mette au niveau ?

Et, s'il existe, un document sur OpenVPN avec systemd ?


Comprendre systemd suffit. Voir dans 
/etc/systemd/system/multi-user.target.wants/openvpn.service et on 
trouvera /etc/openvpn comme working directory, ce qui rejoint init


[...]

A un moment, il faut rationnaliser et s'en tenir à un mécanisme robuste !
systemd continue a gérer la manière init (combien de temps?) afin de 
faciliter la transition.


--
Daniel

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

PS :
Quand j'éteins ma machine en Jessie (shutdown), elle disparaît _instantanément_ 
du serveur OpenVPN.

Sur la machine en Stretch, quand je lance le client OpenVPN manuellement avec 
la commande 
$ sudo openvpn maconfig.conf 
le serveur l'enregistre immédiatement, et un Ctrl-C le fait disparaître 
_instantanément_ de sclients authentifiés par le serveur.

-> J'en conclue que mon serveur OpenVPN a un comportement acceptable.
 
Avec systemctl ET avec service, sur la machine en Stretch (qui me pose 
problème), il y a bien une gestion "automatique" mystérieuse du client OpenVPN.

Comment faire pour arriver à reproduire le comportement simple, naturel et 
reproductible avec ces outils de gestion de service ? (censés nous simplifier 
la vie)

Re: OpenVPN sous Stretch avec systemd

[roger . tarani]

Merci. 


Roger dit : 


Je fais fonctionner sans souci un client OpenVPN sous Jessie. 
Manuellement ou automatiquement. 

Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de 
systemd). 
Je peux lancer le client OpenVPN en CLI 
$ sudo openvpn client.conf 
Et Ctrl-C pour interrompre. 



Daniel dit : 
sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client 

Roger dit : 
seule la commande suivante fonctionne (voir plus bas): 
$ sudo systemctl start openvpn 



Roger dit : 


En cherchant, j'ai réglé le problème de la façon suivante : 
$ cat /etc/default/openvpn 
... 
AUTOSTART="all" 
... 
Cette ligne est commentée par défaut. 

Puis, comme indiqué dans ce même fichier : 

$ sudo systemctl daemon-reload 
$ sudo systemctl restart openvpn 

Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et 
d'hibernation). 

Il reste cependant deux problèmes à régler : 
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme 
la machine Jessie dont l'IP est la même que toute machine qui s'y trouve). 
Je ne sais pas comment faire ? : oú dois-je chercher ? 



Daniel dit : 
systemctl ne joue en rien sur le routage, le problème doit venir d'autre part 
sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient 
conformes 
sudo ip r pour afficher les routes et vérifier qu'elles soient conformes 


Roger dit : 
ifconfig n'est plus dans Stretch. Alors j'utilise la commande ip 
Peux-tu préciser ce que tu entends par "conformes" ? 
Voilà ce que j'obtiens : 
$ ip r 
default via 212.27.38.253 dev tun0 
 via 192.168.0.1 dev wlp32s0 
169.254.0.0/16 dev tun0 scope link metric 1000 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 
192.168.0.0/24 dev wlp32s0 proto kernel scope link src 192.168.0.102 metric 600 
192.168.27.64/27 via 212.27.38.253 dev tun0 
212.27.38.253 dev tun0 proto kernel scope link src 192.168.27.68 

Ça vous parle ? 
Je cherche une solution pour cet autre problème de routage. 



Roger dit : 


2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de 
reconnexion "sauvage" du client alors que le serveur voit le client connecté 
déclenche une trentaine de transactions "Failed" pendant quelques minutes et 
puis ça finit par aboutir. Pendant ce temps là, pas de réseau du tout. 
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec 
systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter) 



Daniel dit : 
sudo systemctl stop openvpn@client 
sudo systemctl start openvpn@client 
ou sudo systemctl restart openvpn@client 

Roger dit : 
$ sudo systemctl start openvpn 
fonctionne 
mais il y a un problème avec : 
$ sudo systemctl start openvpn@client 
Job for openvpn@client.service failed because the control process exited with 
error code. 
See "systemctl status openvpn@client.service" and "journalctl -xe" for details. 


$ sudo systemctl status openvpn@client.service 
● openvpn@client.service - OpenVPN connection to client 
Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled; vendor preset: 
enabled) 
Active: failed (Result: exit-code) since Sat 2018-09-08 21:06:04 CEST; 10min 
ago 
Docs: man:openvpn(8) 
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage 
https://community.openvpn.net/openvpn/wiki/HOWTO 
Process: 924 ExecStart=/usr/sbin/openvpn --daemon ovpn-client --status 
/run/openvpn/client.status 10 --cd /etc/openvpn --config 
/etc/openvpn/client.conf --writepid /run/openvpn/client.pid (code=exited, 
status=1/FAILURE) 

Sep 08 21:06:04 debian systemd[1]: Starting OpenVPN connection to client... 
Sep 08 21:06:04 debian ovpn-client[924]: Options error: In [CMD-LINE]:1: Error 
opening configuration file: /etc/openvpn/client.conf 
Sep 08 21:06:04 debian ovpn-client[924]: Use --help for more information. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Control process 
exited, code=exited status=1 
Sep 08 21:06:04 debian systemd[1]: Failed to start OpenVPN connection to 
client. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Unit entered failed 
state. 
Sep 08 21:06:04 debian systemd[1]: openvpn@client.service: Failed with result 
'exit-code'. 


CONSTAT INTERESSANT : 
systemd cherche à utiliser /etc/openvpn/client.conf (avec le nom client.conf) 
qui n'existe pas puisque j'ai le fichier de configuration suivant : 
/etc/openvpn/ client /config_openvpn_routed_debian.conf 

Je peux bricoler en copiant mon fichier de configuration client ici avec ce nom 
client.conf (j'ai fait le test : et la commande $ sudo systemctl status 
openvpn@client.service fonctionne ) 
Mais quelles sont les règles à respecter pour utiliser systemd avec OpenVPN ? 


$ sudo journalctl -xe 
Sep 08 21:06:04 debian sudo[921]: truc : TTY=pts/6 ; PWD=/etc/openvpn/client ; 
USER=root ; COMMAND=/bin/systemctl start openvpn@client 
Sep 08 21:06:04 debian sudo[921]: pam_unix(sudo:session): session opened for 
user root by (uid=0) 
Sep 08 

Re: OpenVPN sous Stretch avec systemd

[daniel huhardeaux]

Le 08/09/2018 à 14:40, roger.tar...@free.fr a écrit :

Salut


Bonjour



Je fais fonctionner sans souci un client OpenVPN sous Jessie.
  Manuellement ou automatiquement.

Sous Stretch, qui utilise systemd, j'ai des problèmes (par méconnaissance de 
systemd).
Je peux lancer le client OpenVPN en CLI
$ sudo openvpn client.conf
Et Ctrl-C pour interrompre.


sudo systemctl start openvpn ou openvpn@client pour ne lancer que ce client



En cherchant, j'ai réglé le problème de la façon suivante :
$ cat /etc/default/openvpn
...
AUTOSTART="all"
...
Cette ligne est commentée par défaut.

Puis, comme indiqué dans ce même fichier :

$ sudo systemctl daemon-reload
$ sudo systemctl restart openvpn

Et là, ça fonctionne immédiatement (je n'ai pas essayé la sortie de veille et 
d'hibernation).

Il reste cependant deux problèmes à régler :
1/ je n'ai plus accès à internet via le lien où se trouve le serveur VPN (comme 
la machine Jessie dont l'IP est la même que toute machine qui s'y trouve).
Je ne sais pas comment faire ? : oú dois-je chercher ?


systemctl ne joue en rien sur le routage, le problème doit venir d'autre 
part


sudo ifconfig pour afficher les interfaces et vérifier qu'elles soient 
conformes

sudo ip r pour afficher les routes et vérifier qu'elles soient conformes


2/ ça crée un problème causé en fait par le serveur OpenVPN : la tentative de reconnexion 
"sauvage" du client alors que le serveur voit le client connecté déclenche une trentaine 
de transactions "Failed" pendant quelques minutes et puis ça finit par aboutir. Pendant 
ce temps là, pas de réseau du tout.
Comment gérer proprement la connexion et la déconnexion du client OpenVPN avec 
systemd (si connecté, utiliser la cnx VPN ; sinon, se connecter)

sudo systemctl stop openvpn@client
sudo systemctl start openvpn@client
ou sudo systemctl restart openvpn@client

--
Daniel

Re: OpenVPN & Debian Stretch

[Wayne Sallee]

Thanks.

I'll install openvpn, and easy-rsa on a test computer and see what it does, 
before installing it on my server.

Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com

On 09/05/2018 08:51 AM, Dan Ritter wrote:

easy-rsa is basically a series of scripts to get openssl to do
the right thing for you, consistently.

Re: OpenVPN & Debian Stretch

[Wayne Sallee]

On 09/05/2018 08:51 AM, Dan Ritter wrote:

On Wed, Sep 05, 2018 at 06:56:44AM -0400, Wayne Sallee wrote:


On 09/05/2018 06:30 AM, Dan Purgert wrote:

Dan Ritter wrote:

On Wed, Sep 05, 2018 at 12:29:02AM -, Dan Purgert wrote:

Dan Ritter wrote:

On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:

Has anyone set up OpenVPN with ssh-keygen -t rsa ?


Technically, you can do that.

ssh-keygen generates ssh keys, not x.509 certificates ...

An x.509 cert contains an RSA key signed by a CA. openssl can do
the signing, at which point you've half-reimplemented easy-rsa.

-dsr-

Sure - but it just seems silly to use ssh-keygen, then openssl to
convert it to the right format when openssl (or the easy-rsa wrapper
thereto) can do all the work for you in one go.



Ok, then it would be better to use openssl instead of ssh-keygen?

I'm looking at putting OpenVPN on an established server, and wondering if it
is really nessesary to install easy-rsa when I already have established ways
of generating ssh keys.

easy-rsa is basically a series of scripts to get openssl to do
the right thing for you, consistently.

Do that.

Alternatively, look into installing wireguard from unstable. (It
won't drag in anything weird.) Wireguard matches your conception
of how a VPN should work -- and is currently being integrated
into the Linux kernel, because practically everybody likes it
better than OpenVPN, and most people prefer it to IPsec.

-dsr-




Thanks for the tip about wireguard. It's still beta, but it looks promising.

Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com

Re: OpenVPN & Debian Stretch

[deloptes]

Wayne Sallee wrote:

> I will also be installing OpenVPN on Debian Stretch (Debian 9). What
> problems are you having?

go for installation - there are no problems discussed here - only how one
should generate the certificate for the client.

The easy-rsa is a set of scripts that makes generation of client
certificates really easy. You may need however to read some good how to. I
used the debians howto : https://wiki.debian.org/OpenVPN

it was may be 7 or 8y ago - the how to is now even better

regards

Re: OpenVPN & Debian Stretch

[Dan Ritter]

On Wed, Sep 05, 2018 at 06:56:44AM -0400, Wayne Sallee wrote:
> 
> 
> On 09/05/2018 06:30 AM, Dan Purgert wrote:
> > Dan Ritter wrote:
> > > On Wed, Sep 05, 2018 at 12:29:02AM -, Dan Purgert wrote:
> > > > Dan Ritter wrote:
> > > > > On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:
> > > > > > Has anyone set up OpenVPN with ssh-keygen -t rsa ?
> > > > > > 
> > > > > Technically, you can do that.
> > > > ssh-keygen generates ssh keys, not x.509 certificates ...
> > > An x.509 cert contains an RSA key signed by a CA. openssl can do
> > > the signing, at which point you've half-reimplemented easy-rsa.
> > > 
> > > -dsr-
> > Sure - but it just seems silly to use ssh-keygen, then openssl to
> > convert it to the right format when openssl (or the easy-rsa wrapper
> > thereto) can do all the work for you in one go.
> > 
> > 
> Ok, then it would be better to use openssl instead of ssh-keygen?
> 
> I'm looking at putting OpenVPN on an established server, and wondering if it
> is really nessesary to install easy-rsa when I already have established ways
> of generating ssh keys.

easy-rsa is basically a series of scripts to get openssl to do
the right thing for you, consistently.

Do that.

Alternatively, look into installing wireguard from unstable. (It
won't drag in anything weird.) Wireguard matches your conception
of how a VPN should work -- and is currently being integrated
into the Linux kernel, because practically everybody likes it
better than OpenVPN, and most people prefer it to IPsec.

-dsr-

Re: OpenVPN & Debian Stretch

[Wayne Sallee]

On 09/04/2018 06:47 PM, Josh W. wrote:

Debian Users,
 I am having a terrible time setting up a free VPN Service! Could "Any Body" point me to an UP To Date way. to 
set up OpenVPN on Debian Stretch? Your Help is Much Needed!!! Thank you!


Joshua mailto:joshw8...@gmail.com>>


I will also be installing OpenVPN on Debian Stretch (Debian 9). What problems 
are you having?

Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com

Re: OpenVPN & Debian Stretch

[Wayne Sallee]

On 09/05/2018 06:30 AM, Dan Purgert wrote:

Dan Ritter wrote:

On Wed, Sep 05, 2018 at 12:29:02AM -, Dan Purgert wrote:

Dan Ritter wrote:

On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:

Has anyone set up OpenVPN with ssh-keygen -t rsa ?


Technically, you can do that.

ssh-keygen generates ssh keys, not x.509 certificates ...

An x.509 cert contains an RSA key signed by a CA. openssl can do
the signing, at which point you've half-reimplemented easy-rsa.

-dsr-

Sure - but it just seems silly to use ssh-keygen, then openssl to
convert it to the right format when openssl (or the easy-rsa wrapper
thereto) can do all the work for you in one go.



Ok, then it would be better to use openssl instead of ssh-keygen?

I'm looking at putting OpenVPN on an established server, and wondering if it is really nessesary to install easy-rsa 
when I already have established ways of generating ssh keys.


Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com

Re: OpenVPN & Debian Stretch

[Dan Purgert]

Dan Ritter wrote:
> On Wed, Sep 05, 2018 at 12:29:02AM -, Dan Purgert wrote:
>> Dan Ritter wrote:
>> > On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:
>> >> Has anyone set up OpenVPN with ssh-keygen -t rsa ?
>> >> 
>> >
>> > Technically, you can do that.
>> 
>> ssh-keygen generates ssh keys, not x.509 certificates ... 
>
> An x.509 cert contains an RSA key signed by a CA. openssl can do
> the signing, at which point you've half-reimplemented easy-rsa.
>
> -dsr-

Sure - but it just seems silly to use ssh-keygen, then openssl to
convert it to the right format when openssl (or the easy-rsa wrapper
thereto) can do all the work for you in one go.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: OpenVPN & Debian Stretch

[Dan Ritter]

On Wed, Sep 05, 2018 at 12:29:02AM -, Dan Purgert wrote:
> Dan Ritter wrote:
> > On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:
> >> Has anyone set up OpenVPN with ssh-keygen -t rsa ?
> >> 
> >
> > Technically, you can do that.
> 
> ssh-keygen generates ssh keys, not x.509 certificates ... 

An x.509 cert contains an RSA key signed by a CA. openssl can do
the signing, at which point you've half-reimplemented easy-rsa.

-dsr-

Re: OpenVPN & Debian Stretch

[Dan Purgert]

Dan Ritter wrote:
> On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:
>> Has anyone set up OpenVPN with ssh-keygen -t rsa ?
>> 
>
> Technically, you can do that.

ssh-keygen generates ssh keys, not x.509 certificates ... 


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: OpenVPN & Debian Stretch

[Dan Ritter]

On Tue, Sep 04, 2018 at 07:42:58PM -0400, Wayne Sallee wrote:
> Has anyone set up OpenVPN with ssh-keygen -t rsa ?
> 

Technically, you can do that.

In practice, you need to have a CA set up, of which easy-rsa is
the simplest choice.

Why? Revocation.

Let's suppose you have an SSH server. Because you are cautious,
you require SSH key auth. One day your laptop is stolen. It has
an SSH private key on it, so you go over to
~/.ssh/authorized_keys and delete the matching public key. Good, 
you have secured your server against unauthorized use of your
account.

OpenVPN doesn't do that. OpenVPN assumes that any properly
signed certificate is wonderful, and you can't get rid of one
just by removing a cert entry on your side. Instead, you need
to formally revoke the certificate, and keep it revoked until 
it reaches its expiration date.

https://community.openvpn.net/openvpn/wiki/Hardening

-dsr-

Re: OpenVPN & Debian Stretch

[Wayne Sallee]

Has anyone set up OpenVPN with ssh-keygen -t rsa ?

Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com


On 09/04/2018 07:34 PM, Dan Purgert wrote:

Josh W. wrote:

Debian Users,
  I am having a terrible time setting up a free VPN Service! Could
"Any Body" point me to an UP To Date way. to set up OpenVPN on Debian
Stretch? Your Help is Much Needed!!! Thank you!

Joshua 


apt-get install openvpn-server

Should be enough to get the server going with bogus certs.  Then you
just have to generate yourself some certs to use (CA, Server, and
Client(s)).

I think the generally easy approach to the cert generation is easy-rsa
(which is a separate package these days).

Re: OpenVPN & Debian Stretch

[Dan Purgert]

Josh W. wrote:
> Debian Users,
>  I am having a terrible time setting up a free VPN Service! Could
> "Any Body" point me to an UP To Date way. to set up OpenVPN on Debian
> Stretch? Your Help is Much Needed!!! Thank you!
>
> Joshua 
>
apt-get install openvpn-server 

Should be enough to get the server going with bogus certs.  Then you
just have to generate yourself some certs to use (CA, Server, and
Client(s)).

I think the generally easy approach to the cert generation is easy-rsa
(which is a separate package these days).

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: OpenVPN & Debian Stretch

[Dan Ritter]

On Tue, Sep 04, 2018 at 05:47:37PM -0500, Josh W. wrote:
> Debian Users,
>  I am having a terrible time setting up a free VPN Service! Could
> "Any Body" point me to an UP To Date way. to set up OpenVPN on Debian
> Stretch? Your Help is Much Needed!!! Thank you!

sudo apt install openvpn easy-rsa

Then follow basically any configuration guide.

-dsr-

Re: OpenVPN fonctionne mais "service openvpn status" affiche active (exited) [RESOLU]

[Olivier]

Le 13 août 2018 à 16:38, Olivier  a écrit :

> Bonjour,
>
> J'ai l'habitude de vérifier l'état courant d'un daemon avec la commande
> service.
>
> Sur plusieurs clients OpenVPN sous Stretch ou Jessie, j'ai:
>
> # service openvpn status
> ● openvpn.service - OpenVPN service
>Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor
> preset: enabled)
>Active: active (exited) since Mon 2018-08-13 16:20:25 CEST; 7min ago
>   Process: 6959 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
>  Main PID: 6959 (code=exited, status=0/SUCCESS)
>
> août 13 16:20:25 foo-dev systemd[1]: Starting OpenVPN service...
> août 13 16:20:25 foo-dev systemd[1]: Started OpenVPN service.
>
> Pourtant, le client OpenVPN fonctionne (je peux m'y connecter, la commande
> ip link montre un lien tun0, ...).
>
>
> Qu'en pensez-vous ? Que suggérez-vous ?
>
> Slts
>
>
>
Comme OpenVPN permet le lancement de plusieurs instances définies par un
fichier /etc/openvpn/client1.conf, la commande ci-après donne le résultat
escompté:

service openvpn@client1 status

J'espère que cette réponse sera utile à d'autres.

Re: OpenVPN dhcp

[Roberto C . Sánchez]

On Sat, Jul 28, 2018 at 02:06:46PM -0400, Jim Popovitch wrote:
> 
> Heck, it took NM
> something like 7 years to fix the flood of wifi events that hit
> .xsession-errors and filled up /home partitions, so don't hold your
> breath on this issue being resolved before Sid hits stable.
> 
That is a comically roundabout away of saying "never" ;-)

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: OpenVPN dhcp

[Jim Popovitch]

On Sat, 2018-07-28 at 19:31 +0200, Erwan David wrote:
> 
> 
> Does not seem to work for DNS pushed by the VPN server...
> 

A less pertinent bit was on another page that said you also need to add
the following lines to your client.ovpn before importing into
NetworkManager.

  script-security 2
  up /etc/openvpn/update-resolv-conf
  down /etc/openvpn/update-resolv-conf


So, delete your VPN profile, re-import the new client.ovpn, edit
/etc/NetworkManager/system-connections/, run the nmcli
command, toggle VPN.

Apparently all of this is fixed in future versions of NetworkManager
scripts that just haven't made it downstream yet.  Heck, it took NM
something like 7 years to fix the flood of wifi events that hit
.xsession-errors and filled up /home partitions, so don't hold your
breath on this issue being resolved before Sid hits stable.

hth,

-Jim P.


signature.asc
Description: This is a digitally signed message part

Re: OpenVPN dhcp

[Erwan David]

Le 07/28/18 à 18:48, Jim Popovitch a écrit :
> On Fri, 2018-07-27 at 14:52 -0400, Roberto C. Sánchez wrote:
>> The short answer is, "as long as you use NetworkManager, no."
>>
>> I no longer have the link, but some time ago I found a page that
>> explains it very clearly.
>>
>> Search terms: "openvpn networkmanager dns leak"
>>
>> Effectively, NetworkManager lacks a concept of "replace the active
>> DNS settings when this connection becomes active."  Instead, what it
>> does is add the DNS servers to those already listed.  There is
>> supposed to be a way to specify the IPv4 DNS servers (you can do this
>> in the NM gui), then you set the IPv4 DNS priority to -1 (meaning
>> clear everything else out and use these instead) by editing the text
>> configuration file.
>>
>> The problems with that, though, are the result of the -1 priority
>> appears to prevent any other connection from having IPv4 DNS servers
>> in resolv.conf.  That may or may not be a problem for you.  That
>> approach also prevents you from taking advantage of DHCP push of DNS
>> servers from the VPN server.
>>
>> I have seen some bugs requesting that they fix it, and even a commit
>> that might be what you are asking for.  However, I don't know when it
>> might make its way into a Debian stable release (or even unstable).
>>
> Roberto, thanks for the insight and recommendation, based on your
> search suggestion I found the solution here:
>
> https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/120/comments
> /92
>
> -Jim P.
>
>
Does not seem to work for DNS pushed by the VPN server...





signature.asc
Description: OpenPGP digital signature

Re: OpenVPN dhcp

[Jim Popovitch]

On Fri, 2018-07-27 at 14:52 -0400, Roberto C. Sánchez wrote:
> The short answer is, "as long as you use NetworkManager, no."
> 
> I no longer have the link, but some time ago I found a page that
> explains it very clearly.
> 
> Search terms: "openvpn networkmanager dns leak"
> 
> Effectively, NetworkManager lacks a concept of "replace the active
> DNS settings when this connection becomes active."  Instead, what it
> does is add the DNS servers to those already listed.  There is
> supposed to be a way to specify the IPv4 DNS servers (you can do this
> in the NM gui), then you set the IPv4 DNS priority to -1 (meaning
> clear everything else out and use these instead) by editing the text
> configuration file.
> 
> The problems with that, though, are the result of the -1 priority
> appears to prevent any other connection from having IPv4 DNS servers
> in resolv.conf.  That may or may not be a problem for you.  That
> approach also prevents you from taking advantage of DHCP push of DNS
> servers from the VPN server.
> 
> I have seen some bugs requesting that they fix it, and even a commit
> that might be what you are asking for.  However, I don't know when it
> might make its way into a Debian stable release (or even unstable).
> 

Roberto, thanks for the insight and recommendation, based on your
search suggestion I found the solution here:

https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/120/comments
/92

-Jim P.




signature.asc
Description: This is a digitally signed message part

Re: OpenVPN dhcp

[Roberto C . Sánchez]

On Fri, Jul 27, 2018 at 02:38:37PM -0400, Jim Popovitch wrote:
> Hello,
> 
> Is there a way to have an OpenVPN server push dhcp-options to the
> clients that completely replace any existing entries in
> /etc/resolv.conf?  
> 
The short answer is, "as long as you use NetworkManager, no."

I no longer have the link, but some time ago I found a page that
explains it very clearly.

Search terms: "openvpn networkmanager dns leak"

Effectively, NetworkManager lacks a concept of "replace the active DNS
settings when this connection becomes active."  Instead, what it does is
add the DNS servers to those already listed.  There is supposed to be a
way to specify the IPv4 DNS servers (you can do this in the NM gui),
then you set the IPv4 DNS priority to -1 (meaning clear everything else
out and use these instead) by editing the text configuration file.

The problems with that, though, are the result of the -1 priority
appears to prevent any other connection from having IPv4 DNS servers in
resolv.conf.  That may or may not be a problem for you.  That approach
also prevents you from taking advantage of DHCP push of DNS servers from
the VPN server.

I have seen some bugs requesting that they fix it, and even a commit
that might be what you are asking for.  However, I don't know when it
might make its way into a Debian stable release (or even unstable).

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: openvpn client DNS security

[Mark Fletcher]

On Thu, Apr 05, 2018 at 11:48:51AM +0200, Roger Price wrote:
> Hi, I had a problem setting up DNS on an openvpn client.  I'll describe it
> here before submitting a bug report - I would appreciate comment on the
> security aspects.
> 

> 
> Looking more closely at script /etc/openvpn/update-resolv-conf, it begins
> with the line
> 
>  [ -x /sbin/resolvconf ] || exit 0
> 
> File /sbin/resolvconf is not present, because package resolvconf is not a
> prerequisite for openvpn, so the script fails silently!  This looks to me
> like a serious security problem.  Joe Road-Warrior is out there, connected
> to the "free" Wifi.  He follows corporate instructions to turn on his
> openvpn client, but because of the exit 0 he is still using the local
> thoroughly compromised DNS server.
> 

apt-cache rdepends resolvconf shows a dependency of openvpn on 
openresolv, which according to apt-file provides /sbin/resolvconf (and 
also, if I am reading apt-cache output correctly, depends on 
resolvconf...)

I can only assume one of the dependencies in that stack is a "suggests" 
rather than a "depends". If you are going to report a bug probably worth 
acknowledging this so you don't get turned away at the door.

... Yep, checking apt show openvpn, resolvconf is indeed a "suggests".

Mark

Re: openvpn

[Joe]

On Mon, 23 Oct 2017 21:03:30 +0200
Pol Hallen  wrote:

> Hello all :-)
> 
> maybe I've a simple question...
> 
> I've an openvpn server 10.0.0.1/24 and a connected client (gateway):
> I use vpn to make backup.
> 
> On this client I've samba and clients in same lan can connect to it.
> 
> The problem: these clients can see also all netbios across vpn
> (10.0.0.1/24)
> 
> what I should blocks using iptables?
> 

Everything. Only allow through what you want to allow.

Alternatively, use a different method than VPN for backups. When you
say 'backup', are you simply synchronising SMB shares, or are you
making a backup file and copying it across the VPN? If the latter,
then SSH or another secure file transfer protocol can do the job
without linking the networks together fully as a VPN does.

-- 
Joe 

Re: openvpn

[mc-2]

merci à tous pour vos solutions. Je me remets au travail.

M. Clément


On 13/10/2017 22:54, G2PC wrote:

Le 13/10/2017 à 19:19, herve.thib...@free.fr a écrit :

Le 13/10/2017 à 18:49, hamster a écrit :

Le 13/10/2017 à 18:01, mc-2 a écrit :

je me remets à vos conseils pour le "how to..."

Le seul tuto VPN que je connaisse c'est celui la, mais il y a peu de
chances qu'il te soit utile parce que ton fournisseur est probablement
pas le meme.
https://wiki-adh.fdn.fr/travaux:vpn_misc:doc


Bonjour

J'ai eu le problème avec un VPN chez OVH il y a pas longtemps.

J'ai utilisé le manager de connexion. avec le fichier client.ovpn
téléchargé du serveur OVH.

Dans le manager choisir Modifications des connexions puis cliquer sur
Ajouter dans la fenêtre Connexions réseaux
Dans la fenêtre Sélectionner un type de réseau sélectionner Importer
une configuration VPN enregistrée et donner le ficher client.ovpn
enregistré
En fait j'utilise Ubuntu pour donner les titres des commandes donc
rectifier pour Debian.
Si tout se passe bien il y aura juste à saisir user name et le mot de
passe à mettre aussi dans Private key (Le type d'authentification est
pour mon cas Password with Certificate TLS)

VPN, quelques bases utiles :
https://www.visionduweb.eu/wiki/index.php?title=Utiliser_un_VPN#Autre_m.C3.A9thode_rapide_pour_utiliser_OpenVPN_avec_VPNBook

Re: openvpn

[G2PC]

Le 13/10/2017 à 19:19, herve.thib...@free.fr a écrit :
> Le 13/10/2017 à 18:49, hamster a écrit :
>> Le 13/10/2017 à 18:01, mc-2 a écrit :
>>> je me remets à vos conseils pour le "how to..."
>> Le seul tuto VPN que je connaisse c'est celui la, mais il y a peu de
>> chances qu'il te soit utile parce que ton fournisseur est probablement
>> pas le meme.
>> https://wiki-adh.fdn.fr/travaux:vpn_misc:doc
>>
> Bonjour
>
> J'ai eu le problème avec un VPN chez OVH il y a pas longtemps.
>
> J'ai utilisé le manager de connexion. avec le fichier client.ovpn
> téléchargé du serveur OVH.
>
> Dans le manager choisir Modifications des connexions puis cliquer sur
> Ajouter dans la fenêtre Connexions réseaux
> Dans la fenêtre Sélectionner un type de réseau sélectionner Importer
> une configuration VPN enregistrée et donner le ficher client.ovpn
> enregistré
> En fait j'utilise Ubuntu pour donner les titres des commandes donc
> rectifier pour Debian.
> Si tout se passe bien il y aura juste à saisir user name et le mot de
> passe à mettre aussi dans Private key (Le type d'authentification est
> pour mon cas Password with Certificate TLS)

VPN, quelques bases utiles :
https://www.visionduweb.eu/wiki/index.php?title=Utiliser_un_VPN#Autre_m.C3.A9thode_rapide_pour_utiliser_OpenVPN_avec_VPNBook

Re: openvpn

[herve.thib...@free.fr]

Le 13/10/2017 à 18:49, hamster a écrit :

Le 13/10/2017 à 18:01, mc-2 a écrit :

je me remets à vos conseils pour le "how to..."

Le seul tuto VPN que je connaisse c'est celui la, mais il y a peu de
chances qu'il te soit utile parce que ton fournisseur est probablement
pas le meme.
https://wiki-adh.fdn.fr/travaux:vpn_misc:doc


Bonjour

J'ai eu le problème avec un VPN chez OVH il y a pas longtemps.

J'ai utilisé le manager de connexion. avec le fichier client.ovpn 
téléchargé du serveur OVH.


Dans le manager choisir Modifications des connexions puis cliquer sur 
Ajouter dans la fenêtre Connexions réseaux
Dans la fenêtre Sélectionner un type de réseau sélectionner Importer une 
configuration VPN enregistrée et donner le ficher client.ovpn enregistré
En fait j'utilise Ubuntu pour donner les titres des commandes donc 
rectifier pour Debian.
Si tout se passe bien il y aura juste à saisir user name et le mot de 
passe à mettre aussi dans Private key (Le type d'authentification est 
pour mon cas Password with Certificate TLS)

Re: openvpn

[hamster]

Le 13/10/2017 à 18:01, mc-2 a écrit :
> je me remets à vos conseils pour le "how to..."

Le seul tuto VPN que je connaisse c'est celui la, mais il y a peu de
chances qu'il te soit utile parce que ton fournisseur est probablement
pas le meme.
https://wiki-adh.fdn.fr/travaux:vpn_misc:doc

Re: openvpn updates?

[Adrian Bunk]

On Tue, Jun 27, 2017 at 11:11:47AM -0400, Perry E. Metzger wrote:
> On Thu, 22 Jun 2017 23:10:21 +0300 Adrian Bunk 
> wrote:
> > On Thu, Jun 22, 2017 at 10:20:09AM -0400, Perry E. Metzger wrote:
> > > There was a security advisory against openvpn a couple of days
> > > ago;  
> > 
> > Yesterday, not a couple of days ago.
> > 
> > > just wondering when updated packages are likely to show up?  
> > 
> > unstable is already fixed.
> > 
> > stable and oldstable will be fixed soon.
> 
> Any news on this?
>...

https://lists.debian.org/debian-security-announce/2017/msg00161.html

> Perry

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: openvpn updates?

[David Wright]

On Tue 27 Jun 2017 at 12:09:47 (-0400), Perry E. Metzger wrote:
> On Tue, 27 Jun 2017 10:48:26 -0500 David Wright
>  wrote:
> > > Any news on this? Apparently this is remotely exploitable though
> > > not in ordinary configurations.  
> > 
> > In what respect do
> > 
> >  https://security-tracker.debian.org/tracker/source-package/openvpn
> > 
> > and
> > 
> >  https://tracker.debian.org/pkg/openvpn
> > 
> > let you down?
> 
> In the respect that I didn't know they existed and I could look at
> them?

OK. Perhaps your email filters were a little too aggressive and
you missed seeing Reco's post archived as

https://lists.debian.org/debian-user/2017/06/msg00905.html

Cheers,
David.

Re: openvpn updates?

[Perry E. Metzger]

On Tue, 27 Jun 2017 10:48:26 -0500 David Wright
 wrote:
> > Any news on this? Apparently this is remotely exploitable though
> > not in ordinary configurations.  
> 
> In what respect do
> 
>  https://security-tracker.debian.org/tracker/source-package/openvpn
> 
> and
> 
>  https://tracker.debian.org/pkg/openvpn
> 
> let you down?

In the respect that I didn't know they existed and I could look at
them?

Perry
-- 
Perry E. Metzgerpe...@piermont.com

Re: openvpn updates?

[David Wright]

On Tue 27 Jun 2017 at 11:11:47 (-0400), Perry E. Metzger wrote:
> On Thu, 22 Jun 2017 23:10:21 +0300 Adrian Bunk 
> wrote:
> > On Thu, Jun 22, 2017 at 10:20:09AM -0400, Perry E. Metzger wrote:
> > > There was a security advisory against openvpn a couple of days
> > > ago;  
> > 
> > Yesterday, not a couple of days ago.
> > 
> > > just wondering when updated packages are likely to show up?  
> > 
> > unstable is already fixed.
> > 
> > stable and oldstable will be fixed soon.
> 
> Any news on this? Apparently this is remotely exploitable though not
> in ordinary configurations.

In what respect do

 https://security-tracker.debian.org/tracker/source-package/openvpn

and

 https://tracker.debian.org/pkg/openvpn

let you down?

Cheers,
David.

Re: openvpn updates?

[Perry E. Metzger]

On Thu, 22 Jun 2017 23:10:21 +0300 Adrian Bunk 
wrote:
> On Thu, Jun 22, 2017 at 10:20:09AM -0400, Perry E. Metzger wrote:
> > There was a security advisory against openvpn a couple of days
> > ago;  
> 
> Yesterday, not a couple of days ago.
> 
> > just wondering when updated packages are likely to show up?  
> 
> unstable is already fixed.
> 
> stable and oldstable will be fixed soon.

Any news on this? Apparently this is remotely exploitable though not
in ordinary configurations.

Perry
-- 
Perry E. Metzgerpe...@piermont.com