Re: [network-manager-openvpn] Problem adding vpn file from my provider FrootVPN.

[Beniamino Galvani]

On Thu, Oct 27, 2016 at 08:15:20PM +0200, Vicente Herrera Cobo wrote:
> Regards to all,
> 
> by adding a specified ovpn file from my provider get the following
> error: "Error: configuration error: unsupported blob/xml element (line
> 104)."
> 
> Line 104: ""

Hi,

at the moment the openvpn plugin doesn't support 
profiles. I've filed a bug [1] to track this issue and hopefully
it will be implemented soon (patches are always welcome!).

Beniamino

[1] https://bugzilla.gnome.org/show_bug.cgi?id=773623


signature.asc
Description: PGP signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[network-manager-openvpn] Problem adding vpn file from my provider FrootVPN.

[Vicente Herrera Cobo]

Regards to all,

by adding a specified ovpn file from my provider get the following
error: "Error: configuration error: unsupported blob/xml element (line
104)."

Line 104: ""

Attachment screenshot and ovpn file.

Thanks for your attention.
client
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
ns-cert-type server
cipher AES-256-CBC
auth SHA384
server-poll-timeout 3

-BEGIN CERTIFICATE-
MIIEwTCCA6mgAwIBAgIJANtGjxbsxYjTMA0GCSqGSIb3DQEBBQUAMIGbMQswCQYD
VQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8GA1UE
ChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFuZ2Vt
ZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5k
b21haW4wHhcNMTQwNTA5MjEwMjIxWhcNMjQwNTA2MjEwMjIxWjCBmzELMAkGA1UE
BhMCU0UxCzAJBgNVBAgTAlFRMRIwEAYDVQQHEwlGcm9vdFRvd24xETAPBgNVBAoT
CEZyb290T3JnMREwDwYDVQQLEwhjaGFuZ2VtZTERMA8GA1UEAxMIY2hhbmdlbWUx
ETAPBgNVBCkTCGNoYW5nZW1lMR8wHQYJKoZIhvcNAQkBFhBtYWlsQGhvc3QuZG9t
YWluMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvjn066eoAeLZdypK
u2parz/ZLyoiTvzR9zfysLn3gLRp9DZjLmdWw5CSdJHou9n2mS/Mgtk76VgwrwKu
I8lg6fAdvGBLZ3CaTUz4qpsCIBoJtfZGO4ipSFK1SEytFX1TvD9GgMAJIqk4ixxF
+wyGahmB01BvVewdYBvUyHwFgPELiPqrNZ0rrx2WyFNHqlqeBWcTxjG3rWL4wG9W
rK5d2QWymlU4309XYTuVuT001eM1zbSjkmLKhFfvBOWP5XmopBBPy3Q5rqzGJCO4
qrgIvtxYBidgPDSI4AXZQevFzMCs5zZqVQkkQOZ/3IKN4Odji4wNf7Ncg30ZpYCv
kSPSgwIDAQABo4IBBDCCAQAwHQYDVR0OBBYEFJnNEWNacY+/pBIcRkrKn9jBiSFr
MIHQBgNVHSMEgcgwgcWAFJnNEWNacY+/pBIcRkrKn9jBiSFroYGhpIGeMIGbMQsw
CQYDVQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8G
A1UEChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFu
Z2VtZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9z
dC5kb21haW6CCQDbRo8W7MWI0zAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4IBAQA/cd7eXInNxSoZMZNLmwP54defRQDclqpRVigUdZppoY/FSq6zCOMjn386
RYhk3wmkl5Retw9wIUNYNmB+3TikBeT5eMCGws/pxGIPELPcYDmVE9hete5EIRX/
1seLzzcLSjg/M+9DOt8tvUPcY8U+JIWU5PICYFQUU7K3BcNICVWIlsus3ilqkbqe
vBHDrs5Z6FQEm1EEYYCtiM3NeZ/GhfgIfVh2x8Tylgsck6s/DKHGi6lAycKMBo1C
yuZl5Gl/pQK76QzxO/p6hzLLRdYec8WQRX4DxpvpNAnLkpryt7XmxzSg8XPTqyN4
r5CdYXeKObGdzsQNY3AxLKsnNuPG
-END CERTIFICATE-


-BEGIN CERTIFICATE-
MIIFBTCCA+2gAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBmzELMAkGA1UEBhMCU0Ux
CzAJBgNVBAgTAlFRMRIwEAYDVQQHEwlGcm9vdFRvd24xETAPBgNVBAoTCEZyb290
T3JnMREwDwYDVQQLEwhjaGFuZ2VtZTERMA8GA1UEAxMIY2hhbmdlbWUxETAPBgNV
BCkTCGNoYW5nZW1lMR8wHQYJKoZIhvcNAQkBFhBtYWlsQGhvc3QuZG9tYWluMB4X
DTE0MDYxNDE3NTMwNloXDTI0MDYxMTE3NTMwNlowgZkxCzAJBgNVBAYTAlNFMQsw
CQYDVQQIEwJRUTESMBAGA1UEBxMJRnJvb3RUb3duMREwDwYDVQQKEwhGcm9vdE9y
ZzERMA8GA1UECxMIY2hhbmdlbWUxDzANBgNVBAMTBmNsaWVudDERMA8GA1UEKRMI
Y2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5kb21haW4wggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDftRDk9EbrSEH2gAuSeBUiQXHECZ/K
flM1tWRo4DMwNsXuMM5WnqPln38svypE9a5BKGO8ZEsM5LAfOik5yPYcLGilslYs
bowcRsnnrhOkPp2AJDrZzcJCXjdQsCDpapErCzyon58T6Vuc27TW369cUTk40Hz3
uBOkYNMmYqhePu3EwKXzMjy8o0qaFlO+8Y6qNEPv8AGhljIwo0Q70xQjDrNxwSBM
vKnYOvjtvH0HlgXYWTQ7Y8/hy8wUnJZg3UX/+7TC2ks+sj3wSDB4CyU+v9lauChq
frdJR2ziXXi/b/CNNfDuuqAWya70/ABdsfG0E583jPxh7VuwnrYrbm51AgMBAAGj
ggFSMIIBTjAJBgNVHRMEAjAAMC0GCWCGSAGG+EIBDQQgFh5FYXN5LVJTQSBHZW5l
cmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMpYLs4OTz/0wAm7TB1wwZAOkmDg
MIHQBgNVHSMEgcgwgcWAFJnNEWNacY+/pBIcRkrKn9jBiSFroYGhpIGeMIGbMQsw
CQYDVQQGEwJTRTELMAkGA1UECBMCUVExEjAQBgNVBAcTCUZyb290VG93bjERMA8G
A1UEChMIRnJvb3RPcmcxETAPBgNVBAsTCGNoYW5nZW1lMREwDwYDVQQDEwhjaGFu
Z2VtZTERMA8GA1UEKRMIY2hhbmdlbWUxHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9z
dC5kb21haW6CCQDbRo8W7MWI0zATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8E
BAMCB4AwDQYJKoZIhvcNAQEFBQADggEBAITvsT/pdb8nPmMRnawoJcp7R9fGE1dE
jtrF2w96V0kTAy5Jrkiss6ilJXz/56pSoM4vk5XIMhUPWOP2Q0Or+b3EMGuEDRWT
3FTxz5p+eTYDaGwA6mR54M3s4A7pXAB+zgHrbKIAY5EgYQ4kimh1ILDcZm4AJxHZ
6gsijNKVo7bfVqZxysvQgG0JYmj9fvrV449DKUhR7/fHalnHI1EqS8P/OLjqq8jb
/XE8/LT7fj6UklBJ9yYOO0Co4kFlgZ4hYLm8k7ccj12vMcvR/sw9f9t66v64lPin
pcrFLwaO6Nymr4oC8q57w5flTct1aNYuqmXLbZF7D7QpSu5p/HYECl8=
-END CERTIFICATE-


-BEGIN PRIVATE KEY-
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDftRDk9EbrSEH2
gAuSeBUiQXHECZ/KflM1tWRo4DMwNsXuMM5WnqPln38svypE9a5BKGO8ZEsM5LAf
Oik5yPYcLGilslYsbowcRsnnrhOkPp2AJDrZzcJCXjdQsCDpapErCzyon58T6Vuc
27TW369cUTk40Hz3uBOkYNMmYqhePu3EwKXzMjy8o0qaFlO+8Y6qNEPv8AGhljIw
o0Q70xQjDrNxwSBMvKnYOvjtvH0HlgXYWTQ7Y8/hy8wUnJZg3UX/+7TC2ks+sj3w
SDB4CyU+v9lauChqfrdJR2ziXXi/b/CNNfDuuqAWya70/ABdsfG0E583jPxh7Vuw
nrYrbm51AgMBAAECggEADOgAWoUxVj+r9pG6mS+uYHSQILRBcMhK+q1FZruQmHaA
gtZ0ARFT+VpzVtyMjr/x1raC0oqivdKvyo1rdXb/o+539x9L03JpSPRYj7I+Vdp6
8bqlXo19aKDQ5inTLERGrcoPLNdQsTBkZa9TRpZPIq9Y8ssseoo3L+OaKvvEJPO2
0nv9un2kfPU/JvN2taV6D/6atEmXDIMIXumTJCSCfU2hq513nZjEVccS691Oug87
siKi5NyqNloq6iinVLvhSGOQ+gt68iZ0G1McH2jnJIXnpRXM0UpjMAYtfRYUh6ow
4bOxHxcTf6UCt0rY1KwSfjS/hd7NFgqcuzwEM6yXfQKBgQD8v0NtnW2AUE32uvDd
Et67Wg5p3w4cRZZ2wXQvsoyuotBS+deo8CN113bdYJel3CtqdxdTkY20j5Xmf2sq
NkBE+lGMfSxLph40bqIUEQ4dp4EXsVOwz1XeNmGYAwQ2PRGZ+H3QrEjZOcrqKLTI
uvy+MuV6vGWFdkdH6esenhr5ZwKBgQDilh+zzMWvc1M4o9xuROAh9ObE8t5I4bb0
g9aVZtX1zBE309lEx8CuUAXwbRpfpFgBDQHkfS38PhNqeC0OXbe/Qq3J6j6Nq5Ou
Y00uceMyJk6FVeEwpJ/

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Dan Williams

> I poked at this today, using this config and your openvpn-2.4.0 RPMs:
> 
> [...]
> 
> but got no response from the server.  Is it still up and configured?
> I've at least verified that the NM-openvpn IPv6 changes don't cause
> problems for my existing openvpn configurations, so that's progress at
> least.

Yes, it's still up. I think the problem is that you're missing
"proto-tcp=yes". (Also, if you want to test IPv6 transport you'd need to
use "remote=greed.fud.no" rather than "remote=87.238.35.145", and
obviously have IPv6 connectivity where you are.)

Finally I have "never-default=true" under both [ipv4] and [ipv6].

BTW the server now also advertises a (working) DNS resolver at
10.20.30.40. (I plan on looking a bit more into bgo#710699.)

Tore
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Williams]

On Wed, 2013-12-18 at 01:04 +0100, Tore Anderson wrote:
> * Tore Anderson
> 
> > I'm working on setting up a test VPN server where I can reproduce it and
> > generate a backtrace to share (I don't dare to do that towards my
> > employer's VPN server).
> 
> Ok, so now I have a dual-stacked OpenVPN test server running and I've
> reproduced the problem there. It's all F20 RPMs, except that Nicolas
> Iooss' patches was applied on top of NetworkManager-openvpn[-gnome].
> 
> I've attached the backtrace that ABRT grabbed after the crash happened.
> 
> In case you or anyone else want to reproduce it, the test server is
> greed.fud.no (87.238.35.145, 2a02:c0:1001:100::145), port 1194/tcp, LZO
> compression enabled. It pushes two routes: 10.20.30.0/24 and
> 2001:db8:1::/64. 10.20.30.40 and 2001:db8:1::1 should respond to pings
> via the tunnel. Use the sample certificates included with OpenVPN - also
> available at http://fud.no/nm-openvpn-ipv6/ along with the server's
> config file. Prebuilt F20 RPMs of NetworkManager-openvpn[-gnome] with
> the IPv6 patches applied are also found there.

I poked at this today, using this config and your openvpn-2.4.0 RPMs:

[connection]
id=openvpn IPv6
uuid=3c0ca914-7855-4dc1-9d55-2eea4050ecb3
type=vpn
autoconnect=false

[vpn]
service-type=org.freedesktop.NetworkManager.openvpn
comp-lzo=yes
remote=87.238.35.145
ca=/usr/share/doc/openvpn/sample/sample-keys/ca.crt
cert=/usr/share/doc/openvpn/sample/sample-keys/client.crt
connection-type=tls
cert-pass-flags=0
key=/usr/share/doc/openvpn/sample/sample-keys/client.key

[ipv6]
method=auto

[ipv4]
method=auto

but got no response from the server.  Is it still up and configured?
I've at least verified that the NM-openvpn IPv6 changes don't cause
problems for my existing openvpn configurations, so that's progress at
least.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Nicolas Iooss]

Hello,

I've been quite busy last week so it took me some time to update my Network
Manager setup to the latest git revision, reproduce the bug, investigate,
and change the patches. Tonight I've added 3 comments to
https://bugzilla.gnome.org/show_bug.cgi?id=682620: the coredump backtrace
of the assertion failure I get, an analysis of what's going wrong in NM and
a patch which updates
0001-service-pass-IPv6-related-information-to-NM.patch. I've tested this
new patch with my OpenVPN server and it is working fine: IPv6 "Internal
Point-to-Point Address" (NM_VPN_PLUGIN_IP6_CONFIG_PTP) seems to be useless
here.

By the way, OpenConnect VPN plugin may have the same bug because
https://git.gnome.org/browse/network-manager-openconnect/tree/src/nm-openconnect-service-openconnect-helper.c?id=80493c029d21712f68c4c1372f2a98cb8450a045#n599
also
uses NM_VPN_PLUGIN_IP6_CONFIG_PTP, but I don't know what's better between
removing code in every VPN plugin (like I did) or patching NetworkManager
to ignore this option which is not supported by libnl.

Regards,

Nicolas

PS: my patches are also available on GitHub,
https://github.com/fishilico/network-manager-openvpn/commits/master


2013/12/18 Tore Anderson :
> * Tore Anderson
>
>> I'm working on setting up a test VPN server where I can reproduce it and
>> generate a backtrace to share (I don't dare to do that towards my
>> employer's VPN server).
>
> Ok, so now I have a dual-stacked OpenVPN test server running and I've
> reproduced the problem there. It's all F20 RPMs, except that Nicolas
> Iooss' patches was applied on top of NetworkManager-openvpn[-gnome].
>
> I've attached the backtrace that ABRT grabbed after the crash happened.
>
> In case you or anyone else want to reproduce it, the test server is
> greed.fud.no (87.238.35.145, 2a02:c0:1001:100::145), port 1194/tcp, LZO
> compression enabled. It pushes two routes: 10.20.30.0/24 and
> 2001:db8:1::/64. 10.20.30.40 and 2001:db8:1::1 should respond to pings
> via the tunnel. Use the sample certificates included with OpenVPN - also
> available at http://fud.no/nm-openvpn-ipv6/ along with the server's
> config file. Prebuilt F20 RPMs of NetworkManager-openvpn[-gnome] with
> the IPv6 patches applied are also found there.
>
> Tpre
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Tore Anderson

> I'm working on setting up a test VPN server where I can reproduce it and
> generate a backtrace to share (I don't dare to do that towards my
> employer's VPN server).

Ok, so now I have a dual-stacked OpenVPN test server running and I've
reproduced the problem there. It's all F20 RPMs, except that Nicolas
Iooss' patches was applied on top of NetworkManager-openvpn[-gnome].

I've attached the backtrace that ABRT grabbed after the crash happened.

In case you or anyone else want to reproduce it, the test server is
greed.fud.no (87.238.35.145, 2a02:c0:1001:100::145), port 1194/tcp, LZO
compression enabled. It pushes two routes: 10.20.30.0/24 and
2001:db8:1::/64. 10.20.30.40 and 2001:db8:1::1 should respond to pings
via the tunnel. Use the sample certificates included with OpenVPN - also
available at http://fud.no/nm-openvpn-ipv6/ along with the server's
config file. Prebuilt F20 RPMs of NetworkManager-openvpn[-gnome] with
the IPv6 patches applied are also found there.

Tpre
[New LWP 656]
[New LWP 665]
[New LWP 663]
[New LWP 661]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.2-gdb.py", 
line 9, in 
from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in 
import gdb.backtrace
ImportError: No module named backtrace
Core was generated by `/usr/sbin/NetworkManager --no-daemon'.
Program terminated with signal SIGABRT, Aborted.
#0  0x7faa0150fc59 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Thread 4 (Thread 0x7fa9f9689700 (LWP 661)):
#0  0x7faa0433a4f1 in do_sigwait (sig=0x7fa9f9688dc4, set=) 
at ../sysdeps/unix/sysv/linux/sigwait.c:60
__arg4 = 8
__arg2 = 0
_a3 = 0
_a1 = 140368220941952
resultvar = 
__arg3 = 0
__arg1 = 140368220941952
_a4 = 8
_a2 = 0
ret = 
tmpset = {__val = {0, 0, 140368010582464, 140368010581760, 0, 
140368215451478, 5, 0, 0, 140368143071544, 140368010581760, 0, 0, 
140368215478725, 0, 140368191631060}}
#1  __sigwait (set=set@entry=0x7faa05f26e80 , 
sig=sig@entry=0x7fa9f9688dc4) at ../sysdeps/unix/sysv/linux/sigwait.c:97
oldtype = 0
result = 128
#2  0x7faa05c3092f in signal_handling_thread (arg=) at 
main.c:87
signo = 32681
__FUNCTION__ = "signal_handling_thread"
#3  0x7faa04332f33 in start_thread (arg=0x7fa9f9689700) at 
pthread_create.c:309
__res = 
pd = 0x7fa9f9689700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140368010581760, 
4163565797753177009, 0, 0, 140368010582464, 140368010581760, 
-4137673526678436943, -4137684980313537615}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#4  0x7faa015ceead in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 3 (Thread 0x7fa9f8c7b700 (LWP 663)):
#0  0x7faa015c4a8d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7faa01cfe5b4 in g_main_context_poll (priority=2147483647, n_fds=2, 
fds=0x7fa9f40008e0, timeout=-1, context=0x7faa07067410) at gmain.c:4007
poll_func = 0x7faa01d0d500 
#2  g_main_context_iterate (context=context@entry=0x7faa07067410, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
gmain.c:3708
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7fa9f40008e0
#3  0x7faa01cfe6dc in g_main_context_iteration (context=0x7faa07067410, 
may_block=may_block@entry=1) at gmain.c:3774
retval = 
#4  0x7faa01cfe729 in glib_worker_main (data=) at 
gmain.c:5473
No locals.
#5  0x7faa01d23a45 in g_thread_proxy (data=0x7faa0706b630) at gthread.c:798
thread = 0x7faa0706b630
#6  0x7faa04332f33 in start_thread (arg=0x7fa9f8c7b700) at 
pthread_create.c:309
__res = 
pd = 0x7fa9f8c7b700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {14036838656, 
4163565797753177009, 0, 0, 14036839360, 14036838656, 
-4137677176326896719, -4137684980313537615}, mask_was_saved = 0}}, priv = {pad 
= {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#7  0x7faa015ceead in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

Thread 2 (Thread 0x7fa9f3fff700 (LWP 665)):
#0  0x7faa015c4a8d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7faa01cfe5b4 in g_main_context_poll (priority=2147483647, n_fds=3, 
fds=0x7fa9ec0010c0, timeout=-1, context=0x7faa0707de60) at gmain.c:4

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Tore Anderson

> I'll try applying f099a04132241790c8f88a651ece49f5c2783d12 on top of it
> and will report back. Thanks!

Seems this patch is the same as one already included in the RPM:

Patch18: rh1018317-openvpn-ptp.patch

I'm working on setting up a test VPN server where I can reproduce it and
generate a backtrace to share (I don't dare to do that towards my
employer's VPN server).

Tore
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Dan Williams

>> ERROR:platform/nm-linux-platform.c:2212:build_rtnl_addr: assertion failed: 
>> (!nle)
> 
> Is that with NM git master, and if so, what date?  The reason I ask is
> because we broke PtP addresses until 2013-12-02, fixed in commit
> f099a04132241790c8f88a651ece49f5c2783d12.  The error you're getting may
> well be the kernel complaining that it cannot reach the static route,
> because it knows nothing about the next hop, because the PtP address
> wasn't assigned correctly.

The F20 RPM: NetworkManager-0.9.9.0-20.git20131003.fc20.x86_64

I'll try applying f099a04132241790c8f88a651ece49f5c2783d12 on top of it
and will report back. Thanks!

Tore

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Williams]

On Tue, 2013-12-17 at 11:57 +0100, Tore Anderson wrote:
> * Nicolas Iooss
> 
> > A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN
> > now supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager
> > doesn't support it. I found bug 682620
> > (https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented
> > some of the missing features with the help
> > of network-manager-openconnect commits (basically the IPv6 payload part,
> > not the IPv6 endpoint one). My patches are attached to this email. Can
> > someone review them and tell me what may be wrong with them? As I'm new
> > with NetworkManager, I think there must be some mistakes in my code.
> 
> Hello Nicolas,
> 
> I (and pretty much all of my colleagues) have been happily using your
> patches since they were posted with no issues. It's a shame they haven't
> been included upstream a long time ago. However, it appears that a 
> change in the version of NetworkManager or NetworkManager-openvpn
> included in Fedora 20 have broken them. When I connect to a VPN server
> that pushes IPv6 routing information, NetworkManager crashes completely.
> The crash happens even if I've set the IPv6 method on the VPN connection
> to "ignore". Also, the tunnel itself may go over IPv4, the crash still
> happens.
> 
>  VPN connection 'foo' (IP6 Config Get) reply received.
>  VPN Gateway: 192.0.2.1
>  Tunnel Device: tun0
>  IPv4 configuration:
>Internal Gateway: 100.66.2.5
>Internal Address: 100.66.2.6
>Internal Prefix: 32
>Internal Point-to-Point Address: 100.66.2.5
>Maximum Segment Size (MSS): 0
>Static Route: 10.0.0.0/8   Next Hop: 100.66.2.5
>Static Route: [..SNIP..]
>Forbid Default Route: yes
>Internal DNS: 10.0.0.10
>DNS Domain: 'foobar.no'
>  IPv6 configuration:
>Internal Address: 2001:db8::1000
>Internal Prefix: 112
>Internal Point-to-Point Address: 2001:db8::1
>Maximum Segment Size (MSS): 0
>Static Route: 2001:db8::/32   Next Hop: 2001:db8::1
>Static Route: [..SNIP..]
>Forbid Default Route: yes
>DNS Domain: 'foobar.no'
>  (tun0): link connected
> **
> ERROR:platform/nm-linux-platform.c:2212:build_rtnl_addr: assertion failed: 
> (!nle)
> 
> Hope this can be fixed and updated patches posted...

Is that with NM git master, and if so, what date?  The reason I ask is
because we broke PtP addresses until 2013-12-02, fixed in commit
f099a04132241790c8f88a651ece49f5c2783d12.  The error you're getting may
well be the kernel complaining that it cannot reach the static route,
because it knows nothing about the next hop, because the PtP address
wasn't assigned correctly.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Nicolas Iooss

> A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN
> now supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager
> doesn't support it. I found bug 682620
> (https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented
> some of the missing features with the help
> of network-manager-openconnect commits (basically the IPv6 payload part,
> not the IPv6 endpoint one). My patches are attached to this email. Can
> someone review them and tell me what may be wrong with them? As I'm new
> with NetworkManager, I think there must be some mistakes in my code.

Hello Nicolas,

I (and pretty much all of my colleagues) have been happily using your
patches since they were posted with no issues. It's a shame they haven't
been included upstream a long time ago. However, it appears that a 
change in the version of NetworkManager or NetworkManager-openvpn
included in Fedora 20 have broken them. When I connect to a VPN server
that pushes IPv6 routing information, NetworkManager crashes completely.
The crash happens even if I've set the IPv6 method on the VPN connection
to "ignore". Also, the tunnel itself may go over IPv4, the crash still
happens.

 VPN connection 'foo' (IP6 Config Get) reply received.
 VPN Gateway: 192.0.2.1
 Tunnel Device: tun0
 IPv4 configuration:
   Internal Gateway: 100.66.2.5
   Internal Address: 100.66.2.6
   Internal Prefix: 32
   Internal Point-to-Point Address: 100.66.2.5
   Maximum Segment Size (MSS): 0
   Static Route: 10.0.0.0/8   Next Hop: 100.66.2.5
   Static Route: [..SNIP..]
   Forbid Default Route: yes
   Internal DNS: 10.0.0.10
   DNS Domain: 'foobar.no'
 IPv6 configuration:
   Internal Address: 2001:db8::1000
   Internal Prefix: 112
   Internal Point-to-Point Address: 2001:db8::1
   Maximum Segment Size (MSS): 0
   Static Route: 2001:db8::/32   Next Hop: 2001:db8::1
   Static Route: [..SNIP..]
   Forbid Default Route: yes
   DNS Domain: 'foobar.no'
 (tun0): link connected
**
ERROR:platform/nm-linux-platform.c:2212:build_rtnl_addr: assertion failed: 
(!nle)

Hope this can be fixed and updated patches posted...

I can generate an ABRT dump if anyone would find that useful.

Best regards,
Tore Anderson
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Dan Williams
> Did the issue with --proto you mentioned in the bug (eg
> http://thread.gmane.org/gmane.network.openvpn.devel/7160/focus=7165 )
> get fixed as well?  Then it would be a lot simpler to enable IPv6
> support because we wouldn't need any UI changes to make the user
> indicate that they want IPv6 explicitly (which would trigger udp6/tcp6).

No, not yet. However that is an orthogonal issue. --proto udp6/tcp6 vs
tcp/udp becoming dual-stack strictly relates to the *transport*. I.e.,
the protocol the OpenVPN client uses for communicating with the OpenVPN
server over the internet.

Nicolas' patches relate strictly to IPv6 *payload*. You can very well
tunnel IPv6 packets over a OpenVPN tunnel where the transport is using
IPv4 and vice versa. (In pretty much the same way that you can make a
TCP connection through an OpenVPN tunnel using --proto udp.)

As long as --proto udp/tcp remains single-stack IPv4 in OpenVPN, this
means that Nicolas' patches will not enable NM-OpenVPN to speak to the
VPN servers over IPv6. That's OK, having support for IPv6 payload is
still a huge improvement. If later --proto udp/tcp becomes dual-stack
(and --proto udp6/tcp6 goes away), then that should just start working
(except that maybe the "insert a static host route to VPN server with
the [old] default gateway as the next hop" functionality might need some
extra logic).

Tore
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Dan Williams

> The assumption here is on the side of security, that it's better to send
> all traffic to the VPN and fail, than it is to send your traffic over
> un-encrypted links when a VPN is supposed to be active and you think
> things are encrypted.

That's a pretty good argument for merging these patches, actually. Right
now all IPv6 traffic will go unencrypted, even though the VPN is
perfectly capable of routing IPv6 to all or parts of ::/0. For me, this
merely an annoyance (I always have to do "ssh -4 some.work.system"
because IPv6 just times out), but for others this may be a big privacy
problem, e.g. as reported here:
http://torrentfreak.com/huge-security-flaw-makes-vpns-useless-for-bittorrent-100617/

Tore
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Williams]

On Mon, 2013-08-26 at 19:01 +0200, Tore Anderson wrote:
> * Dan Williams
> 
> > On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote:
> >>  Your patch fixed the segmentation fault but now NetworkManager sets up a
> >> default route via the VPN even if the OpenVPN server has not pushed any.
> > 
> > Unfortunately we cannot rely on administrators always pushing a default
> > route if the VPN can actually route all traffic.
> 
> Nor can you rely on the VPN always being able to route all traffic...
> 
> > The problem you're going to run into is that the NM-openvpn plugin
> > doesn't yet support IPv6, because last time some patches got proposed,
> > openvpn didn't have full IPv6 support and didn't pass back the necessary
> > stuff to the helper script :(  That may have changed?
> 
> Most definitely! More info here:
> https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1
> 
> BTW: When I tested Nicolas' patches I did so using the standard F19
> OpenVPN RPM. It Works(tm)!

Did the issue with --proto you mentioned in the bug (eg
http://thread.gmane.org/gmane.network.openvpn.devel/7160/focus=7165 )
get fixed as well?  Then it would be a lot simpler to enable IPv6
support because we wouldn't need any UI changes to make the user
indicate that they want IPv6 explicitly (which would trigger udp6/tcp6).

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Williams]

On Mon, 2013-08-26 at 19:01 +0200, Tore Anderson wrote:
> * Dan Williams
> 
> > On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote:
> >>  Your patch fixed the segmentation fault but now NetworkManager sets up a
> >> default route via the VPN even if the OpenVPN server has not pushed any.
> > 
> > Unfortunately we cannot rely on administrators always pushing a default
> > route if the VPN can actually route all traffic.
> 
> Nor can you rely on the VPN always being able to route all traffic...

The assumption here is on the side of security, that it's better to send
all traffic to the VPN and fail, than it is to send your traffic over
un-encrypted links when a VPN is supposed to be active and you think
things are encrypted.

Dan

> > The problem you're going to run into is that the NM-openvpn plugin
> > doesn't yet support IPv6, because last time some patches got proposed,
> > openvpn didn't have full IPv6 support and didn't pass back the necessary
> > stuff to the helper script :(  That may have changed?
> 
> Most definitely! More info here:
> https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1
> 
> BTW: When I tested Nicolas' patches I did so using the standard F19
> OpenVPN RPM. It Works(tm)!
> 
> Tore


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Dan Williams

> On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote:
>>  Your patch fixed the segmentation fault but now NetworkManager sets up a
>> default route via the VPN even if the OpenVPN server has not pushed any.
> 
> Unfortunately we cannot rely on administrators always pushing a default
> route if the VPN can actually route all traffic.

Nor can you rely on the VPN always being able to route all traffic...

> The problem you're going to run into is that the NM-openvpn plugin
> doesn't yet support IPv6, because last time some patches got proposed,
> openvpn didn't have full IPv6 support and didn't pass back the necessary
> stuff to the helper script :(  That may have changed?

Most definitely! More info here:
https://bugzilla.gnome.org/show_bug.cgi?id=682620#c1

BTW: When I tested Nicolas' patches I did so using the standard F19
OpenVPN RPM. It Works(tm)!

Tore
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Williams]

On Thu, 2013-08-22 at 21:39 +0200, Nicolas Iooss wrote:
> 2013/8/21 Dan Winship
> 
> > On 08/19/2013 12:47 PM, Nicolas Iooss wrote:
> > > The patches are working well in my testing environment with
> > > NetworkManager 0.9.8 but with the development revision I've got few
> > > issues such as https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM
> > > crashes on a segmentation fault
> > > at
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788as
> > > nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN
> >
> > Right. Does the attached patch fix it?
> >
> 
>  Your patch fixed the segmentation fault but now NetworkManager sets up a
> default route via the VPN even if the OpenVPN server has not pushed any.

Unfortunately we cannot rely on administrators always pushing a default
route if the VPN can actually route all traffic.

What we *could* do is the same thing that openconnect and vpnc do, which
is that if any other routes are pushed to the client, then
nm-openvpn-service-openvpn-helper sets the NEVER_DEFAULT flag which
prevents the tunnel from claiming the default route in NetworkManager.

The problem you're going to run into is that the NM-openvpn plugin
doesn't yet support IPv6, because last time some patches got proposed,
openvpn didn't have full IPv6 support and didn't pass back the necessary
stuff to the helper script :(  That may have changed?

Dan

> More precisely, with NetworkManager OpenVPN plugin, "ip -6 route" shows
> "default dev tun0  proto static  metric 1024" whereas executing openvpn in
> command line doesn't add this default route. Moreover this route doesn't
> work as the next hop needs to be defined to be able to route packets in an
> OpenVPN tunnel. To fix this behavior, I opened a bug a few days ago which
> makes get_best_ip6_config no longer returns VPN connections which don't
> have any internal gateway :
> https://bugzilla.gnome.org/show_bug.cgi?id=706332.
> 
> In fact I don't know how to make an OpenVPN server route the IPv6 internet
> but by pushing to clients a route to 2000::/3 as described on
> http://tomsalmon.eu/2013/04/openvpn-ipv6-with-tun-device/ (last line of the
> config file), as there is no IPv6 equivalent of OpenVPN setting
> "route_vpn_gateway" (which is what NM uses as IPv4 internal gateway). This
> is why I think that a VPN plugin which doesn't set the "IPv6 internal
> gateway" connection parameter shouldn't be considered as a connection
> providing a default route to the Internet (and this is what I implemented
> in the patch for bug #706332).
> 
> Nicolas
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

IPv6 in network-manager-openvpn

[Nicolas Iooss]

Hello,

A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN now
supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager doesn't
support it. I found bug 682620 (
https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented
some of the missing features with the help of network-manager-openconnect
commits. My patches are attached to this email, can someone kindly review
them and tell me what may be wrong with them? As I'm new with
NetworkManager, I think there must be some mistakes in my code.

The patches are working well in my testing environment with NetworkManager
0.9.8 but with the development revision, NetworkManager complains about
"invalid IP6 config received!" in src/vpn-manager/nm-vpn-connection.c on
line 1034. As I understand things, a "!" is missing on line 1031 (
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/vpn-manager/nm-vpn-connection.c?id=320a9d16a3067df32f5ad8a2bb3770104ec359b1#n1031),
but this is strange as this means no IPv6 VPN should work with current
development revision... Does anyone know how OpenConnect plugin can work
with such code?

Thanks,

Nicolas
(IooNag on irc.freenode.net)


0001-service-pass-IPv6-related-information-to-NM.patch
Description: Binary data


0002-properties-expose-IPv6-capability-to-the-UI.patch
Description: Binary data
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Nicolas Iooss

> As I understand things after reading
> https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage:
> (a) With IPv4, OpenVPN server issues an push "redirect-gateway def1"
> command which tells the client to configure a default route via what is
> in the route-gateway option. This option is retrieved by OpenVPN plugin
> using environment variable "route_vpn_gateway" but the first push
> command is lost and that's why NetworkManager provides a checkbox to
> allow the user to choose whether this VPN connection may be used as
> default route or not.
> (b) With IPv6, push "redirect-gateway def1" command doesn't do anything
> and there is nothing like "route_vpn_gateway". A simple workaround
> consists in pushing a route to 2000::/3 but there should be another way
> for an OpenVPN server to push IPv6 default routes to its clients.

Yeah, I tried pushing ::/0 but that didn't work at all, the client just
ignored it. The work VPN server doesn't push any default routes, nor
will it actually route traffic to the internet, only to the specific
networks for which it does push a route. So I think it is broken
behaviour by NM to redirect the default route to the VPN tunnel by
default, when there is absolutely nothing suggesting it should do so.
But in any case this has nothing to do with your patches.

> Right now, NetworkManager is acting in IPv6 like in IPv4: it creates a
> default route unless "use this connection only for resources on its
> network" is checked. For OpenVPN I think NM should never create a
> default route as the server pushes what is needed, but for other VPN the
> situation is certainly different. To be compatible with every VPN
> plugin, I've written a patch in bug 706332 which would allow the IPv6
> internal gateway associated with a connection to be NULL, which is
> different from "::" (this latest value meaning "configure a default
> route without any gateway").

It's kind of pointless to be talking about "gateways" anyway, since this
is a point-to-point interface anyway where the gateway concept (i.e. a
next-hop pointing to an IP address rather than the interface directly)
doesn't make any sense... I guess this is due to limitations in the
NetworkManager/OpenVPN code though.

Tore

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Nicolas Iooss]

Thanks for testing my patches!


> I noticed that the default route also gets redirected to the tunnel
> device even though the server does not push this route. So internet
> connectivity is broken unless I explicitly enable the "use this
> connection for resources on its network" setting. However I believe this
> bug occurs with IPv4 as well, so I don't think it is something wrong
> with your patches per se in this regard.


>
As I understand things after reading
https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage:
(a) With IPv4, OpenVPN server issues an push "redirect-gateway def1"
command which tells the client to configure a default route via what is in
the route-gateway option. This option is retrieved by OpenVPN plugin using
environment variable "route_vpn_gateway" but the first push command is lost
and that's why NetworkManager provides a checkbox to allow the user to
choose whether this VPN connection may be used as default route or not.
(b) With IPv6, push "redirect-gateway def1" command doesn't do anything and
there is nothing like "route_vpn_gateway". A simple workaround consists in
pushing a route to 2000::/3 but there should be another way for an OpenVPN
server to push IPv6 default routes to its clients.

Right now, NetworkManager is acting in IPv6 like in IPv4: it creates a
default route unless "use this connection only for resources on its
network" is checked. For OpenVPN I think NM should never create a default
route as the server pushes what is needed, but for other VPN the situation is
certainly different. To be compatible with every VPN plugin, I've written a
patch in bug 706332 which would allow the IPv6 internal gateway associated
with a connection to be NULL, which is different from "::" (this latest
value meaning "configure a default route without any gateway").

Best,

Nicolas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Nicolas Iooss]

2013/8/21 Dan Winship

> On 08/19/2013 12:47 PM, Nicolas Iooss wrote:
> > The patches are working well in my testing environment with
> > NetworkManager 0.9.8 but with the development revision I've got few
> > issues such as https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM
> > crashes on a segmentation fault
> > at
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788as
> > nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN
>
> Right. Does the attached patch fix it?
>

 Your patch fixed the segmentation fault but now NetworkManager sets up a
default route via the VPN even if the OpenVPN server has not pushed any.
More precisely, with NetworkManager OpenVPN plugin, "ip -6 route" shows
"default dev tun0  proto static  metric 1024" whereas executing openvpn in
command line doesn't add this default route. Moreover this route doesn't
work as the next hop needs to be defined to be able to route packets in an
OpenVPN tunnel. To fix this behavior, I opened a bug a few days ago which
makes get_best_ip6_config no longer returns VPN connections which don't
have any internal gateway :
https://bugzilla.gnome.org/show_bug.cgi?id=706332.

In fact I don't know how to make an OpenVPN server route the IPv6 internet
but by pushing to clients a route to 2000::/3 as described on
http://tomsalmon.eu/2013/04/openvpn-ipv6-with-tun-device/ (last line of the
config file), as there is no IPv6 equivalent of OpenVPN setting
"route_vpn_gateway" (which is what NM uses as IPv4 internal gateway). This
is why I think that a VPN plugin which doesn't set the "IPv6 internal
gateway" connection parameter shouldn't be considered as a connection
providing a default route to the Internet (and this is what I implemented
in the patch for bug #706332).

Nicolas
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Tore Anderson]

* Nicolas Iooss

> A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN
> now supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager
> doesn't support it. I found bug 682620
> (https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented
> some of the missing features with the help
> of network-manager-openconnect commits (basically the IPv6 payload part,
> not the IPv6 endpoint one). My patches are attached to this email.

Hello Nicolas and thanks for doing this!

I've tested the patches on top of the NetworkManager-openvpn RPM in
Fedora 19. They work just fine for me when testing towards the corporate
VPN server at work, the addresses and routes pushed by the server gets
installed and IPv6 traffic is successfully routed through the tunnel.
Good job!

I really hope these patches end up being merged, as it has been a pain
in the arse to always find ways to force applications to use IPv4 when
I'm working remotely (which is necessary because getaddrinfo() defaults
to the use of IPv6, which goes outside of the VPN and therefore making
my traffic come from an unprivileged source network on the internet).

I noticed that the default route also gets redirected to the tunnel
device even though the server does not push this route. So internet
connectivity is broken unless I explicitly enable the "use this
connection for resources on its network" setting. However I believe this
bug occurs with IPv4 as well, so I don't think it is something wrong
with your patches per se in this regard.

Best regards,
Tore Anderson
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 in network-manager-openvpn

[Dan Winship]

On 08/19/2013 12:47 PM, Nicolas Iooss wrote:
> The patches are working well in my testing environment with
> NetworkManager 0.9.8 but with the development revision I've got few
> issues such as https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM
> crashes on a segmentation fault
> at 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788
>  as
> nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN

Right. Does the attached patch fix it?

(Pavel: I briefly considered changing NMPlatform to take pointers to
struct in6_addr rather than struct in6_addr itself everywhere. it's
generally considered poor form to pass "large" structs on the stack
anyway...)

-- Dan

>From 135d790d1ad1ea240a8ccb04383aa8551cf7f2f7 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Wed, 21 Aug 2013 13:36:54 -0400
Subject: [PATCH] core: fix crash when connecting to ipv6-aware VPN

NMVpnConnection represents "no IPv6 internal gateway" as NULL, so you
can't just dereference the result. We have to pass in6addr_any to
NMPlatform in that case.
---
 src/nm-policy.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/nm-policy.c b/src/nm-policy.c
index cf94033..2707bfe 100644
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -785,12 +785,14 @@ update_ip6_routing (NMPolicy *policy, gboolean force_update)
 		int parent_ifindex = nm_device_get_ip_ifindex (parent);
 		NMIP6Config *parent_ip6 = nm_device_get_ip6_config (parent);
 		guint32 parent_mss = parent_ip6 ? nm_ip6_config_get_mss (parent_ip6) : 0;
-		struct in6_addr int_gw = *nm_vpn_connection_get_ip6_internal_gateway (vpn);
+		const struct in6_addr *int_gw = nm_vpn_connection_get_ip6_internal_gateway (vpn);
 		int mss = nm_ip6_config_get_mss (ip6_config);
 
-		if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, int_gw, 0, mss)) {
+		if (!int_gw)
+			int_gw = &in6addr_any;
+		if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, *int_gw, 0, mss)) {
 			nm_platform_ip6_route_add (parent_ifindex, *gw_addr, 128, in6addr_any, 0, parent_mss);
-			if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, int_gw, 0, mss)) {
+			if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, *int_gw, 0, mss)) {
 nm_log_err (LOGD_IP6 | LOGD_VPN, "Failed to set default route.");
 			}
 		}
-- 
1.8.3.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

IPv6 in network-manager-openvpn

[Nicolas Iooss]

Hello,

A few weeks ago I ran into a bug in NetworkManager: even though OpenVPN now
supports IPv6 in tunnels, the OpenVPN plugin of NetworkManager doesn't
support it. I found bug 682620 (
https://bugzilla.gnome.org/show_bug.cgi?id=682620) and I've implemented
some of the missing features with the help of network-manager-openconnect
commits (basically the IPv6 payload part, not the IPv6 endpoint one). My
patches are attached to this email. Can someone review them and tell me
what may be wrong with them? As I'm new with NetworkManager, I think there
must be some mistakes in my code.

The patches are working well in my testing environment with NetworkManager
0.9.8 but with the development revision I've got few issues such as
https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM crashes on a
segmentation fault at
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788
as
nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN (there
are IPv6 unique local addresses on my OpenVPN server, without routing) so
there is still work to be done before further testing. I'll certainly fill
a bug report tomorrow but right now I can provide some logs and a coredump
backtrace, after this message.

Thanks,

Nicolas


/var/log/daemon.log:

NetworkManager[30420]:  (tun0): carrier is OFF
nm-openvpn[30512]:
/usr/lib/networkmanager/nm-openvpn-service-openvpn-helper tun0 1500 1544
10.55.62.6 10.55.62.5 init
NetworkManager[30420]:  (tun0): new Tun device (driver: 'unknown'
ifindex: 5)
NetworkManager[30420]:  (tun0): exported as
/org/freedesktop/NetworkManager/Devices/3
NetworkManager[30420]:  VPN connection 'Iosenag' (IP Config Get)
reply received.
NetworkManager[30420]:  VPN connection 'Iosenag' (IP4 Config Get)
reply received.
NetworkManager[30420]:  VPN connection 'Iosenag' (IP6 Config Get)
reply received.
NetworkManager[30420]:  VPN Gateway: 31.7.184.34
NetworkManager[30420]:  Tunnel Device: tun0
NetworkManager[30420]:  IPv4 configuration:
NetworkManager[30420]:Internal Gateway: 10.55.62.5
NetworkManager[30420]:Internal Address: 10.55.62.6
NetworkManager[30420]:Internal Prefix: 32
NetworkManager[30420]:Internal Point-to-Point Address: 10.55.62.5
nm-openvpn[30512]: Initialization Sequence Completed
NetworkManager[30420]:Maximum Segment Size (MSS): 0
NetworkManager[30420]:Static Route: 10.55.62.1/32   Next Hop:
10.55.62.1
NetworkManager[30420]:Forbid Default Route: no
NetworkManager[30420]:Internal DNS: 10.55.62.1
NetworkManager[30420]:Internal DNS: 208.67.222.222
NetworkManager[30420]:DNS Domain: '(none)'
NetworkManager[30420]:  IPv6 configuration:
NetworkManager[30420]:Internal Address: fd10:0:55:62::1000
NetworkManager[30420]:Internal Prefix: 64
NetworkManager[30420]:Internal Point-to-Point Address:
fd10:0:55:62::1
NetworkManager[30420]:Maximum Segment Size (MSS): 0
NetworkManager[30420]:Forbid Default Route: no
NetworkManager[30420]:DNS Domain: '(none)'
NetworkManager[30420]:  (tun0): link connected
NetworkManager[30420]:  [1376927563.222516]
[platform/nm-linux-platform.c:1018] add_object(): Netlink error: Unspecific
failure
NetworkManager[30420]:  VPN connection 'Iosenag' (IP Config Get)
complete.
NetworkManager[30420]:  [1376927563.225071]
[platform/nm-linux-platform.c:1018] add_object(): Netlink error: Unspecific
failure
NetworkManager[30420]:  [1376927563.225281]
[platform/nm-linux-platform.c:1018] add_object(): Netlink error: Unspecific
failure
NetworkManager[30420]:  [1376927563.225294] [nm-policy.c:617]
update_ip4_routing(): Failed to set default route.
NetworkManager[30420]:  Policy set 'Iosenag' (tun0) as default for
IPv4 routing and DNS.
systemd[1]: NetworkManager.service: main process exited, code=dumped,
status=11/SEGV
systemd[1]: Unit NetworkManager.service entered failed state.


Coredump backtrace (using "systemd-coredumpctl gdb 30420"):
TIME PID   UID   GID SIG EXE
lun. 2013-08-19 17:52:43 CEST  30420 0 0  11
/usr/bin/NetworkManager
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/NetworkManager...done.
[New LWP 30420]
[New LWP 30421]
[New LWP 30510]
[New LWP 30422]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

warning: no loadable sections found in added symbol-file system-supplied
DSO at 0x6fb5d0c9
Core was generated by `

[PATCH] Fix high cpu usage in network-manager-openvpn

[Bao Haojun]

When a socket is closed, poll(2) will always return readable
immediately, read(2) will return 0 (EOF), thus we need to remove it
from the watched channels, or else the cpu get spinning to 100%.

Signed-off-by: Bao Haojun 
---
 src/nm-openvpn-service.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c
index 660fd2f..d69f536 100644
--- a/src/nm-openvpn-service.c
+++ b/src/nm-openvpn-service.c
@@ -404,12 +404,20 @@ handle_management_socket (NMVPNPlugin *plugin,
NMOpenvpnPluginIOData *io_data = NM_OPENVPN_PLUGIN_GET_PRIVATE 
(plugin)->io_data;
gboolean again = TRUE;
char *str = NULL, *auth = NULL, *buf;
+   GIOStatus status;
 
if (!(condition & G_IO_IN))
return TRUE;
 
-   if (g_io_channel_read_line (source, &str, NULL, NULL, NULL) != 
G_IO_STATUS_NORMAL)
+   status = g_io_channel_read_line (source, &str, NULL, NULL, NULL);
+
+   if (status != G_IO_STATUS_NORMAL) {
+   if (status == G_IO_STATUS_EOF && 
io_data->socket_channel_eventid) {
+   g_source_remove (io_data->socket_channel_eventid);
+   io_data->socket_channel_eventid = 0;
+   }
return TRUE;
+   }
 
if (strlen (str) < 1)
goto out;
-- 
1.7.10.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: High cpu usage bug in network-manager-openvpn (patch)

[Bao Haojun]

Or maybe I should investigate why the socket to localhost:1194 got
closed in the first place, I mean, is this a normal behavior? But as I'm
not familiar with openvpn internals, I have chose to fix it in the easy
way.

PS, please kindly put me in the CC: as I am not subscribed to the list,
thanks!

"Bao Haojun"  writes:

> Hi, all
>
> I'm using debian testing, and the version is
> network-manager-openvpn-0.9.4.0.
>
> I can connect to my openvpn server successfully, but after a while, my
> CPU usage got high:
>
>   PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
> 11039 root   20   0 74032  3576  2932 R 100.  0.0  4:35.72 
> /usr/lib/NetworkManager/nm-openvpn-service
>
> Strace shows it's repeatedly reading EOF from fd 7, 
>
> [pid 11039] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, 
> events=POLLIN}], 3, -1) = 2 ([{fd=4, revents=POLLIN}, {fd=7, revents=POLLIN}])
> [pid 11039] read(4, "\2\0\0\0\0\0\0\0", 16) = 8
> [pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid 11039] read(7, "", 1024)   = 0
> [pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid 11039] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, 
> events=POLLIN}], 3, -1) = 2 ([{fd=4, revents=POLLIN}, {fd=7, revents=POLLIN}])
> [pid 11039] read(4, "\2\0\0\0\0\0\0\0", 16) = 8
> [pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
> [pid 11039] read(7, "", 1024)   = 0
> [pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
>
> which is a socket connected to localhost:1194 and in the CLOSE_WAIT
> state:
>
> # output from "ls -l /proc/pid/fd"
> lrwx-- 1 root root 64 Oct 11 14:02 /proc/11039/fd/7 -> 
> socket:[1024147]
>
> # output from "sudo netstat -a -p -n |grep 11039"
> tcp0  0 127.0.0.1:43056 127.0.0.1:1194  
> CLOSE_WAIT  11039/nm-openvpn-se
>
> My fix for this problem is to stop watching that IO channel because when
> EOF occur, the poll will always return readable immediately, thus
> creating busy loop.
>
> Patch is attached, please help review.

-- 
All the best

 Bao Haojun
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

High cpu usage bug in network-manager-openvpn (patch)

[Haojun Bao]

Hi, all

I'm using debian testing, and the version is
network-manager-openvpn-0.9.4.0.

I can connect to my openvpn server successfully, but after a while, my
CPU usage got high:

  PID USER  PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
11039 root   20   0 74032  3576  2932 R 100.  0.0  4:35.72 
/usr/lib/NetworkManager/nm-openvpn-service

Strace shows it's repeatedly reading EOF from fd 7, 

[pid 11039] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, 
events=POLLIN}], 3, -1) = 2 ([{fd=4, revents=POLLIN}, {fd=7, revents=POLLIN}])
[pid 11039] read(4, "\2\0\0\0\0\0\0\0", 16) = 8
[pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 11039] read(7, "", 1024)   = 0
[pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 11039] poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, 
events=POLLIN}], 3, -1) = 2 ([{fd=4, revents=POLLIN}, {fd=7, revents=POLLIN}])
[pid 11039] read(4, "\2\0\0\0\0\0\0\0", 16) = 8
[pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8
[pid 11039] read(7, "", 1024)   = 0
[pid 11039] write(4, "\1\0\0\0\0\0\0\0", 8) = 8

which is a socket connected to localhost:1194 and in the CLOSE_WAIT
state:

# output from "ls -l /proc/pid/fd"
lrwx-- 1 root root 64 Oct 11 14:02 /proc/11039/fd/7 -> socket:[1024147]

# output from "sudo netstat -a -p -n |grep 11039"
tcp0  0 127.0.0.1:43056 127.0.0.1:1194  
CLOSE_WAIT  11039/nm-openvpn-se

My fix for this problem is to stop watching that IO channel because when
EOF occur, the poll will always return readable immediately, thus
creating busy loop.

Patch is attached, please help review.

-- 
All the best

 Bao Haojun
From 7b3ac1c3fab868a0b1655151510c132073f7f60a Mon Sep 17 00:00:00 2001
From: Bao Haojun 
Date: Thu, 11 Oct 2012 13:36:10 +0800
Subject: [PATCH] Fix high cpu usage

When the openvpn tcp port 1194 connection is closed, poll will always
return readable immediately, thus the cpu get spinning to 100%.
---
 src/nm-openvpn-service.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c
index 660fd2f..d69f536 100644
--- a/src/nm-openvpn-service.c
+++ b/src/nm-openvpn-service.c
@@ -404,12 +404,20 @@ handle_management_socket (NMVPNPlugin *plugin,
 	NMOpenvpnPluginIOData *io_data = NM_OPENVPN_PLUGIN_GET_PRIVATE (plugin)->io_data;
 	gboolean again = TRUE;
 	char *str = NULL, *auth = NULL, *buf;
+	GIOStatus status;
 
 	if (!(condition & G_IO_IN))
 		return TRUE;
 
-	if (g_io_channel_read_line (source, &str, NULL, NULL, NULL) != G_IO_STATUS_NORMAL)
+	status = g_io_channel_read_line (source, &str, NULL, NULL, NULL);
+
+	if (status != G_IO_STATUS_NORMAL) {
+		if (status == G_IO_STATUS_EOF && io_data->socket_channel_eventid) {
+			g_source_remove (io_data->socket_channel_eventid);
+			io_data->socket_channel_eventid = 0;
+		}
 		return TRUE;
+	}
 
 	if (strlen (str) < 1)
 		goto out;
-- 
1.7.10.4

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

network-manager-openvpn still not meet everyone's needs

[Luc Deschenaux]

Hello !

Using natty with backports and natty-bleed-ppa repositories enabled.

When somebody try to load a custom openvpn config file, unwanted options 
are set (eg: redirect-gateway def1), then we could suppose other ones 
are maybe discarded (since the opposite is true)..


When somebody import a custom config file, we could believe he expect 
that it will be used "as is"... not you ?


... there should be an option for it. (it could also allow using server 
configurations - though i didnt check if it was not yet working)


At least, default gateway or dns requests redirection should be optional.

In the meanwhile, 2 years after I mentioned it for the first time, we 
still need to use /etc/openvpn and crontab to "checkvpn" ... *sigh*


Take a look at Tunneblick (it rocks) for OSuX.. (allowing to look at the 
log and edit the configuration file, beside the gui)


Regards,

:7üC:
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Wed, 2009-12-16 at 14:33 -0500, Matt Wilks wrote:
> > On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote:
> >> On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
> >> What prompted my initial query was the lack of support for,
> >> and  directives (supported in OpenVPN since 2.1-beta7, Nov
> >> 2005).  They allow you to specify the key files directly in the
> >> configuration file, making it a self-contained configuration for a
> >> connection using keys to authenticate.  NetworkManager also seemed to
> >> miss the fact that my config required both keys and a password; not
> >> hard to manually set but it wasn't caught by the import.
> >
> > I do believe those have been in the NM openvpn configuration for a
> > long time.  What specific version of NM-openvpn are you using?  I'm
> > certainly using a CA certificate right now to write this mail.  If you
> > pick "Certificates (TLS)" or "Passwords with Certificates" from the
> > dropdown you should be able to use the certificates and keys of your
> > choice.  This has been the case for at least a year and a half, since
> > before NM 0.7.x was released.
> 
> Keys are supported, but you have to specify them in the NetworkManager
> config through a file browser dialog.  The , etc directives I'm
> talking about go in the config file and you include the actual text of
> the key, something like:
> 
> 
> -BEGIN CERTIFICATE-
> asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj
> dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk
> fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj
> -END CERTIFICATE-
> 
> 
> and so on with  and .  I have NM (and NM-openvpn) version 0.8
> on Ubuntu Karmic and it didn't work for me.

Aha, yes that is not yet supported; it wouldn't be too hard to grab the
data out of there and stuff it into its own file in ~/.pki or such; you
don't really want to be storing certificate data in GConf or elsewhere.

In the end, we need a certificate store like Windows or Mac OS X has,
but for now we'll need to use files I guess.

One caveat is to ensure that the user's private key is written out in
encrypted form if it's not already encrypted in the config.

Dan

> > The whitelisting is for security.  As a user, if you download a
> > configuration file and want to use it, what's to say it doesn't include
> > some options that make things less-secure or are malicious?  Depending
> > on the plugin you could send a config option for "run this script after
> > connection" and since the VPN plugins currently run as root, that script
> > gets run as root.  The configuration data cannot /necessarily/ be
> > trusted especially if it comes from the user session.  At the same time,
> > you don't want to /necessarily/ lock users out completely (that's the
> > discretion of the sysadmin if there is one).
> 
> Ah, this security concern settles it for me.  The reason that other
> clients can offer the config file management paradigm is that you must
> have admin privileges to run the program in the first place.  Not so
> with NM.
> 
> Thanks again for your time.  Much appreciated.
> 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Matt Wilks]

On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote:

On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
What prompted my initial query was the lack of support for,
and  directives (supported in OpenVPN since 2.1-beta7, Nov
2005).  They allow you to specify the key files directly in the
configuration file, making it a self-contained configuration for a
connection using keys to authenticate.  NetworkManager also seemed to
miss the fact that my config required both keys and a password; not
hard to manually set but it wasn't caught by the import.


I do believe those have been in the NM openvpn configuration for a
long time.  What specific version of NM-openvpn are you using?  I'm
certainly using a CA certificate right now to write this mail.  If you
pick "Certificates (TLS)" or "Passwords with Certificates" from the
dropdown you should be able to use the certificates and keys of your
choice.  This has been the case for at least a year and a half, since
before NM 0.7.x was released.


Keys are supported, but you have to specify them in the NetworkManager
config through a file browser dialog.  The , etc directives I'm
talking about go in the config file and you include the actual text of
the key, something like:


-BEGIN CERTIFICATE-
asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj
dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk
fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj
-END CERTIFICATE-


and so on with  and .  I have NM (and NM-openvpn) version 0.8
on Ubuntu Karmic and it didn't work for me.


The whitelisting is for security.  As a user, if you download a
configuration file and want to use it, what's to say it doesn't include
some options that make things less-secure or are malicious?  Depending
on the plugin you could send a config option for "run this script after
connection" and since the VPN plugins currently run as root, that script
gets run as root.  The configuration data cannot /necessarily/ be
trusted especially if it comes from the user session.  At the same time,
you don't want to /necessarily/ lock users out completely (that's the
discretion of the sysadmin if there is one).


Ah, this security concern settles it for me.  The reason that other
clients can offer the config file management paradigm is that you must
have admin privileges to run the program in the first place.  Not so
with NM.

Thanks again for your time.  Much appreciated.

--
Matt Wilks   Colossians 2:6-7
University of TorontoInformation Security, I+TS
(416) 978-3328   m...@madhaus.cns.utoronto.ca
4 Bancroft Ave., Rm. 102 Toronto, ON  M5S 1C1
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
> On 09-12-14 06:09 PM, Dan Williams wrote:
> > On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:
> >> This must have been discussed before on this list, but I'm curious the
> >> reasoning behind making network-manager-openvpn have its own GUI for
> >> configuration in the first place.  Why not offer functionality similar
> >> to the Windows/Mac clients that simply manage your connections via
> >> configuration files?  You'd get all the flexibility of OpenVPN with none
> >> of the overhead of constantly having to write patches to support /
> >> debate the inclusion of individual options.
> >
> > For a number of reasons;
> 
> Thanks for your response Dan, I appreciate you taking the time to do so.
> Allow me to make a few comments.
> 
> > 1) not everyone wants to use configuration files,
> > 2) not everyone is aware of (or cares about) the intricacies of
> > configuration options, some cannot be used with others, some require
> > others to be turned on,
> 
> Granted.  However, I would think that anyone who is attempting to
> connect to a work/school VPN is more likely to have a configuration file
> handed to them then a set of OpenVPN parameters.  That is how we do it
> with the VPN I am responsible for.

Again, the config file can be imported into NM, so the process you have
still works exactly the same way.

> > 3) GUI interfaces are often more approachable and do not preclude
> > advanced users from using config files anyway, and
> 
> I think you are making an incorrect distinction here between advanced
> and beginner users.  Using a config file does not necessarily mean that
> a user is advanced.  In our case, we distribute a config file precisely
> because so many of our users are not advanced and we don't want them
> having to fiddle around with options on various clients.
> 
> > 4) handling random config files is often problematic,
> 
> I'm not sure I understand why.  Using the model of OpenVPN-GUI or
> Tunnelblick (Windows and Mac GUIs respectively) however, you would just
> have NetworkManager monitor a directory for config files.  Could be a
> directory in the user's home (ala Tunnelblick) or a system directory
> (ala OpenVPN-GUI).  Even if the user were able to specify arbitrary
> configuration file locations, how is this any more problematic then the
> dialogs to specify the ca, key and user cert that currently exist in the
> NetworkManager GUI?

1) The config file is stored separately from the rest of the
configuration data like IP address, routing information, DNS, etc.  If
it's not available (user downloads it into ~/Downloads and then it gets
deleted when FF quits) then it's no longer available

2) root daemons accessing files in users' directories is often not
allowed by security software like SELinux or AppArmor, for good reason;
it's really hard to contain a binary and limit the attack points when
you have to allow the binary to read from all over the hard drive

3) it's a security risk on daemons that require a password in the config
file when not using stdin (ex vpnc)

4) using a config file can create temporary files that require cleanup
which doesn't always get done; if we do need to substitute certain
values (like we do with dhclient) then we need to create a temporary
config file that has to be cleaned up after the transaction is complete,
which is more housekeeping and more trouble.

> > 5) it wasnt' integrated into the consistent NetworkManager
> > configuration system.
> 
> I have to admit ignorance about the standards for configuring
> NetworkManager, but I imagine that they say something about storing
> configuration internally rather than referencing external files?

http://live.gnome.org/NetworkManagerConfiguration

The NM configuration system actually produces an abstraction over
various distro and desktop-specific configuration systems so taht you
can use your preferred configuration system.  For example, GConf,
KConfig, /etc/network/interfaces, keyfiles, ifcfg files, etc, all are
transformed into a standard format that clients can read and handle.
That allows you, from a client, to actually figure out what's going on
in a standard way instead of having to code logic for each and every
configuration system.

NM doesn't store config /internally/, but the user-settings and
system-settings services do use configuration systems like GConf or
system config files that you might consider to store the config
"internally", at least in a different format than the native config file
for openvpn.  That has some benefits; as the admin you can use tools,
behaviors, processes, and knowledge that you already have for your
distro&

Re: network-manager-openvpn

[Matt Wilks]

On 09-12-14 06:09 PM, Dan Williams wrote:

On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:

This must have been discussed before on this list, but I'm curious the
reasoning behind making network-manager-openvpn have its own GUI for
configuration in the first place.  Why not offer functionality similar
to the Windows/Mac clients that simply manage your connections via
configuration files?  You'd get all the flexibility of OpenVPN with none
of the overhead of constantly having to write patches to support /
debate the inclusion of individual options.


For a number of reasons;


Thanks for your response Dan, I appreciate you taking the time to do so.
Allow me to make a few comments.


1) not everyone wants to use configuration files,
2) not everyone is aware of (or cares about) the intricacies of
configuration options, some cannot be used with others, some require
others to be turned on,


Granted.  However, I would think that anyone who is attempting to
connect to a work/school VPN is more likely to have a configuration file
handed to them then a set of OpenVPN parameters.  That is how we do it
with the VPN I am responsible for.


3) GUI interfaces are often more approachable and do not preclude
advanced users from using config files anyway, and


I think you are making an incorrect distinction here between advanced
and beginner users.  Using a config file does not necessarily mean that
a user is advanced.  In our case, we distribute a config file precisely
because so many of our users are not advanced and we don't want them
having to fiddle around with options on various clients.


4) handling random config files is often problematic,


I'm not sure I understand why.  Using the model of OpenVPN-GUI or
Tunnelblick (Windows and Mac GUIs respectively) however, you would just
have NetworkManager monitor a directory for config files.  Could be a
directory in the user's home (ala Tunnelblick) or a system directory
(ala OpenVPN-GUI).  Even if the user were able to specify arbitrary
configuration file locations, how is this any more problematic then the
dialogs to specify the ca, key and user cert that currently exist in the
NetworkManager GUI?


5) it wasnt' integrated into the consistent NetworkManager
configuration system.


I have to admit ignorance about the standards for configuring
NetworkManager, but I imagine that they say something about storing
configuration internally rather than referencing external files?


Now that we have good import/export capability for openvpn, it's not
actually that hard to use your own configs.  If there's options that
people use, we can also whitelist them and add them to import/export
even if they aren't shown in the GUI.


What prompted my initial query was the lack of support for , 
and  directives (supported in OpenVPN since 2.1-beta7, Nov 2005).
They allow you to specify the key files directly in the configuration
file, making it a self-contained configuration for a connection using
keys to authenticate.  NetworkManager also seemed to miss the fact that
my config required both keys and a password; not hard to manually set
but it wasn't caught by the import.


Just because there's a GUI doesn't preclude you from writing a config
file and importing it of course.


That's true, and apart from the missing config I mentioned above, I
found it to be a relatively painless process.  Kudos!  However I don't
see how this benefits the NetworkManager developers.  Writing a plugin
that used external config files would be a one-time job.  As it stands
now, each new option must be whitelisted and incorporated into the
plugin.

Again, thanks for taking the time to respond.  Much appreciated.

--
Matt Wilks   Colossians 2:6-7
University of TorontoInformation Security, I+TS
(416) 978-3328   m...@madhaus.cns.utoronto.ca
4 Bancroft Ave., Rm. 102 Toronto, ON  M5S 1C1
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:
> >> Read slowly, im not talking about routes here, talking about all the
> >> openvpn parameters that are not yet configurable/importable with the
> >> current graphical interface. They could just be configured through or
> >> imported into a single listbox as described above.
> >
> > But that's *horrible* UI and not something I'd like to condone.  I'd
> > rather add the options on an as-needed basis to ensure we don't just
> > dump everything in, and find out that we overloaded the UI with 50
> > options that almost nobody uses.  Which I suspect is true for at least
> > half of openvpn's options, because they did absolutely no work in
> > consolidating them and asking the people who requested the options
> > what they were actually trying to accomplish to constrain the number
> > of switches that openvpn supports.  I'm interested in making it work
> > for 90 - 95% of use-cases, but I don't think we should be designing
> > for that last 5%, especially when it makes things nearly unusable for
> > the other 90.
> 
> This must have been discussed before on this list, but I'm curious the
> reasoning behind making network-manager-openvpn have its own GUI for
> configuration in the first place.  Why not offer functionality similar
> to the Windows/Mac clients that simply manage your connections via
> configuration files?  You'd get all the flexibility of OpenVPN with none
> of the overhead of constantly having to write patches to support /
> debate the inclusion of individual options.

For a number of reasons; 1) not everyone wants to use configuration
files, 2) not everyone is aware of (or cares about) the intricacies of
configuration options, some cannot be used with others, some require
others to be turned on, 3) GUI interfaces are often more approachable
and do not preclude advanced users from using config files anyway, and
4) handling random config files is often problematic, and 5) it wasnt'
integrated into the consistent NetworkManager configuration system.

Now that we have good import/export capability for openvpn, it's not
actually that hard to use your own configs.  If there's options that
people use, we can also whitelist them and add them to import/export
even if they aren't shown in the GUI.

Just because there's a GUI doesn't preclude you from writing a config
file and importing it of course.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Matt Wilks]

Read slowly, im not talking about routes here, talking about all the
openvpn parameters that are not yet configurable/importable with the
current graphical interface. They could just be configured through or
imported into a single listbox as described above.


But that's *horrible* UI and not something I'd like to condone.  I'd
rather add the options on an as-needed basis to ensure we don't just
dump everything in, and find out that we overloaded the UI with 50
options that almost nobody uses.  Which I suspect is true for at least
half of openvpn's options, because they did absolutely no work in
consolidating them and asking the people who requested the options
what they were actually trying to accomplish to constrain the number
of switches that openvpn supports.  I'm interested in making it work
for 90 - 95% of use-cases, but I don't think we should be designing
for that last 5%, especially when it makes things nearly unusable for
the other 90.


This must have been discussed before on this list, but I'm curious the
reasoning behind making network-manager-openvpn have its own GUI for
configuration in the first place.  Why not offer functionality similar
to the Windows/Mac clients that simply manage your connections via
configuration files?  You'd get all the flexibility of OpenVPN with none
of the overhead of constantly having to write patches to support /
debate the inclusion of individual options.

Matt
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Wed, 2009-09-23 at 15:49 +0200, Luc Deschenaux wrote:
> Le mardi 22 septembre 2009 à 23:09 -0700, Dan Williams a écrit :
> > On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote:
> > > > > 1. It should be possible to activate simutaneously many openvpn
> > > > > configurations using checkboxes instead of radiobuttons, (in server 
> > > > > mode
> > > > > also, say in a second time...).
> > > > 
> > > > Yes, this is something that's been on the map for a while but there was
> > > > other stuff that we considered more important.  It will take some rework
> > > > internally in NetworkManager, though NM 0.7 already has half the work
> > > > done.
> > > > 
> > > > > 2. It should be possible to "import" any openvpn configuration file, 
> > > > > eg:
> > > > 
> > > > The 0.7 openvpn plugin should already be able to import an openvpn
> > > > connection, but I think we just never got around to implementing export.
> > > 
> > > Every configuration parameter should be importable/modifiable, not only
> > > the ones used in a given configuration.
> > > 
> > > > What specific configuration were you having problems with?  Can you
> > > > attach that config so we can see what's going on with it?
> > > 
> > > My config was attached :) But someone may need to use other parameters
> > > as well.
> > >  
> > > > > * Options not modifiable actually by network-manager-openvpn should 
> > > > > also
> > > > > be gathered and displayed, eg: in a dynamic listbox like for the 
> > > > > routes,
> > > > > with an add button. There could be a pop-up in the first column to set
> > > > > or change the option name, an editable field in the second column to 
> > > > > set
> > > > > or change its value.
> > > > 
> > > 
> > > > 0.7 already provides the ability to specify custom routes to apply to
> > > > the connection in addition to any routes sent by the server.
> > > 
> > > >  
> > > Read slowly, im not talking about routes here, talking about all the
> > > openvpn parameters that are not yet configurable/importable with the
> > > current graphical interface. They could just be configured through or
> > > imported into a single listbox as described above.
> > 
> > But that's *horrible* UI and not something I'd like to condone.  I'd
> > rather add the options on an as-needed basis to ensure we don't just
> > dump everything in, and find out that we overloaded the UI with 50
> > options that almost nobody uses.  Which I suspect is true for at least
> > half of openvpn's options, because they did absolutely no work in
> > consolidating them and asking the people who requested the options what
> > they were actually trying to accomplish to constrain the number of
> > switches that openvpn supports.  I'm interested in making it work for 90
> > - 95% of use-cases, but I don't think we should be designing for that
> > last 5%, especially when it makes things nearly unusable for the other
> > 90.
> > 
> > Dan
> 
> Your judgment is totally subjective. What I did suggest is not more
> horrible than the UI to define routes actually, did you read
> thoroughly ?...

Routes is a specific, targeted property that can be done much better
than I've done it.  But trying to put all the available openvpn options
into a table like that isn't, and I think we can do better that that.
We don't *have* to support all the options.  We just have to support the
options that most people use.

> I suggest a listbox in a another panel (like the routes panel) with an
> popup or a text field to specify which option to set in the first
> column , and a second column to set the value. 

If you've got some time to mock it up or prototype, I'm quite happy to
be proved wrong as an addition piece or external utility.  I've run into
quite a few UIs like that in various products (mostly Microsoft
IIS/DHCP/Exchange though) and I have to say, they didn't work well
there.  I have no doubt you could probably do better than IIS 6 though.

> Maybe you and your extended "me" (people you know of) will never add any
> other options in this listobx, but i doesnt mean nobody will.
> 
> Concerning usability, it doesnt makes things nearly unusable for the
> other 90 you know of, since they actually dont need to use any other
> parameters. More, to d

Re: network-manager-openvpn

[Luc Deschenaux]

Le mardi 22 septembre 2009 à 23:09 -0700, Dan Williams a écrit :
> On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote:
> > > > 1. It should be possible to activate simutaneously many openvpn
> > > > configurations using checkboxes instead of radiobuttons, (in server mode
> > > > also, say in a second time...).
> > > 
> > > Yes, this is something that's been on the map for a while but there was
> > > other stuff that we considered more important.  It will take some rework
> > > internally in NetworkManager, though NM 0.7 already has half the work
> > > done.
> > > 
> > > > 2. It should be possible to "import" any openvpn configuration file, eg:
> > > 
> > > The 0.7 openvpn plugin should already be able to import an openvpn
> > > connection, but I think we just never got around to implementing export.
> > 
> > Every configuration parameter should be importable/modifiable, not only
> > the ones used in a given configuration.
> > 
> > > What specific configuration were you having problems with?  Can you
> > > attach that config so we can see what's going on with it?
> > 
> > My config was attached :) But someone may need to use other parameters
> > as well.
> >  
> > > > * Options not modifiable actually by network-manager-openvpn should also
> > > > be gathered and displayed, eg: in a dynamic listbox like for the routes,
> > > > with an add button. There could be a pop-up in the first column to set
> > > > or change the option name, an editable field in the second column to set
> > > > or change its value.
> > > 
> > 
> > > 0.7 already provides the ability to specify custom routes to apply to
> > > the connection in addition to any routes sent by the server.
> > 
> > >  
> > Read slowly, im not talking about routes here, talking about all the
> > openvpn parameters that are not yet configurable/importable with the
> > current graphical interface. They could just be configured through or
> > imported into a single listbox as described above.
> 
> But that's *horrible* UI and not something I'd like to condone.  I'd
> rather add the options on an as-needed basis to ensure we don't just
> dump everything in, and find out that we overloaded the UI with 50
> options that almost nobody uses.  Which I suspect is true for at least
> half of openvpn's options, because they did absolutely no work in
> consolidating them and asking the people who requested the options what
> they were actually trying to accomplish to constrain the number of
> switches that openvpn supports.  I'm interested in making it work for 90
> - 95% of use-cases, but I don't think we should be designing for that
> last 5%, especially when it makes things nearly unusable for the other
> 90.
> 
> Dan

Your judgment is totally subjective. What I did suggest is not more
horrible than the UI to define routes actually, did you read
thoroughly ?...

I suggest a listbox in a another panel (like the routes panel) with an
popup or a text field to specify which option to set in the first
column , and a second column to set the value. 

Maybe you and your extended "me" (people you know of) will never add any
other options in this listobx, but i doesnt mean nobody will.

Concerning usability, it doesnt makes things nearly unusable for the
other 90 you know of, since they actually dont need to use any other
parameters. More, to display the listbox the user would need to press a
button, like for adding routes.

Concerning current usability, theres no way to specify missing openvpn
options people may need.

Objectively we cannot call it "openvpn GUI", but rather an uncomplete
version of an openvpn GUI.

It is like a ftp, pop3 or http client that doesnt implement the full
protocol. The only difference is that there is no alternative choice for
an openvpn GUI integrated to the network manager.

Sincerly,

L:üC:



___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Fri, 2009-09-11 at 04:27 +0200, Luc Deschenaux wrote:
> > > 1. It should be possible to activate simutaneously many openvpn
> > > configurations using checkboxes instead of radiobuttons, (in server mode
> > > also, say in a second time...).
> > 
> > Yes, this is something that's been on the map for a while but there was
> > other stuff that we considered more important.  It will take some rework
> > internally in NetworkManager, though NM 0.7 already has half the work
> > done.
> > 
> > > 2. It should be possible to "import" any openvpn configuration file, eg:
> > 
> > The 0.7 openvpn plugin should already be able to import an openvpn
> > connection, but I think we just never got around to implementing export.
> 
> Every configuration parameter should be importable/modifiable, not only
> the ones used in a given configuration.
> 
> > What specific configuration were you having problems with?  Can you
> > attach that config so we can see what's going on with it?
> 
> My config was attached :) But someone may need to use other parameters
> as well.
>  
> > > * Options not modifiable actually by network-manager-openvpn should also
> > > be gathered and displayed, eg: in a dynamic listbox like for the routes,
> > > with an add button. There could be a pop-up in the first column to set
> > > or change the option name, an editable field in the second column to set
> > > or change its value.
> > 
> 
> > 0.7 already provides the ability to specify custom routes to apply to
> > the connection in addition to any routes sent by the server.
> 
> >  
> Read slowly, im not talking about routes here, talking about all the
> openvpn parameters that are not yet configurable/importable with the
> current graphical interface. They could just be configured through or
> imported into a single listbox as described above.

But that's *horrible* UI and not something I'd like to condone.  I'd
rather add the options on an as-needed basis to ensure we don't just
dump everything in, and find out that we overloaded the UI with 50
options that almost nobody uses.  Which I suspect is true for at least
half of openvpn's options, because they did absolutely no work in
consolidating them and asking the people who requested the options what
they were actually trying to accomplish to constrain the number of
switches that openvpn supports.  I'm interested in making it work for 90
- 95% of use-cases, but I don't think we should be designing for that
last 5%, especially when it makes things nearly unusable for the other
90.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Luc Deschenaux]

> > 1. It should be possible to activate simutaneously many openvpn
> > configurations using checkboxes instead of radiobuttons, (in server mode
> > also, say in a second time...).
> 
> Yes, this is something that's been on the map for a while but there was
> other stuff that we considered more important.  It will take some rework
> internally in NetworkManager, though NM 0.7 already has half the work
> done.
> 
> > 2. It should be possible to "import" any openvpn configuration file, eg:
> 
> The 0.7 openvpn plugin should already be able to import an openvpn
> connection, but I think we just never got around to implementing export.

Every configuration parameter should be importable/modifiable, not only
the ones used in a given configuration.

> What specific configuration were you having problems with?  Can you
> attach that config so we can see what's going on with it?

My config was attached :) But someone may need to use other parameters
as well.
 
> > * Options not modifiable actually by network-manager-openvpn should also
> > be gathered and displayed, eg: in a dynamic listbox like for the routes,
> > with an add button. There could be a pop-up in the first column to set
> > or change the option name, an editable field in the second column to set
> > or change its value.
> 

> 0.7 already provides the ability to specify custom routes to apply to
> the connection in addition to any routes sent by the server.

>  
Read slowly, im not talking about routes here, talking about all the
openvpn parameters that are not yet configurable/importable with the
current graphical interface. They could just be configured through or
imported into a single listbox as described above.

Regards,

L:üc:

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

[Dan Williams]

On Mon, 2009-09-07 at 22:24 +0200, Luc Deschenaux wrote:
> Le dimanche 06 septembre 2009 à 19:12 +0200, Tim Niemueller a écrit : 
> > On 06.09.2009 18:27, Luc Deschenaux wrote:
> > > Hello !
> > 
> > Hello Luc.
> 
> Hello everybody !
> 
> > > Nice try, but you could do better :)
> > 
> > Feel free to send patches.
> 
> I know that patches are always welcome :) 
> But i dont have the time to make it work like everybody at first glance
> will expect it should, ie: allowing to import any valid openvpn
> configuration file.
> 
> Let me just send you, instead of a patch, a more serious analysis of
> what could make network-manager-openvpn less annoying:
> 
> 1. It should be possible to activate simutaneously many openvpn
> configurations using checkboxes instead of radiobuttons, (in server mode
> also, say in a second time...).

Yes, this is something that's been on the map for a while but there was
other stuff that we considered more important.  It will take some rework
internally in NetworkManager, though NM 0.7 already has half the work
done.

> 2. It should be possible to "import" any openvpn configuration file, eg:

The 0.7 openvpn plugin should already be able to import an openvpn
connection, but I think we just never got around to implementing export.
What specific configuration were you having problems with?  Can you
attach that config so we can see what's going on with it?

> * Copy the config (as a file or individual parameters in gconf) and
> patch it: parse options for actually supported parameters and patch or
> add "up", "down", "cd", ...
> 
> (using gconf to store openvpn parameters is much less cool when it's
> time to copy the configs directly from disk or to port the application,
> but it is ok to store the config location or other external details in
> gconf). 
> 
> * Options not modifiable actually by network-manager-openvpn should also
> be gathered and displayed, eg: in a dynamic listbox like for the routes,
> with an add button. There could be a pop-up in the first column to set
> or change the option name, an editable field in the second column to set
> or change its value.

0.7 already provides the ability to specify custom routes to apply to
the connection in addition to any routes sent by the server.  The plugin
does not yet support (nor I think does NM) using openvpn in a
multi-client server configuration, though peer-to-peer openvpn using a
shared secret should work just fine.

Dan

> > However, send them to the NM mailing list, as
> > I'm not longer an active developer on that project.
> > 
> It was the only mail address specified for the debian package.
> 
> Feel free to forward this mail to the mailing list for me or to send me
> the mailing list address. Thanks in advance !
> 
> Oh forget it i found the address :)
> 
> > > At least there should be a way to enable openvpn connections defined
> > > somewhere in /etc/openvpn or so. 
> > 
> > Not to do that was a concious design decision at that time.
> > > Or you could add a text field so that one could add options not
> > > supported by network-manager-openvpn, or that would be filled in when
> > > importing a configuration file.
> > 
> > That's not the way the applet was designed. The applet should cover most
> > of the typical use cases and make it easy to configure those. And from
> > my experience that works nicely. Though I haven't followed the recent
> > development and discussions. So my statements may be obsolete by now and
> > different decisions may have been made. I'm pretty sure though that a
> > "command line args" input field is the worst idea ever.
> 
> It just mean "anything should be done so that it works for every
> possible configuration" :)
> 
> > > ps: 
> > [...]
> > 
> > Contact the mailing list. But first you should go and read
> > http://catb.org/~esr/faqs/smart-questions.html and change your style of
> > writing. I wouldn't expect an answer otherwise.
> > 
> 
> I wrote first the mail impulsively, but with a smile :)
> Nothing agressive or disrespectful from my point of view.
> Isn't it better than no feedback at all ?
> 
> Beside this i didn't ask anything... it was only constructive remarks
> and suggestions.
> 
> Many openvpn users (me first) will never use this version of the
> network-manager-openvpn applet which is not handling the configuration
> they are using, and, after some waste of time trying to use it, will
> continue to run openvpn as a service, eventually starting additional
> openvpn processes manually or using kv

Re: network-manager-openvpn

[Luc Deschenaux]

Le dimanche 06 septembre 2009 à 19:12 +0200, Tim Niemueller a écrit : 
> On 06.09.2009 18:27, Luc Deschenaux wrote:
> > Hello !
> 
> Hello Luc.

Hello everybody !

> > Nice try, but you could do better :)
> 
> Feel free to send patches.

I know that patches are always welcome :) 
But i dont have the time to make it work like everybody at first glance
will expect it should, ie: allowing to import any valid openvpn
configuration file.

Let me just send you, instead of a patch, a more serious analysis of
what could make network-manager-openvpn less annoying:

1. It should be possible to activate simutaneously many openvpn
configurations using checkboxes instead of radiobuttons, (in server mode
also, say in a second time...).

2. It should be possible to "import" any openvpn configuration file, eg:

* Copy the config (as a file or individual parameters in gconf) and
patch it: parse options for actually supported parameters and patch or
add "up", "down", "cd", ...

(using gconf to store openvpn parameters is much less cool when it's
time to copy the configs directly from disk or to port the application,
but it is ok to store the config location or other external details in
gconf). 

* Options not modifiable actually by network-manager-openvpn should also
be gathered and displayed, eg: in a dynamic listbox like for the routes,
with an add button. There could be a pop-up in the first column to set
or change the option name, an editable field in the second column to set
or change its value.

> However, send them to the NM mailing list, as
> I'm not longer an active developer on that project.
> 
It was the only mail address specified for the debian package.

Feel free to forward this mail to the mailing list for me or to send me
the mailing list address. Thanks in advance !

Oh forget it i found the address :)

> > At least there should be a way to enable openvpn connections defined
> > somewhere in /etc/openvpn or so. 
> 
> Not to do that was a concious design decision at that time.
> > Or you could add a text field so that one could add options not
> > supported by network-manager-openvpn, or that would be filled in when
> > importing a configuration file.
> 
> That's not the way the applet was designed. The applet should cover most
> of the typical use cases and make it easy to configure those. And from
> my experience that works nicely. Though I haven't followed the recent
> development and discussions. So my statements may be obsolete by now and
> different decisions may have been made. I'm pretty sure though that a
> "command line args" input field is the worst idea ever.

It just mean "anything should be done so that it works for every
possible configuration" :)

> > ps: 
> [...]
> 
> Contact the mailing list. But first you should go and read
> http://catb.org/~esr/faqs/smart-questions.html and change your style of
> writing. I wouldn't expect an answer otherwise.
> 

I wrote first the mail impulsively, but with a smile :)
Nothing agressive or disrespectful from my point of view.
Isn't it better than no feedback at all ?

Beside this i didn't ask anything... it was only constructive remarks
and suggestions.

Many openvpn users (me first) will never use this version of the
network-manager-openvpn applet which is not handling the configuration
they are using, and, after some waste of time trying to use it, will
continue to run openvpn as a service, eventually starting additional
openvpn processes manually or using kvpnc, and keep in mind a bad image
of network-manager-openvpn. 

One could use kvpnc, or modify network-manager-openvpn, or reinvent the
wheel and write a configuration tool using standard openvpn
configuration files, for server and client configs, generating keys, and
write some glue to paste it in the gnome-network-manager applet.

But actually i need nothing, so i won't use, modify, write nor reinvent
anything... network-manager-openvpn was available so i tried it and
wasted time doing so...

>   Tim
> 

Regards,

L:üc:

ps: Past events forged my style :)

Le dimanche 06 septembre 2009 à 18:28 +0200, Luc Deschenaux a écrit :
Hello !
> 
> It tooks me days and hours, and learning how to use openvpn "manually"
> before understanding (while trying to import my configuration in order
> to enable it through the gnome-network-manager applet and seeing it
was
> not possible) that network-manager-openvpn is quite unusable and
> obsolete.
> 
> Nice try, but you could do better :)
> 
> At least there should be a way to enable openvpn connections defined
> somewhere in /etc/openvpn or so. 
> 
> Or you could add a text field so that one could add options not
> supported by network-manager-openvpn, or that would be filled in whe

Re: Network Manager - OpenVPN

[Casey Harkins]

Alexander Sandström Krantz wrote:
> Hi!
> When will the openvpn addon have build in support to change the 
> openvpn-configuration
> ns-cert-type server

I think it is possible to accomplish this using the gconf editor to 
modify the vpn configuration directly. I have a feeling (haven't tested) 
that if you do this, modifying the vpn connection settings through the 
network manager openvpn configuration dialog afterwards will overwrite 
the settings.

First configure everything else for your vpn connection through network 
manager. Then fire up the gconf configuration editor 
(Applications->System Tools->Configuration Editor on FC6) and find 
/system/networking/vpn_connections/YOUR_CONNECTION from the tree on the 
left. Then edit the value of vpn_data on the right. This is a list of 
the openvpn configuration options (i.e. key,value,key,value...etc).

I'm mostly guessing at this, but I vaguely remember modifying the 
openvpn configuration in this way with success in the past.

-casey
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Network Manager - OpenVPN

[Jon Nettleton]

On Mon, 2007-03-26 at 21:19 +0200, Alexander Sandström Krantz wrote:
> Hi!
> When will the openvpn addon have build in support to change the
> openvpn-configuration
> ns-cert-type server
> 
> or to be more precise, turn of the requirement for the ns-cert-type to
> be set to server. From what I've understood this way of determining if
> a certificate is a server or a client certificate is deprecated so the
> CA I use (CAcert) doesn't use this flag any more. At the moment I
> can't use Network Manager to connect to my VPN because of this, but
> instead I have run openvpn through my CLI. 
> 
> It would be nice to have this feature in the Network Manager OpenVPN
> addon.
> 
Please put feature requests like this in bugzilla.  I don't get emailed,
but tend to check pet projects I work on pretty religously.  This makes
it easier for me to post patches and have NM developers review them for
inclusion.

Jon

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Network Manager - OpenVPN

[Alexander Sandström Krantz]

Hi!
When will the openvpn addon have build in support to change the
openvpn-configuration
ns-cert-type server

or to be more precise, turn of the requirement for the ns-cert-type to be
set to server. From what I've understood this way of determining if a
certificate is a server or a client certificate is deprecated so the CA I
use (CAcert) doesn't use this flag any more. At the moment I can't use
Network Manager to connect to my VPN because of this, but instead I have run
openvpn through my CLI.

It would be nice to have this feature in the Network Manager OpenVPN addon.

Regards,
Alexander
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn remote port?

[Jim Popovitch]

On Mon, 2006-12-11 at 22:08 -0500, Dan Williams wrote:
> On Mon, 2006-12-11 at 18:15 -0500, Jim Popovitch wrote:
> > I keep hearing that.  I want to get involved in NM dev work,
> > specifically to help add two-phase auth.  I started to send you a
> 
> Two phase auth for WPA[2] Enterprise and 802.1x?

Yes.

-Jim P.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn remote port?

[Dan Williams]

On Mon, 2006-12-11 at 18:15 -0500, Jim Popovitch wrote:
> On Mon, 2006-12-11 at 17:48 -0500, Dan Williams wrote:
> > On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote:
> > > Is there a way to specify a non-standard remote port to use with
> > > network-manager-openvpn?  I don't see anything on the vpn config gui,
> > > nor could I find anything conclusive via Google.
> > 
> > Not yet; what's the config item and how is it used?
> > 
> > remote-port 3252
> 
> Hmm, I saw 1194 in the source code.  I worked around it by recompiling
> with my port. 
> 
> > something like that?  It's pretty trivial to add to the code, but the
> > GUI bits are a disaster at the moment.
> 
> I keep hearing that.  I want to get involved in NM dev work,
> specifically to help add two-phase auth.  I started to send you a

Two phase auth for WPA[2] Enterprise and 802.1x?

Dan

> private email abt this last week, but held off as I'm not sure who does
> what wrt NM and I didn't want to step on anyone's work.
> 
> -Jim P.
> 

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn remote port?

[Jim Popovitch]

On Mon, 2006-12-11 at 17:48 -0500, Dan Williams wrote:
> On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote:
> > Is there a way to specify a non-standard remote port to use with
> > network-manager-openvpn?  I don't see anything on the vpn config gui,
> > nor could I find anything conclusive via Google.
> 
> Not yet; what's the config item and how is it used?
> 
> remote-port 3252

Hmm, I saw 1194 in the source code.  I worked around it by recompiling
with my port. 

> something like that?  It's pretty trivial to add to the code, but the
> GUI bits are a disaster at the moment.

I keep hearing that.  I want to get involved in NM dev work,
specifically to help add two-phase auth.  I started to send you a
private email abt this last week, but held off as I'm not sure who does
what wrt NM and I didn't want to step on anyone's work.

-Jim P.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn remote port?

[Dan Williams]

On Fri, 2006-12-08 at 18:22 -0500, Jim Popovitch wrote:
> Is there a way to specify a non-standard remote port to use with
> network-manager-openvpn?  I don't see anything on the vpn config gui,
> nor could I find anything conclusive via Google.

Not yet; what's the config item and how is it used?

remote-port 3252

something like that?  It's pretty trivial to add to the code, but the
GUI bits are a disaster at the moment.

Dan

> Tia,
> 
> -Jim P.
> 
> ___
> NetworkManager-list mailing list
> NetworkManager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

network-manager-openvpn remote port?

[Jim Popovitch]

Is there a way to specify a non-standard remote port to use with
network-manager-openvpn?  I don't see anything on the vpn config gui,
nor could I find anything conclusive via Google.

Tia,

-Jim P.

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

more options for network-manager-openvpn

[Brice Goglin]

Hi,

I am using openvpn regularly and would like to integrate my VPN
connections in NetworkManager. But I have several non-trivial options in
my openvpn configuration file (such as rport, lport, ping, ping-restart,
mute-replay-warning, ...). Is there any way to pass these options to
network-manager-openvpn ? Something simple like a text-box where the
user can enter something that would be appended to the openvpn command
line might be enough.

Thanks,
Brice

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list