search

nm-l2tp / NetworkManager-l2tp

L2TP and L2TP/IPsec support for NetworkManager
GNU General Public License v2.0
488 stars 84 forks source link

packaging on nixos #69

Closed teto closed 6 years ago

teto commented 6 years ago

Sorry if that's a bit out of scope. I am packaging l2tp for nixos as I need it for my work and the currently packaged version doesn't work. If you don't know about nixos, each package is installed in a very specific folder so paths need to be explicit. For instance strongswan is installed in '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0.

It's my first time using a vpn on linux so I am not too sure if it's my config or nixos fault or sthg else. Here is my progress on packaging https://github.com/NixOS/nixpkgs/issues/30147 so I have 2 questions:

I am currently looking at increasing charon's verbosity but here is my current log. I am not sure how to interpret it so any tip is welcome (using applet + nm 1.8.2, l2tp 1.2.8)

ct. 11 17:21:09 jedha NetworkManager[730]: Starting strongSwan 5.6.0 IPsec [starter]...
oct. 11 17:21:09 jedha NetworkManager[730]: Loading config setup
oct. 11 17:21:09 jedha NetworkManager[730]: Loading conn '74615f38-bdb3-424b-898c-440e3f490289'
oct. 11 17:21:09 jedha ipsec_starter[6301]: Starting strongSwan 5.6.0 IPsec [starter]...
oct. 11 17:21:09 jedha ipsec_starter[6301]: Loading config setup
oct. 11 17:21:09 jedha ipsec_starter[6301]: Loading conn '74615f38-bdb3-424b-898c-440e3f490289'
oct. 11 17:21:09 jedha NetworkManager[730]: sh: modprobe : commande introuvable
oct. 11 17:21:09 jedha NetworkManager[730]: sh: modprobe : commande introuvable
oct. 11 17:21:09 jedha NetworkManager[730]: sh: modprobe : commande introuvable
oct. 11 17:21:09 jedha NetworkManager[730]: sh: modprobe : commande introuvable
oct. 11 17:21:09 jedha NetworkManager[730]: sh: modprobe : commande introuvable
oct. 11 17:21:09 jedha NetworkManager[730]: found netkey IPsec stack
oct. 11 17:21:09 jedha ipsec_starter[6301]: found netkey IPsec stack
oct. 11 17:21:09 jedha ipsec_starter[6315]: Attempting to start charon...
oct. 11 17:21:09 jedha charon[6316]: 00[DMN] Starting IKE charon daemon (strongSwan 5.6.0, Linux 4.13.5, x86_64)
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] PKCS11 module '<name>' lacks library path
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] dnscert plugin is disabled
oct. 11 17:21:09 jedha charon[6316]: 00[NET] using forecast interface eno1
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading ca certificates from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/cacerts'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading aa certificates from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/aacerts'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading ocsp signer certificates from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/ocspcerts'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading attribute certificates from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/acerts'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading crls from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/crls'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] loading secrets from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.secrets'
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] opening triplet file /nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.d/triplets.dat failed: No such file or directory
oct. 11 17:21:09 jedha charon[6316]: 00[CFG] no script for ext-auth script defined, disabled
oct. 11 17:21:09 jedha charon[6316]: 00[LIB] loaded plugins: charon unbound pkcs11 aesni aes des rc2 sha2 sha1 md5 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert pem af-alg fips-prf gmp curve25519 chapoly xcbc
oct. 11 17:21:09 jedha charon[6316]: 00[JOB] spawning 16 worker threads
oct. 11 17:21:09 jedha ipsec_starter[6315]: charon (6316) started after 120 ms
oct. 11 17:21:09 jedha charon[6316]: 05[CFG] received stroke: add connection '74615f38-bdb3-424b-898c-440e3f490289'
oct. 11 17:21:09 jedha charon[6316]: 05[CFG] added configuration '74615f38-bdb3-424b-898c-440e3f490289'
oct. 11 17:21:10 jedha charon[6316]: 06[CFG] rereading secrets
oct. 11 17:21:10 jedha charon[6316]: 06[CFG] loading secrets from '/nix/store/4b15381yxcychsiaip2cwrr923k03x07-strongswan-5.6.0/etc/ipsec.secrets'
oct. 11 17:21:10 jedha charon[6316]: 08[CFG] received stroke: initiate '74615f38-bdb3-424b-898c-440e3f490289'
oct. 11 17:21:10 jedha charon[6316]: 11[IKE] initiating Main Mode IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] to FAKEIP
oct. 11 17:21:10 jedha charon[6316]: 11[IKE] initiating Main Mode IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] to FAKEIP
oct. 11 17:21:10 jedha charon[6316]: 11[ENC] generating ID_PROT request 0 [ SA V V V V V ]
oct. 11 17:21:10 jedha charon[6316]: 11[NET] sending packet: from 192.168.0.129[500] to FAKEIP[500] (240 bytes)
oct. 11 17:21:14 jedha charon[6316]: 12[IKE] sending retransmit 1 of request message ID 0, seq 1
oct. 11 17:21:14 jedha charon[6316]: 12[NET] sending packet: from 192.168.0.129[500] to FAKEIP[500] (240 bytes)
oct. 11 17:21:20 jedha NetworkManager[730]: Stopping strongSwan IPsec...
oct. 11 17:21:20 jedha charon[6316]: 00[DMN] signal of type SIGINT received. Shutting down
oct. 11 17:21:20 jedha charon[6316]: 00[IKE] destroying IKE_SA in state CONNECTING without notification
oct. 11 17:21:20 jedha NetworkManager[730]: initiating Main Mode IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] to FAKEIP
oct. 11 17:21:20 jedha NetworkManager[730]: generating ID_PROT request 0 [ SA V V V V V ]
oct. 11 17:21:20 jedha NetworkManager[730]: sending packet: from 192.168.0.129[500] to FAKEIP[500] (240 bytes)
oct. 11 17:21:20 jedha NetworkManager[730]: sending retransmit 1 of request message ID 0, seq 1
oct. 11 17:21:20 jedha NetworkManager[730]: sending packet: from 192.168.0.129[500] to FAKEIP[500] (240 bytes)
oct. 11 17:21:20 jedha NetworkManager[730]: destroying IKE_SA in state CONNECTING without notification
oct. 11 17:21:20 jedha NetworkManager[730]: establishing connection '74615f38-bdb3-424b-898c-440e3f490289' failed
oct. 11 17:21:20 jedha ipsec_starter[6315]: child 6316 (charon) has quit (exit code 0)
oct. 11 17:21:20 jedha nm-l2tp-service[6271]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
oct. 11 17:21:20 jedha NetworkManager[730]: <warn>  [1507710080.2234] vpn-connection[0x1d010c0,74615f38-bdb3-424b-898c-440e3f490289,"Connexion VPN 1",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'
dkosovic commented 6 years ago

I did provide some advice to a previous nixos package and was grateful for a subsequent patch that was contributed for a 32bit build issue.

I'll try and answer your two questions, but will raise a number other issues and suggestions in subsequent messages.

is there a flag to configure Makefile.am's "dbusservicedir" via a configure flag ?

In Makefile.am dbusservicedir = $(sysconfdir)/dbus-1/system.d. I assume you mean using something more than the --sysconfdir configure switch. Typically `--sysconfdir=/etc' is specified on other linux distros.

Makefile.am and configure.ac are based on GNOME Project's NetworkManager-pptp and to a lesser extant NetworkManager-libreswan :

I try to track the changes GNOME Project NetworkManager VPN plug-ins do, especially NetworkManager-pptp.

I've had a look at some of the GNOME Project NetworkManager VPN plug-ins and they seem to be doing the same as this one for dbusservicedir. If you believe there should be a --dbus-service-dir configure switch to make life easier for nixos, perhaps it might be best to report it in the GNOME bugzilla as it would be useful for other NetworkManager VPN plug-in packages.

is it mandatory that strongswan and networkmanager l2tp share the same /etc folder ?

With the strongswan ipsec start and ipsec restart commands, there is no command-line switch or other means to override /etc/ipsec.secrets (or wherever ipsec.secrets is on nixos), unlike the config file which can be specified with --conf switch.

This VPN plug-in adds the following two lines to /etc/ipsec.secrets if the include line is missing :

# Following line was added by NetworkManager-l2tp
include /etc/ipsec.d/*.secrets

Then writes a secrets file called /etc/ipsec.d/nm-l2tp-ipsec-_UUID_.secrets where UUID from your log output is 74615f38-bdb3-424b-898c-440e3f490289

If you can find another means to inject the include line to /etc/ipsec.secrets, you'll be able to point it to whatever directory you want and won't need to share the /etc/ folder.

dkosovic commented 6 years ago

Looks like you are hitting the 10 second timeout of this VPN plug-in for establishing the IPsec connection and strongswan is getting killed.

The VPN server at your workplace might be using legacy ciphers that newer versions of strongSwan consider broken. Have a look at the user specified IPsec IKEv1 cipher suites section in the README.md file:

Ideally the stronger ciphers should be specified on the VPN server, if you can't you can use the phase 1 and 2 algorithms text boxes in the advanced section of the IPsec configuration dialog box.

See the "Querying VPN server for supported IPsec IKEv1 ciphers" section in the Wiki for the ciphers the VPN server supports :

dkosovic commented 6 years ago

You could also try doing the nixos equivalent of the following on the command-line to see if you can establish an IPsec connection:

sudo ipsec restart --config /var/run/nm-l2tp-ipsec-74615f38-bdb3-424b-898c-440e3f490289.conf --debug
sleep 2
sudo ipsec up 74615f38-bdb3-424b-898c-440e3f490289

sudo ipsec status

EDITED: replaced libreswan example with strongswan

dkosovic commented 6 years ago

Once you get the IPsec connection working, you might hit a number of L2TP issues.

You might need to stop the system xl2tpd server, see the following in the README :

xl2tpd will most likely truncate the nixos equivalent of the following files

See xl2tpd bugzilla report https://github.com/xelerance/xl2tpd/issues/132

With xl2tpd 1.3.10, STRLEN in file.h was increased to 100 from 80.

dkosovic commented 6 years ago

I was just looking at the following:

in particular the following lines :

AC_ARG_WITH([dbus-service-dir],
  [AS_HELP_STRING([--with-dbus-service-dir=PATH],[dbus service file directory])],
  [dbusservicedir="$withval"],
  [dbusservicedir='${datadir}/dbus-1/services'])
AC_SUBST([dbusservicedir])

I could do the appropriate modifications to add that option to this project if you think it is worthwhile, but it would also be good to have the modification upstream in the other GNOME Project VPN clients.

teto commented 6 years ago

First of all, let me thank you for the fantastic answers.

Don't worry about dbusservicedir. Nixos has to patch software all the time to deal with its unusual paths so it's not necessary to upstream it; it's fixed with a simple:

    substituteInPlace ./Makefile.am \
      --replace '$(sysconfdir)/dbus-1/system.d' "$out/etc/dbus-1/system.d"

https://github.com/teto/nixpkgs/blob/l2tp/pkgs/tools/networking/network-manager/l2tp.nix#L29

Strongswan configuration is also available at: https://github.com/teto/nixpkgs/blob/l2tp/pkgs/tools/networking/strongswan/default.nix

You have given me enough data to run a few tests (which I didn't have the opportunity to do today).

I've got a log from a colleague that successfully connected with libreswan (fedora). He hasn't added any custom cipher. Do you know if libreswan dropped "old" ciphers like strongswan did ?

Here is an excerpt from his log.

 pluto[5705]: Encryption algorithms:
1 pluto[5705]:   AES_CCM_16         IKEv1:     ESP     IKEv2:     ESP     FIPS  {256,192,*128}  (aes_ccm aes_ccm_c)
1 pluto[5705]:   AES_CCM_12         IKEv1:     ESP     IKEv2:     ESP     FIPS  {256,192,*128}  (aes_ccm_b)
1 pluto[5705]:   AES_CCM_8          IKEv1:     ESP     IKEv2:     ESP     FIPS  {256,192,*128}  (aes_ccm_a)
1 pluto[5705]:   3DES_CBC           IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  [*192]  (3des)
1 pluto[5705]:   CAMELLIA_CTR       IKEv1:     ESP     IKEv2:     ESP           {256,192,*128}
1 pluto[5705]:   CAMELLIA_CBC       IKEv1: IKE ESP     IKEv2: IKE ESP           {256,192,*128}  (camellia)
1 pluto[5705]:   AES_GCM_16         IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  {256,192,*128}  (aes_gcm aes_gcm_c)
1 pluto[5705]:   AES_GCM_12         IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  {256,192,*128}  (aes_gcm_b)
1 pluto[5705]:   AES_GCM_8          IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  {256,192,*128}  (aes_gcm_a)
1 pluto[5705]:   AES_CTR            IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  {256,192,*128}  (aesctr)
1 pluto[5705]:   AES_CBC            IKEv1: IKE ESP     IKEv2: IKE ESP     FIPS  {256,192,*128}  (aes)
1 pluto[5705]:   SERPENT_CBC        IKEv1: IKE ESP     IKEv2: IKE ESP           {256,192,*128}  (serpent)
1 pluto[5705]:   TWOFISH_CBC        IKEv1: IKE ESP     IKEv2: IKE ESP           {256,192,*128}  (twofish)
1 pluto[5705]:   TWOFISH_SSH        IKEv1: IKE         IKEv2: IKE ESP           {256,192,*128}  (twofish_cbc_ssh)
1 pluto[5705]:   CAST_CBC           IKEv1:     ESP     IKEv2:     ESP           {*128}  (cast)
1 pluto[5705]:   NULL               IKEv1:     ESP     IKEv2:     ESP           []
1 pluto[5705]: Hash algorithms:
1 pluto[5705]:   MD5                IKEv1: IKE         IKEv2:
1 pluto[5705]:   SHA1               IKEv1: IKE         IKEv2:             FIPS  (sha)
1 pluto[5705]:   SHA2_256           IKEv1: IKE         IKEv2:             FIPS  (sha2 sha256)
1 pluto[5705]:   SHA2_384           IKEv1: IKE         IKEv2:             FIPS  (sha384)
1 pluto[5705]:   SHA2_512           IKEv1: IKE         IKEv2:             FIPS  (sha512)
1 pluto[5705]: PRF algorithms:
1 pluto[5705]:   HMAC_MD5           IKEv1: IKE         IKEv2: IKE               (md5)
1 pluto[5705]:   HMAC_SHA1          IKEv1: IKE         IKEv2: IKE         FIPS  (sha sha1)
1 pluto[5705]:   HMAC_SHA2_256      IKEv1: IKE         IKEv2: IKE         FIPS  (sha2 sha256 sha2_256)
1 pluto[5705]:   HMAC_SHA2_384      IKEv1: IKE         IKEv2: IKE         FIPS  (sha384 sha2_384)
1 pluto[5705]:   HMAC_SHA2_512      IKEv1: IKE         IKEv2: IKE         FIPS  (sha512 sha2_512)
1 pluto[5705]: Integrity algorithms:
1 pluto[5705]:   HMAC_MD5_96        IKEv1: IKE ESP AH  IKEv2: IKE ESP AH        (md5 hmac_md5)
1 pluto[5705]:   HMAC_SHA1_96       IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (sha sha1 sha1_96 hmac_sha1)
1 pluto[5705]:   HMAC_SHA2_512_256  IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (sha512 sha2_512 hmac_sha2_512)
1 pluto[5705]:   HMAC_SHA2_384_192  IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (sha384 sha2_384 hmac_sha2_384)
1 pluto[5705]:   HMAC_SHA2_256_128  IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (sha2 sha256 sha2_256 hmac_sha2_256)
1 pluto[5705]:   AES_XCBC_96        IKEv1:     ESP AH  IKEv2:     ESP AH  FIPS  (aes_xcbc)
1 pluto[5705]:   AES_CMAC_96        IKEv1:     ESP AH  IKEv2:     ESP AH  FIPS  (aes_cmac)
1 pluto[5705]: DH algorithms:
1 pluto[5705]:   MODP1024           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH        (dh2)
1 pluto[5705]:   MODP1536           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH        (dh5)
1 pluto[5705]:   MODP2048           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (dh14)
1 pluto[5705]:   MODP3072           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (dh15)
1 pluto[5705]:   MODP4096           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (dh16)
1 pluto[5705]:   MODP6144           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (dh17)
1 pluto[5705]:   MODP8192           IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS  (dh18)
1 pluto[5705]:   DH19               IKEv1: IKE         IKEv2: IKE ESP AH  FIPS  (ecp_256)
1 pluto[5705]:   DH20               IKEv1: IKE         IKEv2: IKE ESP AH  FIPS  (ecp_384)
1 pluto[5705]:   DH21               IKEv1: IKE         IKEv2: IKE ESP AH  FIPS  (ecp_521)
1 pluto[5705]:   DH23               IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS
1 pluto[5705]:   DH24               IKEv1: IKE ESP AH  IKEv2: IKE ESP AH  FIPS

I will proceed with the tests you recommended and will update the issue. Thanks again

dkosovic commented 6 years ago

Over a month ago, libreswan was updated to version 3.21 on Fedora 26 and caused issues for some as algorithms were removed from the default set of allowed algorithms :

I've got to update the wiki known issues documentation for libreswan.

teto commented 6 years ago

I've added old ciphers and it works \o/ (well not completely because of nixos-related problems with the resolver). I leave this open until I get a fully working setup, in case I need to send a patch for L2TP. If not I will close it hopefully within a week. Thanks for your dedication

teto commented 6 years ago

Sorry I have a question about my current problem: Failed to create /etc/ppp/resolv.conf: No such file or directory. I have looked at the code but I am not sure of the code path. It seems like pppd is started by NetworkManager at the initiative of l2tp via dbus and its nm-l2tp-pppd-plugin.so .

Does l2tp control/sets the "/etc/ppp/resolv.conf" path ? via the (RUNDIR"/nm-l2tp-ppp-options-%s" file I suppose. From the man https://linux.die.net/man/8/pppd it seems the path should have been /var/run/ppp/resolv.conf ? so maybe that's a problem with the nixos ppp package that doesn't set "--localstatedir=/var":

Log:

. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: start_pppd: I'm running:
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "/nix/store/v2l5dhzzdyv9cv509n8zi6yjyyh97w2r-ppp-2.4.7/sbin/pppd"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "plugin"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "pppol2tp.so"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "pppol2tp"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "7"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "passive"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "nodetach"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: ":"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "file"
oct. 12 18:41:12 jedha NetworkManager[724]: xl2tpd[11118]: "/var/run/nm-l2tp-ppp-options-74615f38-bdb3-424b-898c-440e3f490289"
oct. 12 18:41:12 jedha pppd[11119]: Plugin pppol2tp.so loaded.
oct. 12 18:41:12 jedha pppd[11119]: Plugin /nix/store/i6cp0qx18x5gkfxjm0b49nngp9whp4sg-NetworkManager-l2tp-gnome-1.2.8/lib/pppd/2.4.7/nm-l2tp-pppd-plugin.so loaded.
oct. 12 18:41:12 jedha pppd[11119]: pppd 2.4.7 started by root, uid 0
oct. 12 18:41:12 jedha pppd[11119]: Using interface ppp0
oct. 12 18:41:12 jedha pppd[11119]: Connect: ppp0 <-->
oct. 12 18:41:12 jedha pppd[11119]: Overriding mtu 1500 to 1400
oct. 12 18:41:12 jedha pppd[11119]: Overriding mru 1500 to mtu value 1400
oct. 12 18:41:12 jedha pppd[11119]: CHAP authentication succeeded
oct. 12 18:41:12 jedha pppd[11119]: Failed to create /etc/ppp/resolv.conf: No such file or directory
dkosovic commented 6 years ago

The only code in this repo that affects resolv.conf was added by commit# https://github.com/nm-l2tp/network-manager-l2tp/commit/7328971a08d897641661e6d2539bc44351909a1d

With that commit, if "Automatic (VPN) Addresses Only" mode is enabled in the the IPv4 GUI settings, then the usepeerdns option isn't used in the nm-l2tp-ppp-options-UUID config file, which results in resolv.conf not being overridden.

NetworkManager has some impact on DNS resolution, it switched from DNSMasq to Systemd-resolved and caused some issues in the past :

Your suspicions on issues related to pppd not setting --localstatedir=/var configure switch seems plausible, but I'm not familiar enough with it.

dkosovic commented 6 years ago

Sorry forgot to answer the code path question.

NetworkManager-l2tp starts a child instance of xl2tpd and xl2tpd starts a child instance of pppd.

nm-l2tp-pppd-plugin.so is for the PPP authentication and supplies the username and password.

dkosovic commented 6 years ago

It is also possible to test your L2TP connection by starting xl2tpd from the command-line, but would need to remove nm-l2tp-pppd-plugin.so from the ppp options file (/var/run/nm-l2tp-ppp-options-74615f38-bdb3-424b-898c-440e3f490289) and provide your VPN credentials by other means, see xl2tpd/pppd docs on how to specify the credentials.

xl2tpd -D \
-c /var/run/nm-l2tp-xl2tpd-74615f38-bdb3-424b-898c-440e3f490289.conf \
-C /var/run/nm-l2tp-xl2tpd-control-74615f38-bdb3-424b-898c-440e3f490289 \
-p /var/run/nm-l2tp-xl2tpd-74615f38-bdb3-424b-898c-440e3f490289.pid
teto commented 6 years ago

I hacked all around and I think I've reached a reproducible success on nixos (which was a painful path, I believe i've discovered quite a few bugs in the packages).

Now I am connected successfully, password is accepted but I can't access any website. I have 2 DNS servers correctly configured according to journalctl but when I try to use firefox, I get https://transfer.sh/GuDxx/2017-10-16-183340_956x967_scrot.png

I noticed in journalctl the error /56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/triplets.dat failed: No such file or directory. Could it be the reason ? or because of the old ciphers ?


oct. 16 18:31:43 jedha charon[2776]: 00[CFG] joining forecast multicast groups: 224.0.0.1,224.0.0.22,224.0.0.251,224.0.0.252,239.255.255.250
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading ca certificates from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/cacerts'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading aa certificates from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/aacerts'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading ocsp signer certificates from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/ocspcerts'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading attribute certificates from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/acerts'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading crls from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/crls'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading secrets from '/nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.secrets'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-74615f38-bdb3-424b-898c-440e3f490289.secrets'
oct. 16 18:31:43 jedha charon[2776]: 00[CFG]   loaded IKE secret for %any
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] opening triplet file /nix/store/56ywhi751kvczjl6nvk32nasbdh1685c-strongswan-5.6.0/etc/ipsec.d/triplets.dat failed: No such file or directory
oct. 16 18:31:43 jedha charon[2776]: 00[CFG] no script for ext-auth script defined, disabled
dkosovic commented 6 years ago

Firefox issue seems like a SSL certificate issue, possibly due to the https proxy replacing the certificate or you have an old CA certificate package installed. If you click on the 'i' icon before the URL, does the SSL certificate look right? It should have support.mozilla.org in the certificate hierarchy

You could try using wget or wget --no-check-certificate with the same URL as Firefox and see if wget can download the page.

Are you able to access http websites that don't redirect to https URLs?

teto commented 6 years ago

NixOS doesn't give to applications access to the cacert store (by default). I remember having a similar problem when trying to use wget. It could not validate the file.

wget --no-check-certificate www.google.com                                                                                ~
--2017-10-16 20:51:37--  http://www.google.com/
Résolution de www.google.com (www.google.com)… 216.58.197.164, 2404:6800:4004:801::2004
Connexion à www.google.com (www.google.com)|216.58.197.164|:80… connecté.
requête HTTP transmise, en attente de la réponse… 403 Access Denied
2017-10-16 20:51:37 erreur 403 : Access Denied.

I can't get access to any website.

I believe that strongswan is in charge of validating the packets ? Its cacert folder is empty so that might be it ? on your typical distribution do these folders /etc/ipsec.d/*cert have files ?

ls -R etc                                                                                                                                                                                                /nix/store/3pdjx61160sgf655jxjg5cpx3cz7f37h-strongswan-5.6.0
etc:
ipsec.conf  ipsec.d  ipsec.secrets  strongswan.conf  strongswan.d  swanctl  systemd

etc/ipsec.d:
aacerts  acerts  cacerts  certs  crls  ocspcerts  private  reqs

etc/ipsec.d/aacerts:

etc/ipsec.d/acerts:

etc/ipsec.d/cacerts:

etc/ipsec.d/certs:

etc/ipsec.d/crls:

etc/ipsec.d/ocspcerts:

etc/ipsec.d/private:

etc/ipsec.d/reqs:

etc/strongswan.d:
charon  charon.conf  charon-logging.conf  charon-systemd.conf  pki.conf  scepclient.conf  starter.conf  swanctl.conf

etc/strongswan.d/charon:
acert.conf   attr.conf      constraints.conf  dnscert.conf        eap-gtc.conf       eap-simaka-pseudonym.conf  eap-sim-pcsc.conf  forecast.conf        md5.conf    pkcs11.conf  pkcs8.conf   rdrand.conf      sha2.conf            unbound.conf  xauth-eap.conf
aes.conf     chapoly.conf   curve25519.conf   dnskey.conf         eap-identity.conf  eap-simaka-reauth.conf     ext-auth.conf      gmp.conf             nonce.conf  pkcs12.conf  pubkey.conf  resolve.conf     socket-default.conf  updown.conf   xauth-generic.conf
aesni.conf   cmac.conf      des.conf          eap-aka-3gpp2.conf  eap-md5.conf       eap-sim.conf               farp.conf          hmac.conf            pem.conf    pkcs1.conf   random.conf  revocation.conf  sshkey.conf          vici.conf     xauth-pam.conf
af-alg.conf  connmark.conf  dhcp.conf         eap-aka.conf        eap-mschapv2.conf  eap-sim-file.conf          fips-prf.conf      kernel-netlink.conf  pgp.conf    pkcs7.conf   rc2.conf     sha1.conf        stroke.conf          x509.conf     xcbc.conf

etc/swanctl:
bliss  conf.d  ecdsa  pkcs12  pkcs8  private  pubkey  rsa  swanctl.conf  x509  x509aa  x509ac  x509ca  x509crl  x509ocsp

etc/swanctl/bliss:

etc/swanctl/conf.d:

etc/swanctl/ecdsa:

etc/swanctl/pkcs12:

etc/swanctl/pkcs8:

etc/swanctl/private:

etc/swanctl/pubkey:

etc/swanctl/rsa:

etc/swanctl/x509:

etc/swanctl/x509aa:

etc/swanctl/x509ac:

etc/swanctl/x509ca:

etc/swanctl/x509crl:

etc/swanctl/x509ocsp:

etc/systemd:
system

etc/systemd/system:
strongswan.service  strongswan-swanctl.service
dkosovic commented 6 years ago

Here is what Ubuntu has in /etc/ipsec.d/ and /etc/strongswan.d

$ ls -R /etc/ipsec.d/
/etc/ipsec.d/:
aacerts  acerts  cacerts  certs  crls  ocspcerts  policies  private  reqs

/etc/ipsec.d/aacerts:

/etc/ipsec.d/acerts:

/etc/ipsec.d/cacerts:

/etc/ipsec.d/certs:

/etc/ipsec.d/crls:

/etc/ipsec.d/ocspcerts:

/etc/ipsec.d/policies:

/etc/ipsec.d/private:

/etc/ipsec.d/reqs:
$ ls -R /etc/strongswan.*
/etc/strongswan.conf

/etc/strongswan.d:
charon       charon-logging.conf  pool.conf        starter.conf
charon.conf  pki.conf             scepclient.conf

/etc/strongswan.d/charon:
aes.conf          hmac.conf            pkcs1.conf       sha2.conf
agent.conf        kernel-netlink.conf  pkcs7.conf       socket-default.conf
attr.conf         md4.conf             pkcs8.conf       sshkey.conf
connmark.conf     md5.conf             pubkey.conf      stroke.conf
constraints.conf  nonce.conf           random.conf      test-vectors.conf
dnskey.conf       openssl.conf         rc2.conf         updown.conf
fips-prf.conf     pem.conf             resolve.conf     x509.conf
gcm.conf          pgp.conf             revocation.conf  xcbc.conf
gmp.conf          pkcs12.conf          sha1.conf
dkosovic commented 6 years ago

Looks like your workplace might be providing a transparent http/https proxy. As it is returning a HTTP Error 403 (i.e. access denied), perhaps you first need to authenticate with the proxy to allow access to external websites? A connection is definitely being established, it's just that it is not getting past the proxy.

Are you able to SSH to anywhere after establishing a VPN connection?

dkosovic commented 6 years ago

You could also try curl -v http://www.google.com as it provides a bit more diagnostics than wget.

The HTTP status codes are listed on the following page, including the 4xx HTTP error codes :

In particular :

403 Forbidden The request was valid, but the server is refusing action. The user might not have the necessary permissions for a resource, or may need an account of some sort.

stongswan doesn't provide error codes for the HTTP protocol.

dkosovic commented 6 years ago

The default setting for the VPN connection is that all traffic goes over the VPN connection. You could setup a split tunneling VPN, so only traffic to your workplace goes over the VPN connection. This would solve the issue with the proxy.

For split tunneling VPN, it might be as simple as clicking on the "Use this connection for resources on its network" in the Routes section of the IPv4 settings. For some sites, you might need to manually add additional routing info.

teto commented 6 years ago

I had been looking for sthg like that but misunderstood the "Use this connection for resources on its network" and ended up changing the routing tables myself. That checkbox is great even though that doesn't solve the problem, makes testing more bearable :) Thanks for the ls output; seems pretty similar.

I can ping the other peer of the ppp but no host behind it it seems. xl2tp is 1.3.10 so the filename length shouldn't be a problem. I've asked colleagues and apparently there is no firewall and one optional proxy. I've disabled proxy use wherever I could so I don't think that's the problem. My guess is that the encryption is checked by a program on my stack - dunno if it's strongswan/xl2tp - that doesn't have access to the system store because of nixos specificities. What would you say that component is (if any) ? Right now I believe my best bet is to run xl2tdp directly as you advised and see what debug output I can get.

dkosovic commented 6 years ago

Could you try the Network Monitor in Firefox, see: https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor

You can enable the 'Remote IP' column (e.g. right mouse button on 'Domain' column name, then enable 'Remote IP'). Be interested to know if the IP address of the server returning the Error 403 is correct.

teto commented 6 years ago

After poking around, it seems I was assigned the wrong type of VPN (not easy to get as I am in a country I don't speak/read the language) basically I am just allowed to retrieve mails (not send it!). Hopefully they change that and I can indeed confirm that this is the blocking point (I sure hope so).

dkosovic commented 6 years ago

Forgot to mention last week, one thing you could use to test the NixOS L2TP/IPsec related packages is to try a free L2TP/IPsec server that is known to work and it will rule out issues that are related to your workplace VPN. Occasionally I use vpn302920012.opengw.net which is listed on the following page :

See the "L2TP/IPsec Connect guide" in the table on that page for the username, password and shared key.

teto commented 6 years ago

I received my new VPN credentials with extended access and it now fully works \o/ Thank you so very much for the invaluable help !
I am now looking into having an upstreamable nixos solution so I might send a patch one a design has been agreed to. Conversation on https://github.com/NixOS/nixpkgs/issues/30147. I wonder if swanctl can be used to load the ipsec.d/secrets instead of having l2tp to write into ipsec.secrets ?

dkosovic commented 6 years ago

Glad to hear it now works for you.

The swanctl documentation says swanctl --load* commands read secrets from /etc/swanctl/swanctl.conf, I don't know if you could use a different swanctl.conf file?

dkosovic commented 6 years ago

I could add a --with-nm-ipsec-secrets-dir=path configure switch like with network-manager-libreswan :

Extract :

AC_ARG_WITH(nm-ipsec-secrets-dir, AS_HELP_STRING([--with-nm-ipsec-secrets-dir=path], [The directory where to put IPSec secrets, defaults to /etc/ipsec.d/]), [], [with_nm_ipsec_secrets_dir=])
AS_IF([test -z "$with_nm_ipsec_secrets_dir"], with_nm_ipsec_secrets_dir="/etc/ipsec.d")
if (printf '%s' "$with_nm_ipsec_secrets_dir" | grep -v -q '^/'); then
    AC_MSG_ERROR([--with-nm-ipsec-secrets-dir must be an absolute path, instead it is '$with_nm_ipsec_secrets_dir'])
fi
AC_DEFINE_UNQUOTED(NM_IPSEC_SECRETS_DIR, "$with_nm_ipsec_secrets_dir", [IPSec secret dir])

Would probably also need to add a --with-nm-ipsec-secrets=path for /etc/ipsec.secrets

The two values are currently hard coded in src/nm-l2tp-service.c :

    secrets = "/etc/ipsec.secrets";
    ipsec_d = "/etc/ipsec.d";
teto commented 6 years ago

there is not much feedback on the nixos side. I will send a PR to wake people up. As long as I don't have better feedback, it's hard to give any advice. My feeling is that it's odd for l2tp to inject itself in /etc/ipsec.secrets. Though I understand it's practical I believe this is best left to package managers.

Having sthg akin to could indeed be helpful: secrets = SYSCONFDIR"/etc/ipsec.secrets";

I believe my best bet for now is to change https://nixos.org/nixos/options.html#networkmanager (networking.networkmanager.packages) so that the presence of l2tp adds "secrets" path to services.strongswan.secrets (https://nixos.org/nixos/options.html#strongswan)

services.strongswan did not work for me but there has been some fixes recently on it so that's worth a try.

dkosovic commented 6 years ago

In earlier versions of nm-l2tp it would temporarily rename /etc/ipsec.secrets, create a new /etc/ipsec.secrets and then soon after restore the original file. Unfortunately restoring the original ipsec.secrets file breaks rekeying which can happen after a number of hours of the connection being up.

nm-l2tp doesn't inject into /etc/ipsec.secrets for Libreswan, just for strongSwan, as Libreswan already has the include line in the upstream source. It's unfortunate, but didn't have much choice as many Linux distributions don't package Libreswan. Contacting strongSwan upstream would be better than contacting the package managers as there are too many Linux distributions, unfortunately it could be years before all the major Linux distributions ship a version of strongSwan that includes the fix.

dkosovic commented 6 years ago

I went off in a bit of a tangent in regards to injecting the include line, but I understand where you are coming from when you mentioned package managers in regards to NixOS.

teto commented 6 years ago

Apparently the nix store should be immutable so secrets can live in /etc. In the end I might be able to support l2tp without patching it so that's good news. The bad news is that I now have this original error. failed to connect: 'property 'ipsec-ike' invalid or not supported' and I don't know what triggered it (I rebased my branch so it might be because of some external changes, but I also made some changes to support l2tp+ipsec in nixos, mostly setting up paths in /etc). The l2tp config didn't change though. The key is present in: /etc/NetworkManager/system-connections/MyCompan-L2TP ipsec-ike=aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024

dkosovic commented 6 years ago

The ipsec-ike property was first added in network-manager-l2tp version 1.2.6, I think the one that ships with NixOS is 1.2.4, so wonder if it somehow got reverted to 1.2.4?

ipsec-ike (i.e phase 1) and ipsec-esp (i.e. phase 2) are defined in shared/nm-service-defines.h :

#define NM_L2TP_KEY_IPSEC_IKE         "ipsec-ike"
#define NM_L2TP_KEY_IPSEC_ESP         "ipsec-esp"
teto commented 6 years ago

I have 1.2.8 in my local branch. It seems to be launched because I can define the phases via nm-applet, which I can't with 1.2.4. I will try a reboot.

teto commented 6 years ago

That was it. Sometimes networkmanager is not properly restarted, I believe it happens when I have the libvirtd daemon :/ Anyway I now have what I believe a nixos upstreamable solution. I'll let you know whn it gets merged. Thnaks again for the awesome support. I wish we could star maintainers too ;)

dkosovic commented 6 years ago

Glad to hear you got it going.

One request, if it's not too much effort, could the homepage in l2tp.nix be changed to this GitHub repository as it's currently pointing to the previous maintainer's old GitHub repository :

teto commented 6 years ago

sure

dkosovic commented 6 years ago

With commit #https://github.com/nm-l2tp/network-manager-l2tp/commit/0d563082a8ac64b21e7c4384356b35ac65841b3a the following configure arguments were added :

The reason SYSCONFDIR wasn't used is because some people build and install strongswan from source code and use the default --prefix=/usr/local configure switch to install to /usr/local/.

teto commented 6 years ago

I tried rebasing my PR and it broke it. I will try to fix it when I get some time, probably when this gets passed https://github.com/NixOS/nixpkgs/pull/27958 The url has been fixed on your recommandation by someone else. https://github.com/NixOS/nixpkgs/pull/31506/files

Anyway I'll keep u posted.

teto commented 6 years ago

After a rebase, it worked again so I made a PR and after a few months I wanted to tell people "merge my PR" but when I tried it failed again

Any idea where udp_xmit failed to could stem from ?

févr. 19 20:57:49 jedha NetworkManager[27274]: generating ID_PROT request 0 [ ID HASH ]
févr. 19 20:57:49 jedha NetworkManager[27274]: sending packet: from 192.168.0.129[4500] to SERVER_IP[4500] (68 bytes)
févr. 19 20:57:49 jedha NetworkManager[27274]: received packet: from SERVER_IP[4500] to 192.168.0.129[4500] (68 bytes)
févr. 19 20:57:49 jedha NetworkManager[27274]: parsed ID_PROT response 0 [ ID HASH ]
févr. 19 20:57:49 jedha NetworkManager[27274]: IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] established between 192.168.0.129[192.168.0.129]...SERVER_IP[SERVER_IP]
févr. 19 20:57:49 jedha NetworkManager[27274]: scheduling reauthentication in 9953s
févr. 19 20:57:49 jedha NetworkManager[27274]: maximum IKE_SA lifetime 10493s
févr. 19 20:57:49 jedha NetworkManager[27274]: generating QUICK_MODE request 3371751540 [ HASH SA No ID ID NAT-OA NAT-OA ]
févr. 19 20:57:49 jedha NetworkManager[27274]: sending packet: from 192.168.0.129[4500] to SERVER_IP[4500] (244 bytes)
févr. 19 20:57:49 jedha NetworkManager[27274]: received packet: from SERVER_IP[4500] to 192.168.0.129[4500] (156 bytes)
févr. 19 20:57:49 jedha NetworkManager[27274]: parsed QUICK_MODE response 3371751540 [ HASH SA No ID ID ]
févr. 19 20:57:49 jedha NetworkManager[27274]: CHILD_SA 74615f38-bdb3-424b-898c-440e3f490289{1} established with SPIs c2595470_i 0e78ecaa_o and TS 192.168.0.129/32[udp/l2f] === SERVER_IP/32[udp/l2f]
févr. 19 20:57:49 jedha NetworkManager[27274]: generating QUICK_MODE request 3371751540 [ HASH ]
févr. 19 20:57:49 jedha NetworkManager[27274]: connection '74615f38-bdb3-424b-898c-440e3f490289' established successfully
févr. 19 20:57:49 jedha nm-l2tp-service[27542]: xl2tpd started with pid 27606
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: setsockopt recvref[30]: Protocol not available
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Using l2tp kernel support.
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: xl2tpd version xl2tpd-1.3.10 started on jedha PID:27606
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Forked by Scott Balmos and David Stipp, (C) 2001
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Inherited by Jeff McAdams, (C) 2002
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Forked again by Xelerance (www.xelerance.com) (C) 2006-2016
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Listening on IP address 0.0.0.0, port 1701
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Connecting to host SERVER_IP, port 1701
févr. 19 20:57:49 jedha NetworkManager[27274]: <info>  [1519041469.4624] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN plugin: state changed: starting (3)
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Connection established to SERVER_IP, 1701.  Local: 64326, Remote: 26619 (ref=0/0).
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: Calling on tunnel 64326
févr. 19 20:57:49 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:57:50 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:57:52 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:57:56 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:58:01 jedha charon[27573]: 11[NET] received packet: from SERVER_IP[4500] to 192.168.0.129[4500] (76 bytes)
févr. 19 20:58:01 jedha charon[27573]: 11[ENC] parsed INFORMATIONAL_V1 request 673049089 [ HASH D ]
févr. 19 20:58:01 jedha charon[27573]: 11[IKE] received DELETE for ESP CHILD_SA with SPI 0e78ecaa
févr. 19 20:58:01 jedha charon[27573]: 11[IKE] closing CHILD_SA 74615f38-bdb3-424b-898c-440e3f490289{1} with SPIs c2595470_i (105 bytes) 0e78ecaa_o (110 bytes) and TS 192.168.0.129/32[udp/l2f] === SERVER_IP/32[udp/l2f]
févr. 19 20:58:01 jedha charon[27573]: 11[IKE] closing CHILD_SA 74615f38-bdb3-424b-898c-440e3f490289{1} with SPIs c2595470_i (105 bytes) 0e78ecaa_o (110 bytes) and TS 192.168.0.129/32[udp/l2f] === SERVER_IP/32[udp/l2f]
févr. 19 20:58:01 jedha NetworkManager[27274]: <debug> [1519041481.5359] agent-manager: req[0x1dfa8c0, :1.22/org.freedesktop.nm-applet/1000]: agent failed save secrets request [0x7fdcb4002510/"IIJ-L2TP"sav]: Le délai d’attente est dépassé
févr. 19 20:58:03 jedha NetworkManager[27274]: xl2tpd[27606]: death_handler: Fatal signal 15 received
févr. 19 20:58:03 jedha NetworkManager[27274]: xl2tpd[27606]: udp_xmit failed to SERVER_IP:1701 with err=-1:No such device
févr. 19 20:58:03 jedha NetworkManager[27274]: xl2tpd[27606]: Connection 26619 closed to SERVER_IP, port 1701 (Server closing)
févr. 19 20:58:03 jedha NetworkManager[27274]: <warn>  [1519041483.4713] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN plugin: failed: connect-failed (1)
févr. 19 20:58:03 jedha NetworkManager[27274]: <warn>  [1519041483.4714] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN plugin: failed: connect-failed (1)
févr. 19 20:58:03 jedha NetworkManager[27274]: <info>  [1519041483.4714] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN plugin: state changed: stopping (5)
févr. 19 20:58:03 jedha NetworkManager[27274]: Stopping strongSwan IPsec...
févr. 19 20:58:03 jedha charon[27573]: 00[DMN] signal of type SIGINT received. Shutting down
févr. 19 20:58:03 jedha charon[27573]: 00[IKE] deleting IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] between 192.168.0.129[192.168.0.129]...SERVER_IP[SERVER_IP]
févr. 19 20:58:03 jedha charon[27573]: 00[IKE] deleting IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1] between 192.168.0.129[192.168.0.129]...SERVER_IP[SERVER_IP]
févr. 19 20:58:03 jedha charon[27573]: 00[IKE] sending DELETE for IKE_SA 74615f38-bdb3-424b-898c-440e3f490289[1]
févr. 19 20:58:03 jedha charon[27573]: 00[ENC] generating INFORMATIONAL_V1 request 108706194 [ HASH D ]
févr. 19 20:58:03 jedha charon[27573]: 00[NET] sending packet: from 192.168.0.129[4500] to SERVER_IP[4500] (84 bytes)
févr. 19 20:58:03 jedha ipsec_starter[27572]: child 27573 (charon) has quit (exit code 0)
févr. 19 20:58:03 jedha ipsec_starter[27572]: 
févr. 19 20:58:03 jedha ipsec_starter[27572]: charon stopped after 200 ms
févr. 19 20:58:03 jedha ipsec_starter[27572]: ipsec starter stopped
févr. 19 20:58:03 jedha nm-l2tp-service[27542]: ipsec shut down
févr. 19 20:58:03 jedha NetworkManager[27274]: <info>  [1519041483.5972] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN plugin: state changed: stopped (6)
févr. 19 20:58:03 jedha NetworkManager[27274]: <debug> [1519041483.5989] active-connection[0x1e64440]: set state deactivated (was activating)
févr. 19 20:58:03 jedha NetworkManager[27274]: <debug> [1519041483.5990] active-connection[0x1e64440]: check-master-ready: not signalling (state deactivated, no master)
févr. 19 20:58:03 jedha NetworkManager[27274]: <debug> [1519041483.5991] device[0x1d9c640] (eno1): remove_pending_action (0): 'activation-0x1e64440'
févr. 19 20:58:03 jedha NetworkManager[27274]: <info>  [1519041483.6005] vpn-connection[0x1e64440,74615f38-bdb3-424b-898c-440e3f490289,"IIJ-L2TP",0]: VPN service disappeared

Also I wondered when /etc/ipsec.d/XXX.secret is created. Sometimes it's there sometimes it isn't (aka /etc/ipsec.d/ is empty, maybe it's removed after the connection tentative).

dkosovic commented 6 years ago

I went from kernel-4.15.4 and back to 4.13.9 and things started to work again.

dkosovic commented 6 years ago

For the udp_xmit failed with err=-1:No such device error, see issue https://github.com/nm-l2tp/network-manager-l2tp/issues/79

dkosovic commented 6 years ago

The following xl2tpd patch fixes the udp_xmit ... No such device issue with kernels 4.15 and 4.16 :

teto commented 6 years ago

thanks for the updates/help/successful support. Package got merged so closing this.