[Desktop-packages] [Bug 1970068] Re: L2TP+IPSec not working after upgrade to 22.04 LTS

2022-04-24 Thread Douglas Kosovic
I think this is a duplicate of the following, although the xl2tpd errors 
manifest slightly differently :
https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/1951832
https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/1968336

But as others have confirmed, Ubuntu 22.05's xl2tpd-1.3.16-1 is broken,
so the most likely culprit.


network-manager-l2tp uses kl2tpd as its default L2TP daemon and falls back to 
xl2tpd if it can't find kl2tpd. To confirm it is only xl2tpd that is broken for 
you, try installing kl2tpd with the following :

sudo apt install golang-go

go install "github.com/katalix/go-l2tp/...@latest"
sudo mkdir /usr/local/sbin
sudo cp go/bin/kl2tpd /usr/local/sbin

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1970068

Title:
  L2TP+IPSec not working after upgrade to 22.04 LTS

Status in network-manager package in Ubuntu:
  New
Status in network-manager-l2tp package in Ubuntu:
  New
Status in ppp package in Ubuntu:
  New
Status in xl2tpd package in Ubuntu:
  New

Bug description:
  In 20.04LTS i was able to connect to my work over the L2TP tunel. Now
  it seems like this in journald:

  kwi 24 01:00:37 nm-l2tp-service[11368]: xl2tpd started with pid 11433
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Not looking for kernel 
SAref support.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Using l2tp kernel 
support.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: xl2tpd version 
xl2tpd-1.3.16 started on crushXnitro PID:11433
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Written by Mark 
Spencer, Copyright (C) 1998, Adtran, Inc.
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Forked by Scott Balmos 
and David Stipp, (C) 2001
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Inherited by Jeff 
McAdams, (C) 2002
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Forked again by 
Xelerance (www.xelerance.com) (C) 2006-2016
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Listening on IP address 
0.0.0.0, port 49636
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Connecting to host 
X.X.X.X, port 1701
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Connection established 
to X.X.X.X, 1701.  Local: 19994, Remote: 201 (ref=0/0).
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Calling on tunnel 19994
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: Call established with 
X.X.X.X, Local: 65441, Remote: 142, Serial: 1 (ref=0/0)
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: start_pppd: I'm running:
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "/usr/sbin/pppd"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "plugin"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "pppol2tp.so"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "pppol2tp"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "7"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "passive"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "nodetach"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: ":"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: "file"
  kwi 24 01:00:37 NetworkManager[11433]: xl2tpd[11433]: 
"/run/nm-l2tp-bd8ac49b-a2e9-4094-91dc-17a13ce61ec8/ppp-options"
  kwi 24 01:00:37 pppd[11434]: Plugin pppol2tp.so loaded.
  kwi 24 01:00:37 pppd[11434]: Plugin 
/usr/lib/pppd/2.4.9/nm-l2tp-pppd-plugin.so loaded.
  kwi 24 01:00:37 pppd[11434]: pppd 2.4.9 started by root, uid 0
  kwi 24 01:00:37 pppd[11434]: Using interface ppp0
  kwi 24 01:00:37 pppd[11434]: Connect: ppp0 <-->
  kwi 24 01:00:37 pppd[11434]: Overriding mtu 1500 to 1400
  kwi 24 01:00:37 pppd[11434]: Overriding mru 1500 to mtu value 1400
  kwi 24 01:00:37 NetworkManager[1017]:   [1650754837.9839] manager: 
(ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/6)
  kwi 24 01:00:38 pppd[11434]: CHAP authentication succeeded
  kwi 24 01:00:38 charon[11397]: 10[KNL] interface ppp0 activated
  kwi 24 01:00:38 charon[11397]: 13[KNL] fe80::81ee:6717:6637:2084 appeared on 
ppp0
  kwi 24 01:00:38 charon[11397]: 14[KNL] flags changed for 
fe80::81ee:6717:6637:2084 on ppp0
  kwi 24 01:00:38 pppd[11434]: local  LL address fe80::81ee:6717:6637:2084
  kwi 24 01:00:38 pppd[11434]: remote LL address fe80::::00f0:0c0e
  kwi 24 01:00:38 charon[11397]: 16[KNL] 192.168.57.181 appeared on ppp0
  kwi 24 01:00:38 NetworkManager[1017]:   [1650754838.0741] device 
(ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', 
sys-iface-state: 'external')
  kwi 24 01:00:38 charon[11397]: 08[KNL] 192.168.57.181 disappeared from ppp0
  kwi 24 01:00:38 charon[11397]: 10[KNL] 192.168.57.181 appeared on ppp0
  kwi 24 01:00:38 NetworkManager[1017]:   [1650754838.0751] device 
(ppp0): state change: unavailable -> disconnected (reason 'none', 
sys-iface-state: 'external')
  kwi 24 01:00:38 

[Desktop-packages] [Bug 1890814] Re: Handle PPP non-compliant success packets

2021-02-25 Thread Douglas Kosovic
Nim's status change of no longer affects ppp I think was just a mistake
and rectified, but the rectification wasn't recorded in a new message.

This bug report no longer affects ppp >= 2.4.9, as it was fixed upstream
and is the reason the corresponding Debian bug was closed.

This SRU patch request is for Ubuntu 20.04 which is still using an older
ppp.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ppp in Ubuntu.
https://bugs.launchpad.net/bugs/1890814

Title:
  Handle PPP non-compliant success packets

Status in ppp package in Ubuntu:
  Confirmed
Status in ppp package in Debian:
  Fix Released

Bug description:
  [Impact]
  According to RFC2759, the format of PPP success packets is :

  "S= M="

  Recently Windows Server 2019 has started producing non-complaint PPP
  success packets which have a space missing before the M= characters.

  PPP based (e.g. PPTP, L2TP, etc) VPN clients connecting to an affected
  Windows Server 2019 VPN server will get the following error message
  during MS-CHAPv2 authentication :

 MS-CHAPv2 Success packet is badly formed

  
  If the following upstream ppp patch is applied, it will handle the 
non-compliant, missing-space before M= success packets :

  
https://github.com/paulusmack/ppp/commit/3cd95baf3f1de1d5a9bc89be0f4c3215ceb5aefe.patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1890814/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1890814] Re: Handle PPP non-compliant success packets

2020-08-07 Thread Douglas Kosovic
** Bug watch added: Debian Bug tracker #968040
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968040

** Also affects: ppp (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968040
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ppp in Ubuntu.
https://bugs.launchpad.net/bugs/1890814

Title:
  Handle PPP non-compliant success packets

Status in ppp package in Ubuntu:
  New
Status in ppp package in Debian:
  Unknown

Bug description:
  [Impact]
  According to RFC2759, the format of PPP success packets is :

  "S= M="

  Recently Windows Server 2019 has started producing non-complaint PPP
  success packets which have a space missing before the M= characters.

  PPP based (e.g. PPTP, L2TP, etc) VPN clients connecting to an affected
  Windows Server 2019 VPN server will get the following error message
  during MS-CHAPv2 authentication :

 MS-CHAPv2 Success packet is badly formed

  
  If the following upstream ppp patch is applied, it will handle the 
non-compliant, missing-space before M= success packets :

  
https://github.com/paulusmack/ppp/commit/3cd95baf3f1de1d5a9bc89be0f4c3215ceb5aefe.patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1890814/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1890814] Re: Handle PPP non-compliant success packets

2020-08-07 Thread Douglas Kosovic
macOS already handles the missing space before M=, extract from :
https://opensource.apple.com/source/ppp/ppp-862.120.2/Helpers/pppd/chap_ms.c.auto.html

//we'll allow the missing-space case from the server, even though
//it's non-conforming to spec!
dbglog("Rcvd non-conforming MSCHAPv2 Success packet, len=%d", len);
if(len >= 2 && !strncmp((char*)msg, "M=", 2))
msg += 2;
else
{
error("MS-CHAPv2 Success packet is badly formed.");
return 0;
}

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ppp in Ubuntu.
https://bugs.launchpad.net/bugs/1890814

Title:
  Handle PPP non-compliant success packets

Status in ppp package in Ubuntu:
  New
Status in ppp package in Debian:
  Unknown

Bug description:
  [Impact]
  According to RFC2759, the format of PPP success packets is :

  "S= M="

  Recently Windows Server 2019 has started producing non-complaint PPP
  success packets which have a space missing before the M= characters.

  PPP based (e.g. PPTP, L2TP, etc) VPN clients connecting to an affected
  Windows Server 2019 VPN server will get the following error message
  during MS-CHAPv2 authentication :

 MS-CHAPv2 Success packet is badly formed

  
  If the following upstream ppp patch is applied, it will handle the 
non-compliant, missing-space before M= success packets :

  
https://github.com/paulusmack/ppp/commit/3cd95baf3f1de1d5a9bc89be0f4c3215ceb5aefe.patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1890814/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1890814] [NEW] Handle PPP non-compliant success packets

2020-08-07 Thread Douglas Kosovic
Public bug reported:

[Impact]
According to RFC2759, the format of PPP success packets is :

"S= M="

Recently Windows Server 2019 has started producing non-complaint PPP
success packets which have a space missing before the M= characters.

PPP based (e.g. PPTP, L2TP, etc) VPN clients connecting to an affected
Windows Server 2019 VPN server will get the following error message
during MS-CHAPv2 authentication :

   MS-CHAPv2 Success packet is badly formed


If the following upstream ppp patch is applied, it will handle the 
non-compliant, missing-space before M= success packets :

https://github.com/paulusmack/ppp/commit/3cd95baf3f1de1d5a9bc89be0f4c3215ceb5aefe.patch

** Affects: ppp (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: sru

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ppp in Ubuntu.
https://bugs.launchpad.net/bugs/1890814

Title:
  Handle PPP non-compliant success packets

Status in ppp package in Ubuntu:
  New

Bug description:
  [Impact]
  According to RFC2759, the format of PPP success packets is :

  "S= M="

  Recently Windows Server 2019 has started producing non-complaint PPP
  success packets which have a space missing before the M= characters.

  PPP based (e.g. PPTP, L2TP, etc) VPN clients connecting to an affected
  Windows Server 2019 VPN server will get the following error message
  during MS-CHAPv2 authentication :

 MS-CHAPv2 Success packet is badly formed

  
  If the following upstream ppp patch is applied, it will handle the 
non-compliant, missing-space before M= success packets :

  
https://github.com/paulusmack/ppp/commit/3cd95baf3f1de1d5a9bc89be0f4c3215ceb5aefe.patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1890814/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1849930] Re: Additional L2TP VPN Breaks First VPN

2019-11-01 Thread Douglas Kosovic
** Project changed: l2tp-ipsec-vpn => ubuntu

** Changed in: ubuntu
   Status: New => Confirmed

** Package changed: ubuntu => network-manager-l2tp (Ubuntu)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-control-center in Ubuntu.
https://bugs.launchpad.net/bugs/1849930

Title:
  Additional L2TP VPN Breaks First VPN

Status in gnome-control-center:
  New
Status in NetworkManager:
  New
Status in strongSwan:
  New
Status in gnome-control-center package in Ubuntu:
  Incomplete
Status in network-manager-l2tp package in Ubuntu:
  Confirmed

Bug description:
  When I add only one L2TP VPN profile to gnome-control-center's Network
  > VPN settings, it works fine.

  However, if I add a 2nd L2TP VPN, the 2nd L2TP VPN, not only doesn't
  work, but it corrupts the first L2TP VPN so that it too stops working.

  Furthermore, if I remove 2nd L2TP VPN profile (that corrupted the
  first L2TP VPN) this does NOT repair the corruption to the first L2TP
  VPN, it remains corrupted.

  Additionally, removing all VPN profiles and re-adding the first one
  back, doesn't repair the corruption. Rebooting and adding them back
  doesn't work either.

  The only thing that works, that I've found, is completely reinstalling
  Ubuntu 19.10. Please advise better workarounds than reinstalling.

  In case it matters, these additional packages were also required for
  my initial VPN setup:

  sudo apt-get install -y network-manager-l2tp network-manager-l2tp-
  gnome strongswan

  Here's what's in the syslog on a failed VPN Connection attempt:

  Oct 26 02:58:35 workstation5 NetworkManager[1241]:   [1572076715.5632] 
audit: op="connection-activate" uuid="1942cf95-93b1-4e74-a44a-947a46bffb5a" 
name="L2TP VPN1" pid=3531 uid=1000 result="success"
  Oct 26 02:58:35 workstation5 NetworkManager[1241]:   [1572076715.5702] 
vpn-connection[0x5642f421c750,1932cf95-91b1-4e85-a44a-498a56befb5a,"L2TP 
VPN1",0]: Started the VPN service, PID 7273
  Oct 26 02:58:35 workstation5 NetworkManager[1241]:   [1572076715.5747] 
vpn-connection[0x5642f421c750,1932cf95-91b1-4e85-a44a-498a56befb5a,"L2TP 
VPN1",0]: Saw the service appear; activating connection
  Oct 26 02:58:35 workstation5 NetworkManager[1241]:   [1572076715.6566] 
vpn-connection[0x5642f421c750,1932cf95-91b1-4e85-a44a-498a56befb5a,"L2TP 
VPN1",0]: VPN connection: (ConnectInteractive) reply received
  Oct 26 02:58:35 workstation5 NetworkManager[1241]: Stopping strongSwan IPsec 
failed: starter is not running
  Oct 26 02:58:37 workstation5 NetworkManager[1241]: Starting strongSwan 5.7.2 
IPsec [starter]...
  Oct 26 02:58:37 workstation5 NetworkManager[1241]: Loading config setup
  Oct 26 02:58:37 workstation5 NetworkManager[1241]: Loading conn 
'1942cf95-93b1-4e74-a44a-947a46bffb5a'
  Oct 26 02:58:37 workstation5 NetworkManager[1241]: found netkey IPsec stack
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: Stopping strongSwan 
IPsec...
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: initiating Main Mode 
IKE_SA 1942cf95-93b1-4e74-a44a-947a46bffb5a[1] to 49.230.24.121
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: generating ID_PROT request 
0 [ SA V V V V V ]
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: sending packet: from 
192.168.1.2[500] to 49.230.24.121[500] (236 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received packet: from 
49.230.24.121[500] to 192.168.1.2[500] (156 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: parsed ID_PROT response 0 
[ SA V V V V ]
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received XAuth vendor ID
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received DPD vendor ID
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received FRAGMENTATION 
vendor ID
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received NAT-T (RFC 3947) 
vendor ID
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: selected proposal: 
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: generating ID_PROT request 
0 [ KE No NAT-D NAT-D ]
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: sending packet: from 
192.168.1.2[500] to 49.230.24.121[500] (244 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received packet: from 
49.230.24.121[500] to 192.168.1.2[500] (244 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: parsed ID_PROT response 0 
[ KE No NAT-D NAT-D ]
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: local host is behind NAT, 
sending keep alives
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: generating ID_PROT request 
0 [ ID HASH ]
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: sending packet: from 
192.168.1.2[4500] to 49.230.24.121[4500] (68 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: received packet: from 
49.230.24.121[500] to 192.168.1.2[500] (68 bytes)
  Oct 26 02:58:48 workstation5 NetworkManager[1241]: invalid HASH_V1 payload 

[Desktop-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection

2019-01-20 Thread Douglas Kosovic
Comment 6 and 7 in the upstream GNOME NetworkManager-pptp bug report :
https://bugzilla.gnome.org/show_bug.cgi?id=785771#c6
are relevant to this bug (but not the 'cp -a' issue).

As mentioned, the following exit in /etc/ppp/ip-up.d/000resolvconf when
the interface is managed by NM, seems the right solution.

case "$6" in
  nm-pptp-service-*|nm-l2tp-service-*|/org/freedesktop/NetworkManager/PPP/*)
# NetworkManager handles it
exit 0
;;
esac

Perhaps the exit should be added to /etc/ppp/ip-up.d/usepeerdns for
instances when resolvconf package isn't installed?

** Bug watch added: GNOME Bug Tracker #785771
   https://bugzilla.gnome.org/show_bug.cgi?id=785771

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1778946

Title:
  No dns resolution after closing a vpn/pptp connection

Status in network-manager package in Ubuntu:
  Confirmed
Status in ppp package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  step to reproduce

  set a VPN connection configured to connect a Microsoft vpn server
  (pptp)

  internet acces is ok

  enable the vpn connection using the applet on the top right corner of
  the desktop

  internet still ok
  ping works

  disable the vpn connection

  ping doesn't works with a host but works if i specify an ip address

  ping: xx.net: Nom ou service inconnu

  As a workaround, i disable the ethernet link and re-enable it

  name resolution is now ok

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jun 27 18:09:30 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-06-03 (1484 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  IpRoute:
   default via 192.168.0.254 dev eth0 proto dhcp metric 20100 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
  IwConfig:
   lono wireless extensions.
   
   eth0  no wireless extensions.
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  RfKill:
   
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE  DBUS-PATH  
CONNECTION   CON-UUID  CON-PATH 
  
   eth0ethernet  connected  /org/freedesktop/NetworkManager/Devices/2  
Connexion filaire 1  94806bba-1c68-46b6-87f4-a3aff6dd  
/org/freedesktop/NetworkManager/ActiveConnection/6 
   lo  loopback  unmanaged  /org/freedesktop/NetworkManager/Devices/1  --   
----
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  
WIFI-HW  WIFI WWAN-HW  WWAN
   running  1.10.6   connected (site only)  started  limited   enabled 
enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection

2019-01-19 Thread Douglas Kosovic
I wasn't able to redirect the stderr from the following line in /etc/ppp
/ip-up.d/usepeerdns (probably because of something pppd is doing) :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

So I modified the cp.c source from the coreutils package and redirected
stderr to a file.

The error message I now see is :


cp: failed to preserve ownership for 
'/run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0': Operation not 
permitted


cp.c is using the lchown() function which is failing with that message.

Looks like only preserving ownership is failing as I tried the following
and it works:

cp --preserve=mode,timestamps "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-
backup.$PPP_IFACE"

The way /run is mounted might be the reason why 'cp -a' and lchown() is failing.
 

Ignore what I said able $? being 0 after the cp -a line. Doing the
following line confirms $? is 1 :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE" || echo
ERROR $? >> /tmp/usepeerdns-up.log

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1778946

Title:
  No dns resolution after closing a vpn/pptp connection

Status in network-manager package in Ubuntu:
  Confirmed
Status in ppp package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  step to reproduce

  set a VPN connection configured to connect a Microsoft vpn server
  (pptp)

  internet acces is ok

  enable the vpn connection using the applet on the top right corner of
  the desktop

  internet still ok
  ping works

  disable the vpn connection

  ping doesn't works with a host but works if i specify an ip address

  ping: xx.net: Nom ou service inconnu

  As a workaround, i disable the ethernet link and re-enable it

  name resolution is now ok

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jun 27 18:09:30 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-06-03 (1484 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  IpRoute:
   default via 192.168.0.254 dev eth0 proto dhcp metric 20100 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
  IwConfig:
   lono wireless extensions.
   
   eth0  no wireless extensions.
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  RfKill:
   
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE  DBUS-PATH  
CONNECTION   CON-UUID  CON-PATH 
  
   eth0ethernet  connected  /org/freedesktop/NetworkManager/Devices/2  
Connexion filaire 1  94806bba-1c68-46b6-87f4-a3aff6dd  
/org/freedesktop/NetworkManager/ActiveConnection/6 
   lo  loopback  unmanaged  /org/freedesktop/NetworkManager/Devices/1  --   
----
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  
WIFI-HW  WIFI WWAN-HW  WWAN
   running  1.10.6   connected (site only)  started  limited   enabled 
enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection

2019-01-17 Thread Douglas Kosovic
Sorry ignore comment #16 as the following line in /etc/ppp/ip-
up.d/usepeerdns will exit because of the '#!/bin/sh -e' shebang
line:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"


So my original suggestion of replacing the following line:

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

was correct and won't prematurely exit.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1778946

Title:
  No dns resolution after closing a vpn/pptp connection

Status in network-manager package in Ubuntu:
  Confirmed
Status in ppp package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  step to reproduce

  set a VPN connection configured to connect a Microsoft vpn server
  (pptp)

  internet acces is ok

  enable the vpn connection using the applet on the top right corner of
  the desktop

  internet still ok
  ping works

  disable the vpn connection

  ping doesn't works with a host but works if i specify an ip address

  ping: xx.net: Nom ou service inconnu

  As a workaround, i disable the ethernet link and re-enable it

  name resolution is now ok

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jun 27 18:09:30 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-06-03 (1484 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  IpRoute:
   default via 192.168.0.254 dev eth0 proto dhcp metric 20100 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
  IwConfig:
   lono wireless extensions.
   
   eth0  no wireless extensions.
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  RfKill:
   
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE  DBUS-PATH  
CONNECTION   CON-UUID  CON-PATH 
  
   eth0ethernet  connected  /org/freedesktop/NetworkManager/Devices/2  
Connexion filaire 1  94806bba-1c68-46b6-87f4-a3aff6dd  
/org/freedesktop/NetworkManager/ActiveConnection/6 
   lo  loopback  unmanaged  /org/freedesktop/NetworkManager/Devices/1  --   
----
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  
WIFI-HW  WIFI WWAN-HW  WWAN
   running  1.10.6   connected (site only)  started  limited   enabled 
enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection

2019-01-17 Thread Douglas Kosovic
I can confirm the issue is the following line in /etc/ppp/ip-
up.d/usepeerdns as previously mentioned :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

The variable expansion of that line is :
cp -a /run/systemd/resolve/stub-resolv.conf 
/run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

I had to modify the shebang line of that script from :
  #!/bin/sh -e
to :
  #!/bin/sh
to get past that line and output debugging output I inserted, which included :

ls -l /run/systemd/resolve/stub-resolv.conf
-rw-r--r-- 1 systemd-resolve systemd-resolve 720 Jan 17 21:47 
/run/systemd/resolve/stub-resolv.conf

ls -l /run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0
-rw--- 1 root root 720 Jan 17 21:47 
/run/systemd/resolve/stub-resolv.conf.pppd-backup.ppp0

So 'cp -a' isn't copying the permissions. Oddly, $? is 0 after running
that 'cp -a' line, therefor seems correct, also umask is 0022, so I'm
not sure what is going wrong.


Anyway a fix seems to be to change the following line in 
/etc/ppp/ip-up.d/usepeerdns from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"


For Ubuntu 18.04 setups that have the pppconfig package installed, the
following lines in /etc/ppp/ip-up.d/0dns-up probably should be changed
from :

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

to:

/bin/cp -Lp "$RESOLVCONF" "$RESOLVBAK" || exit 1
chmod 644 "$RESOLVBAK" || exit 1
/bin/cp -Lp "$TEMPRESOLV" "$RESOLVCONF" || exit 1
chmod 644 "$RESOLVCONF" || exit 1

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1778946

Title:
  No dns resolution after closing a vpn/pptp connection

Status in network-manager package in Ubuntu:
  Confirmed
Status in ppp package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  step to reproduce

  set a VPN connection configured to connect a Microsoft vpn server
  (pptp)

  internet acces is ok

  enable the vpn connection using the applet on the top right corner of
  the desktop

  internet still ok
  ping works

  disable the vpn connection

  ping doesn't works with a host but works if i specify an ip address

  ping: xx.net: Nom ou service inconnu

  As a workaround, i disable the ethernet link and re-enable it

  name resolution is now ok

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jun 27 18:09:30 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-06-03 (1484 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  IpRoute:
   default via 192.168.0.254 dev eth0 proto dhcp metric 20100 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
  IwConfig:
   lono wireless extensions.
   
   eth0  no wireless extensions.
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  RfKill:
   
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE  DBUS-PATH  
CONNECTION   CON-UUID  CON-PATH 
  
   eth0ethernet  connected  /org/freedesktop/NetworkManager/Devices/2  
Connexion filaire 1  94806bba-1c68-46b6-87f4-a3aff6dd  
/org/freedesktop/NetworkManager/ActiveConnection/6 
   lo  loopback  unmanaged  /org/freedesktop/NetworkManager/Devices/1  --   
----
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  
WIFI-HW  WIFI WWAN-HW  WWAN
   running  1.10.6   connected (site only)  started  limited   enabled 
enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1778946] Re: No dns resolution after closing a vpn/pptp connection

2019-01-17 Thread Douglas Kosovic
Correction the following line in /etc/ppp/ip-up.d/usepeerdns
probably should be changed from :

cp -a "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

to:

cp -Lp "$REALRESOLVCONF" "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"
chmod 644 "$REALRESOLVCONF.pppd-backup.$PPP_IFACE"

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1778946

Title:
  No dns resolution after closing a vpn/pptp connection

Status in network-manager package in Ubuntu:
  Confirmed
Status in ppp package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  Confirmed

Bug description:
  step to reproduce

  set a VPN connection configured to connect a Microsoft vpn server
  (pptp)

  internet acces is ok

  enable the vpn connection using the applet on the top right corner of
  the desktop

  internet still ok
  ping works

  disable the vpn connection

  ping doesn't works with a host but works if i specify an ip address

  ping: xx.net: Nom ou service inconnu

  As a workaround, i disable the ethernet link and re-enable it

  name resolution is now ok

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: network-manager 1.10.6-2ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Jun 27 18:09:30 2018
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
  InstallationDate: Installed on 2014-06-03 (1484 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  IpRoute:
   default via 192.168.0.254 dev eth0 proto dhcp metric 20100 
   169.254.0.0/16 dev eth0 scope link metric 1000 
   192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.47 metric 100
  IwConfig:
   lono wireless extensions.
   
   eth0  no wireless extensions.
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  RfKill:
   
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to bionic on 2018-05-10 (48 days ago)
  nmcli-dev:
   DEVICE  TYPE  STATE  DBUS-PATH  
CONNECTION   CON-UUID  CON-PATH 
  
   eth0ethernet  connected  /org/freedesktop/NetworkManager/Devices/2  
Connexion filaire 1  94806bba-1c68-46b6-87f4-a3aff6dd  
/org/freedesktop/NetworkManager/ActiveConnection/6 
   lo  loopback  unmanaged  /org/freedesktop/NetworkManager/Devices/1  --   
----
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  
WIFI-HW  WIFI WWAN-HW  WWAN
   running  1.10.6   connected (site only)  started  limited   enabled 
enabled  enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1778946/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 1692066] Re: [Request] Libreswan plugin for Network Manager

2017-10-27 Thread Douglas Kosovic
I suggest you file a Debian Request for Package (RFP) for 
network-manager-libreswan :
   https://wiki.debian.org/RFP

Once the package is in Debian Sid, it will automatically make its way to
Ubuntu.

Or if you are able to provide a package, an Intent to Package (ITP) :
   https://wiki.debian.org/ITP

libreswan was added to Debian Sid earlier in the year and it made its
way to Ubuntu 17.04.

Upstream in the GNOME Projects network-manager-libreswan GIT repository in the 
NEWS file, you'll notice network-manager-libreswan was renamed from 
network-manager-openswan at version 1.2
  https://git.gnome.org/browse/network-manager-libreswan/tree/

Debian/Ubuntu used to include network-manager-openswan, so that package
might be a good starting point for updating to network-manager-
libreswan.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1692066

Title:
  [Request] Libreswan plugin for Network Manager

Status in libreswan package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hello!

  I have the need to use Libreswan instead of strongswan to connect to
  an IPSec IKEv1 XAuth VPN in main mode without a group. Thing is
  strongswan doesn't support this configuration, so I explicitally need
  it. Nonetheless, libreswan is as developed as strongswan and it's
  widely used.

  using config files in /etc (ipsec.conf and .secrets) it's possible to
  correctly configure ipsec/libreswan, but needlessly to say, having the
  possibility to manage it via a GUI is 100 times better (and easier for
  "normal" users).

  In the current repositories (Zesty) I only found the libreswan's ipsec
  binaries (package libreswan), but not the network manager plugin
  (sources are available on github).

  I've tried to compile them, but I'm afraid they use a different path
  pattern than Ubuntu, so without making changes it's not possible to
  succesfully install it from sources.

  Thanks

  LibreSwan NetworkManager plugin sources:
  https://github.com/NetworkManager/network-manager-libreswan

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libreswan/+bug/1692066/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 264691] Re: Please add NM option for connecting to L2TP IPSEC VPN

2017-06-14 Thread Douglas Kosovic
network-manager-l2tp 1.2.6-2 was accepted into Debian sid :

   https://tracker.debian.org/pkg/network-manager-l2tp

The Debian package was automatically added to Ubuntu artful (17.10).

I've requested an Ubuntu backport of network-manager-l2tp from artful to
xenial (16.04) which includes intermediate zesty (17.04) and yakkety
(16:10) releases :

   https://bugs.launchpad.net/xenial-backports/+bug/1697934

Please vote for the backport by clicking the "this bug affects me" link
in the backport request.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/264691

Title:
  Please add NM option for connecting to L2TP IPSEC VPN

Status in NetworkManager:
  Unknown
Status in network-manager package in Ubuntu:
  Confirmed
Status in network-manager package in Debian:
  Invalid

Bug description:
  Binary package hint: network-manager

  Missing feature:

  You cannot connect to a (Microsoft) L2TP IPSEC VPN with Network
  Manager.

  The server I want to connect to expects a login / password and a PSK.

  When you do a connection in XP you can see the following details on a
  connection:

  Device name: L2TP
  Server type: PPP
  Authentication: MS CHAP v2
  IPSEC Encryption: IPSEC ESP 3DES
  Compression: MPPC

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/264691/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 264691] Re: Please add NM option for connecting to L2TP IPSEC VPN

2017-03-13 Thread Douglas Kosovic
There is now a new PPA, network-manager-l2tp 1.2.4 for 17.04 (zesty), 16.10 
(yakkety) and 16.04 (xenial) packages can be found here:
https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp

strongswan stable release updates for yakkety and xenial which fix the
aforementioned AppArmor name space issue were released in the last
couple of weeks. So I've decided to release PPA packages as Debian
strongswan doesn't have the fix yet. The network-manager-l2tp 1.2.4 PPA
packages on yakkety and xenial have explicit dependencies for the
versions of the strongswan packages with the fix.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/264691

Title:
  Please add NM option for connecting to L2TP IPSEC VPN

Status in NetworkManager:
  Unknown
Status in network-manager package in Ubuntu:
  Confirmed
Status in network-manager package in Debian:
  Invalid

Bug description:
  Binary package hint: network-manager

  Missing feature:

  You cannot connect to a (Microsoft) L2TP IPSEC VPN with Network
  Manager.

  The server I want to connect to expects a login / password and a PSK.

  When you do a connection in XP you can see the following details on a
  connection:

  Device name: L2TP
  Server type: PPP
  Authentication: MS CHAP v2
  IPSEC Encryption: IPSEC ESP 3DES
  Compression: MPPC

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/264691/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp


[Desktop-packages] [Bug 264691] Re: Please add NM option for connecting to L2TP IPSEC VPN

2016-07-12 Thread Douglas Kosovic
I've posted a summary of current NetworkManager-l2tp known issues and 
workarounds for Ubuntu and Debian here :
  https://github.com/nm-l2tp/network-manager-l2tp/issues/12

I haven't created a new network-manager-l2tp PPA because because of the
strongSwan AppArmor name space issue involving NetworkManager and also
some Ubuntu 16.04 users have had an issues with the system xl2tpd, but
not with a locally built copy. Unfortunately I haven't been able to
reproduce the xl2tpd issue since I changed computers a couple of months
ago.

I hope to submit a network-manager-l2tp package to Debian once the
strongSwan AppArmor issue has been resolved.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/264691

Title:
  Please add NM option for connecting to L2TP IPSEC VPN

Status in NetworkManager:
  Unknown
Status in network-manager package in Ubuntu:
  Confirmed
Status in network-manager package in Debian:
  Invalid

Bug description:
  Binary package hint: network-manager

  Missing feature:

  You cannot connect to a (Microsoft) L2TP IPSEC VPN with Network
  Manager.

  The server I want to connect to expects a login / password and a PSK.

  When you do a connection in XP you can see the following details on a
  connection:

  Device name: L2TP
  Server type: PPP
  Authentication: MS CHAP v2
  IPSEC Encryption: IPSEC ESP 3DES
  Compression: MPPC

To manage notifications about this bug go to:
https://bugs.launchpad.net/network-manager/+bug/264691/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp