nm-l2tp / NetworkManager-l2tp

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

strongswan charon: 04[IKE] received DELETE for IKE_SA #36

Closed dePhantum closed 7 years ago

dePhantum commented 7 years ago

Greetings,

I have followed the instructions found in the wiki of this project, installed to the letter. Although there is no suggestion as to how the conf files should be defined, I am assuming the defaults take precedence.

After the install, I get the generic message popup from Network Manager:

"The VPN Connection 'MyConnection L2TP' failed because the VPN service failed to start"

Went to syslogs and see the following:

nm-l2tp-service[7864]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed

In the context of the following messages:

Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: generating QUICK_MODE request 3996919311 [ HASH ]
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: connection 'nm-ipsec-l2tp-7864' established successfully
Jan 14 19:29:33 dephantum-dbox charon: 15[NET] sending packet: from [my.ip.add.ress][4500] to [vpn.ip.add.ress][4500] (60 bytes)
Jan 14 19:29:33 dephantum-dbox charon: 04[NET] received packet: from [vpn.ip.add.ress][4500] to [my.ip.add.ress][4500] (84 bytes)
Jan 14 19:29:33 dephantum-dbox charon: 04[ENC] parsed INFORMATIONAL_V1 request 2914406121 [ HASH D ]
Jan 14 19:29:33 dephantum-dbox charon: 04[IKE] received DELETE for IKE_SA nm-ipsec-l2tp-7864[1]
Jan 14 19:29:33 dephantum-dbox charon: 04[IKE] deleting IKE_SA nm-ipsec-l2tp-7864[1] between [my.ip.add.ress][[my.ip.add.ress]]...[vpn.ip.add.ress][[vpn.ip.add.ress]]
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: nm-l2tp[7864] <warn>  Could not establish IPsec tunnel.
Jan 14 19:29:33 dephantum-dbox charon: 08[CFG] rereading secrets
Jan 14 19:29:33 dephantum-dbox charon: 08[CFG] loading secrets from '/etc/ipsec.secrets'
Jan 14 19:29:33 dephantum-dbox charon: 08[CFG]   loaded IKE secret for [vpn.ip.add.ress]
Jan 14 19:29:33 dephantum-dbox nm-l2tp-service[7864]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: <info>  [1484443773.9455] vpn-connection[0x5561eb4fe7b0,b96770f8-b9eb-4ee1-9810-46cee7bbdb1d,"MyConnection L2TP",0]: VPN plugin: state changed: stopped (6)
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: <info>  [1484443773.9467] vpn-connection[0x5561eb4fe7b0,b96770f8-b9eb-4ee1-9810-46cee7bbdb1d,"MyConnection L2TP",0]: VPN plugin: state change reason: unknown (0)
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: <info>  [1484443773.9475] vpn-connection[0x5561eb4fe7b0,b96770f8-b9eb-4ee1-9810-46cee7bbdb1d,"MyConnection L2TP",0]: VPN service disappeared
Jan 14 19:29:33 dephantum-dbox dbus-daemon[2200]: Activating service name='org.freedesktop.Notifications'
Jan 14 19:29:33 dephantum-dbox NetworkManager[1015]: <warn>  [1484443773.9481] vpn-connection[0x5561eb4fe7b0,b96770f8-b9eb-4ee1-9810-46cee7bbdb1d,"MyConnection L2TP",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'
Jan 14 19:29:33 dephantum-dbox dbus-daemon[2200]: Successfully activated service 'org.freedesktop.Notifications'

It appears to be something invalid with ipsec.secrets, I have only one line there:

vpn.ip.add.ress : PSK "top-secret"

where vpn.ip.add.ress is the IP address of the VPN server.

There obviously is an assertion thrown in handling the secrets and I would think this is a bug. Any suggestions, or guidance on this matter? Much Appreciated.

dkosovic commented 7 years ago

The only conf files are the ones that are generated each time it is run and can be found under /var/run/ with the exception of /etc/ipsec.secrets which is temporarily replaced and re-read.

Are you able to see the logs on the VPN server? For some reason the VPN server is sending a DELETE payload as indicated by the following line :

 Jan 14 19:29:33 dephantum-dbox charon: 04[IKE] received DELETE for IKE_SA nm-ipsec-l2tp-7864[1]

which then brings the IPsec connection down.

dkosovic commented 7 years ago

I'm not sure which version of strongSwan you are using and on what Linux distribution. But a possible workaround is to remove the system strongSwan and build a local copy of Libreswan or different version of strongSwan.

At runtime, this VPN plugin will look for Libreswan and strongSwan in the following locations (so is fine to install Libreswan or strongSwan to /usr/local/ ) :

dkosovic commented 7 years ago

You might like to do a git pull which fixes a strongSwan issue with the temporarily generated ipsec.secrets that some people encountered. But suspect it wont help in your case.

The g_dbus_method_invocation_take_error() assertion issue is something to do with Gnome libsecret and nothing to do with ipsec.secrets. It also is no longer in this plugin's code, but common NetworkManager VPN code in a library.

dePhantum commented 7 years ago

Hi Doug,

Here is some additional info I should have given up front, my apologies:

~$ lsb_release -rd
Description:    Ubuntu 16.10
Release:    16.10 

Output from the temp conf file in /var/run/:

cat: /var/run/nm-ipsec-l2tp.3314: Is a directory
ipparam nm-l2tp-service-3314
nodetach
usepeerdns
noipdefault
nodefaultroute
noauth
noccp
lcp-echo-failure 0
lcp-echo-interval 0
plugin /usr/lib/pppd/2.4.7/nm-l2tp-pppd-plugin.so
mru 1400
mtu 1400
[global]
access control = yes
port = 1701
[lac l2tp]
lns = [VPN SERVER IP]
pppoptfile = /var/run/nm-ppp-options.xl2tpd.3314
autodial = yes
tunnel rws = 8
tx bps = 100000000
rx bps = 100000000 

I have asked the Admin for info from the VPN Server logs, but to no avail, thus far. I found it strange that it sends a delete, I thought it was in response to an invalid secret. Even though I have the proper secret entered.

My secret file is as such:

# This file holds shared secrets or RSA private keys for authentication.

# RSA private key for this host, authenticating it to any other host
# which knows the public part.
[VPN SERVER IP] : PSK "super-secret" 

I have tried with both putting enteries and removing them for the Group ID in network manager also.

I am confused by your comment 'nothing to do with ipsec.secrets', at least from my first glance of the source it is reading the secrets, calling the lib function and then failing at the point:

password = nm_setting_vpn_get_secret (s_vpn, NM_L2TP_KEY_PASSWORD);
        if (!password || !strlen (password)) {
                g_dbus_method_invocation_return_error_literal (invocation,
                                                               NM_VPN_PLUGIN_ERROR,
                                                               NM_VPN_PLUGIN_ERROR_INVALID_CONNECTION,
                                                               _("Missing or invalid VPN password."));
                return FALSE;;
        }

So then, even though it is a library call, it is in the source, and to be contended with. If the secrets is invalid, this info somehow should get back to the user, I think sending it back to network manager in this way leads to the misleading "can't start server" which is false, since the server did start and negotiations did proceed and something went bad, and the server said, delete and bye forever :)

Yes, also I am using strongswan, as you wiki page states to do.

I am also a C/C++ programmer, and would be glad to help with the project, to get this issue remedied, I know a lot of non-techinical people are very frustrated, that want plug and play with VPN.

dkosovic commented 7 years ago

That snippet of code you pasted from the handle_need_secrets() function of src/nm-l2tp-service.c is dealing with Gnome Libsecret and to do with the username/password secret for L2TP and not the PSK of IPsec.

When I previously did a grep for g_dbus_method_invocation_take_error I couldn't find it anywhere in the master branch of the source code, but could only find it in an older version that had it in the handle_need_secrets() function.

I was probably wrong about assertion issue now happening somewhere in a common NetworkManager VPN library.

I think that g_dbus_method_invocation_take_error assertion is a side effect of the IPsec connection failing earlier.

As of commit https://github.com/nm-l2tp/network-manager-l2tp/commit/d8716a9356dc0fb947c2b1dde249186259debbc5, there is nothing now before the colon in the temporarily generated /etc/ipsec.secrets so it just looks something like:

: PSK my-pre-shared-key

In your logs, strongswan's /usr/sbin/ipsec up claims the connection is "established successfully" and a fraction of a second later it receives a DELETE payload. I never trust the exit status of /usr/sbin/ipsec and explicitly test the connection is indeed up with the following code :

which outputs "Could not establish IPsec tunnel." when the IPsec connection is down and that is what you are seeing in the logs.

You could try changing the --debug for strongswan on the following line to --moredebug:

which might give a hint as to what is going wrong.

When I did a Google search for "received DELETE for IKE_SA" some people recommended updating the version of strongSwan. But I suspect you won't have the issue with Libreswan. I should probably include instructions for building Libreswan in the wiki, but it'll just be something like the following after cd'ing to the top level folder of the libreswan source :

sudo apt remove strongswan
./configure
make install

I only recommend strongswan for Ubuntu in the wiki as Ubuntu/Debian don't offer Libreswan packages, unlike Fedora which provides both.

I'm more than happy to accept any code contributions.

dePhantum commented 7 years ago

I tried to install both libreswan 3.18 and 3.19 both were a bust for me and failed on the compilation/link, I am using 16.10 bleeding edge. I am re-isntalling the strongswan again.

dePhantum commented 7 years ago

Ok... rebuilt strongswan and network-manager-l2tp source. Turned on debug and here is the output

me@dephantum-dbox:~/network-manager-l2tp$ sudo /usr/lib/NetworkManager/nm-l2tp-service --debug
nm-l2tp[23392] <debug> nm-l2tp-service (version 1.2.4) starting...
nm-l2tp[23392] <debug>  uses default --bus-name "org.freedesktop.NetworkManager.l2tp"
nm-l2tp[23392] <info>  ipsec enable flag: yes
** Message: Check port 1701
connection
    id : "[MYCONNECTIONNAME]" (s)
    uuid : "b96770f8-b9eb-4ee1-9810-46cee7bbdb1d" (s)
    interface-name : NULL (sd)
    type : "vpn" (s)
    permissions : [] (s)
    autoconnect : FALSE (s)
    autoconnect-priority : 0 (sd)
    timestamp : 0 (sd)
    read-only : FALSE (sd)
    zone : NULL (sd)
    master : NULL (sd)
    slave-type : NULL (sd)
    autoconnect-slaves : ((NMSettingConnectionAutoconnectSlaves) NM_SETTING_CONNECTION_AUTOCONNECT_SLAVES_DEFAULT) (sd)
    secondaries : [] (s)
    gateway-ping-timeout : 0 (sd)
    metered : ((NMMetered) NM_METERED_UNKNOWN) (sd)
    lldp : -1 (sd)

ipv6
    method : "auto" (s)
    dns : [] (s)
    dns-search : [] (s)
    dns-options : NULL (sd)
    dns-priority : 0 (sd)
    addresses : ((GPtrArray*) 0x55e7c3616000) (s)
    gateway : NULL (sd)
    routes : ((GPtrArray*) 0x55e7c3616020) (s)
    route-metric : -1 (sd)
    ignore-auto-routes : FALSE (sd)
    ignore-auto-dns : FALSE (sd)
    dhcp-hostname : NULL (sd)
    dhcp-send-hostname : TRUE (sd)
    never-default : FALSE (sd)
    may-fail : TRUE (sd)
    dad-timeout : -1 (sd)
    dhcp-timeout : 0 (sd)
    ip6-privacy : ((NMSettingIP6ConfigPrivacy) NM_SETTING_IP6_CONFIG_PRIVACY_DISABLED) (s)
    addr-gen-mode : 1 (sd)

ipv4
    method : "auto" (s)
    dns : ["[My.DNS.IP]"] (s)
    dns-search : ["my.gateway.com"] (s)
    dns-options : NULL (sd)
    dns-priority : 0 (sd)
    addresses : ((GPtrArray*) 0x55e7c36160a0) (s)
    gateway : NULL (sd)
    routes : ((GPtrArray*) 0x55e7c36160c0) (s)
    route-metric : -1 (sd)
    ignore-auto-routes : FALSE (sd)
    ignore-auto-dns : FALSE (sd)
    dhcp-hostname : NULL (sd)
    dhcp-send-hostname : TRUE (sd)
    never-default : FALSE (sd)
    may-fail : TRUE (sd)
    dad-timeout : -1 (sd)
    dhcp-timeout : 0 (sd)
    dhcp-client-id : NULL (sd)
    dhcp-fqdn : NULL (sd)

vpn
    service-type : "org.freedesktop.NetworkManager.l2tp" (s)
    user-name : "<myusername>" (s)
    persistent : FALSE (sd)
    data : ((GHashTable*) 0x55e7c35fa760) (s)
    secrets : ((GHashTable*) 0x55e7c35fa760) (s)
    timeout : 0 (sd)

nm-l2tp[23392] <info>  starting ipsec
Stopping strongSwan IPsec failed: starter is not running
Starting strongSwan 5.3.5 IPsec [starter]...
Loading config setup
Loading conn 'nm-ipsec-l2tp-23392'
found netkey IPsec stack
initiating Main Mode IKE_SA nm-ipsec-l2tp-23392[1] to [VPN.SERVER.IP]
generating ID_PROT request 0 [ SA V V V V ]
sending packet: from my.ip.add.ress[500] to [VPN.SERVER.IP][500] (280 bytes)
received packet: from [VPN.SERVER.IP][500] to my.ip.add.ress[500] (112 bytes)
parsed ID_PROT response 0 [ SA V V ]
received unknown vendor ID: 5b:36:2b:c8:20:f6:00:07
received NAT-T (RFC 3947) vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from my.ip.add.ress[500] to [VPN.SERVER.IP][500] (244 bytes)
received packet: from [VPN.SERVER.IP][500] to my.ip.add.ress[500] (276 bytes)
parsed ID_PROT response 0 [ KE NAT-D NAT-D No V V V ]
received unknown vendor ID: 40:4b:f4:39:52:2c:a3:f6
received XAuth vendor ID
received DPD vendor ID
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from my.ip.add.ress[4500] to [VPN.SERVER.IP][4500] (108 bytes)
received packet: from [VPN.SERVER.IP][4500] to my.ip.add.ress[4500] (76 bytes)
queueing TRANSACTION request as tasks still active
sending retransmit 1 of request message ID 0, seq 3
sending packet: from my.ip.add.ress[4500] to [VPN.SERVER.IP][4500] (108 bytes)
received packet: from [VPN.SERVER.IP][4500] to my.ip.add.ress[4500] (64 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA nm-ipsec-l2tp-23392[1] established between my.ip.add.ress[<my.login.to.vpn>]...[VPN.SERVER.IP][[VPN.SERVER.IP]]
scheduling reauthentication in 9924s
maximum IKE_SA lifetime 10464s
parsed TRANSACTION request 3758263982 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
generating TRANSACTION response 3758263982 [ HASH CP ]
sending packet: from my.ip.add.ress[4500] to [VPN.SERVER.IP][4500] (68 bytes)
generating QUICK_MODE request 3193119671 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from my.ip.add.ress[4500] to [VPN.SERVER.IP][4500] (244 bytes)
received packet: from [VPN.SERVER.IP][4500] to my.ip.add.ress[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 3248831319 [ HASH D ]
received DELETE for IKE_SA nm-ipsec-l2tp-23392[1]
deleting IKE_SA nm-ipsec-l2tp-23392[1] between my.ip.add.ress[<my.login.to.vpn>]...[VPN.SERVER.IP][[VPN.SERVER.IP]]
establishing connection 'nm-ipsec-l2tp-23392' failed
nm-l2tp[23392] <warn>  Could not establish IPsec tunnel.

(nm-l2tp-service:23392): GLib-GIO-CRITICAL **: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
dkosovic commented 7 years ago

I'll look into building Libreswan on Ubuntu when I get home from work.

I can't see anything with the increased strongswan verbosity to indicate the cause of the issue.

dkosovic commented 7 years ago

Actually according to https://libreswan.org/wiki/Building_and_installing_from_source it's just a matter of issuing the following to build Ubuntu libreswan .deb packages from the source tar ball :

cd libreswan-3.19/debian 
make deb

EDIT: tried to build libreswan and looks like that page has wrong info.

dkosovic commented 7 years ago

Sorry I mustn't have built Libreswan before, turns out it was more complicated than I thought, but managed to build the .deb package and install it.

First have to install the dependencies (note: latex related dependencies get downloaded which are large in size):

sudo apt install \
  build-essential \
  bison \
  bzip2 \
  debhelper \
  devscripts \
  flex \
  htmldoc \
  libcurl4-nss-dev \
  libkrb5-dev \
  libldap2-dev \
  libnspr4-dev \
  libnss3-dev \
  libnss3-tools \
  libpam0g-dev \
  libsystemd-dev \
  libunbound-dev \
  libevent-dev \
  man2html \
  xmlto \
  po-debconf

Remove strongswan :

sudo apt remove "strongswan*" "libstrongswan*"
sudo rm -f /etc/ipsec.secrets /etc/ipsec.conf

Download, build and install libreswan :

wget https://github.com/libreswan/libreswan/archive/v3.19/libreswan-3.19.tar.gz
tar xvzf libreswan-3.19.tar.gz
cd libreswan-3.19
make deb

sudo dpkg -i ../libreswan_3.19-1_amd64.deb
dePhantum commented 7 years ago

I will be returning to this. As I mentioned prior I could not get libreswan to compile and link on my system based upon their install guide for the last two versions.

dePhantum commented 7 years ago

I will be returning to this. As I mentioned prior I could not get libreswan to compile and link on my system based upon their install guide for the last two versions. Are saying that you don't think that the strongswan package will not work?

dkosovic commented 7 years ago

There was one dependency missing when I tried to build on Ubuntu 16.10 using the instructions I previously provided and it was devscripts, I've updated the previous build instructions.

I've also upload a libreswan_3.19-1_amd64.deb package that was built on x86-64 Ubuntu 16.10 to dropbox and it can be download and installed with:

wget https://www.dropbox.com/s/7dpjp1jtg690hdq/libreswan_3.19-1_amd64.deb
sudo apt remove "strongswan*" "libstrongswan*"
sudo rm -f /etc/ipsec.secrets /etc/ipsec.conf
sudo dpkg -i libreswan_3.19-1_amd64.deb

If you get the following message for /etc/ipsec.conf and /etc/ipsec.secrets while installing libreswan, just press Y or I:

...
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
...

There seems to be some kind of issue between strongswan and whatever the VPN server is running. I just want to rule out that Libreswan doesn't have the issue also. If Libreswan has the issue also, it might provide better diagnostics.

dkosovic commented 7 years ago

apparently commit https://github.com/nm-l2tp/network-manager-l2tp/commit/61f3f7d6ae00adf62121fbaf14451d53efc7283a from pull request https://github.com/nm-l2tp/network-manager-l2tp/pull/37 fixes this strongswan issue.

dePhantum commented 7 years ago

Actually it did not, it introduced some issues with my linux machine which I have not yet resolved.

On 3/9/2017 6:33 AM, Douglas Kosovic wrote:

apperently commit 61f3f7d https://github.com/nm-l2tp/network-manager-l2tp/commit/61f3f7d6ae00adf62121fbaf14451d53efc7283a from pull request #37 https://github.com/nm-l2tp/network-manager-l2tp/pull/37 fixes this strongswan issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nm-l2tp/network-manager-l2tp/issues/36#issuecomment-285339434, or mute the thread https://github.com/notifications/unsubscribe-auth/AX9o36zh4LEw0qs0oEQ8GaFLB2d0MNmaks5rj_GQgaJpZM4LjzIJ.

dePhantum commented 7 years ago

Well lo and behold.

I applied your fix but it did not start working until I made a few changes to the conf files

1) I had changed the /etc/NetworkManager/NetworkManager.conf and set managed=true

2) I changed my /etc/network/interfaces and removed the lo (loopback) default and added my network card which was missing:

auto lo

iface lo inet loopback

auto enp5s0 iface enp5s0 inet dhcp

dns-nameservers 8.8.8.8 4.2.2.1 84.200.69.80 8.26.56.26 208.67.222.222

and also added the dns nameservers seen above in the same file. (don't know if it is even used since I am not using a static address in the interface file, I defined that at the router level). enp5s0 is my ethernet card where most folks I guess use eth0

Maybe that will help some one. I also found this helps to get me seeing out side networks when debugging the issue:

sudo /sbin/ifconfig enp5s0 netmask 255.255.255.0 broadcast 192.168.1.253 sudo ip route add default via 192.168.1.254

On 3/9/2017 6:33 AM, Douglas Kosovic wrote:

apperently commit 61f3f7d https://github.com/nm-l2tp/network-manager-l2tp/commit/61f3f7d6ae00adf62121fbaf14451d53efc7283a from pull request #37 https://github.com/nm-l2tp/network-manager-l2tp/pull/37 fixes this strongswan issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nm-l2tp/network-manager-l2tp/issues/36#issuecomment-285339434, or mute the thread https://github.com/notifications/unsubscribe-auth/AX9o36zh4LEw0qs0oEQ8GaFLB2d0MNmaks5rj_GQgaJpZM4LjzIJ.

dkosovic commented 7 years ago

Just for confirmation, when you say my fix, are you referring to using libreswan and not y4uperka's pull request that was recently committed ?

Glad to hear you solved the issue.

Although not related, reminds me of the unmanaged device with NetworkManager issue on Ubuntu 17.04 (Zesty Zaps) : https://github.com/nm-l2tp/network-manager-l2tp/wiki#dns-on-ubuntu-1704-zesty-zapus but at least this issue should hopefully be fixed before Ubuntu 17.04 is released.

dePhantum commented 7 years ago

yes the libreswan.

Also I would like help develop the source, I am using Eclipse CDE, are there are docs you have to help get started?

On 3/9/2017 4:15 PM, Douglas Kosovic wrote:

Just for confirmation, when you say my fix, are you referring to using libreswan and not y4uperka's pull request that was recently committed ?

Glad to hear you solved the issue.

Although not related, reminds me of the unmanaged device with NetworkManager issue on Ubuntu 17.04 (Zesty Zaps) : https://github.com/nm-l2tp/network-manager-l2tp/wiki#dns-on-ubuntu-1704-zesty-zapus but at least this issue should hopefully be fixed before Ubuntu 17.04 is released.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nm-l2tp/network-manager-l2tp/issues/36#issuecomment-285501085, or mute the thread https://github.com/notifications/unsubscribe-auth/AX9o3_lZ9--QR--hRiY8pRasdxBIZd75ks5rkHoZgaJpZM4LjzIJ.

dePhantum commented 7 years ago

yeah, you can close the ticket, it was the default interfaces file and such that was preventing the communication

On 3/9/2017 4:15 PM, Douglas Kosovic wrote:

Just for confirmation, when you say my fix, are you referring to using libreswan and not y4uperka's pull request that was recently committed ?

Glad to hear you solved the issue.

Although not related, reminds me of the unmanaged device with NetworkManager issue on Ubuntu 17.04 (Zesty Zaps) : https://github.com/nm-l2tp/network-manager-l2tp/wiki#dns-on-ubuntu-1704-zesty-zapus but at least this issue should hopefully be fixed before Ubuntu 17.04 is released.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nm-l2tp/network-manager-l2tp/issues/36#issuecomment-285501085, or mute the thread https://github.com/notifications/unsubscribe-auth/AX9o3_lZ9--QR--hRiY8pRasdxBIZd75ks5rkHoZgaJpZM4LjzIJ.

dkosovic commented 7 years ago

Thanks, I was skeptical y4uperka's pull request fixed this issue, but knew it fixed the NAT issue he had.

I'm happy to accept GitHub pull requests for code you develop, more details of how GitHub pull requests work here: https://help.github.com/articles/about-pull-requests/

I track the upstream Gnome VPN plugins, especially network-manger-pptp which this plugin shares lots of code with: https://git.gnome.org/browse/?q=network-manager

There is a little bit of Gnome developer doco here : https://wiki.gnome.org/Git

I'll hopefully be releasing Ubuntu pre-built package this weekend that have a dependency on the recently released latest update of strongswan (which I've been waiting for the AppArmor fix before releasing a network-manger-l2tp Ubuntu package).

If you are interested in fixing the strongswan code, might be best to report it to strongswan issues: https://wiki.strongswan.org/projects/strongswan/issues they'll also probably be able to give you advice on how to tackle fixing the strongswan code.

Probably be best to run strongswan from the command-line for any tests they might request. Fortunately NetworkManager-l2tp generates a temporary config file with a name something like /var/run/nm-ipsec-l2tp.28866/ipsec.confand you can use that as a starting point. You'll be able to start a strongswan connection and test it is up with something like:

sudo ipsec restart --conf /var/run/nm-ipsec-l2tp.28866/ipsec.conf --debug
sudo ipsec up nm-ipsec-l2tp-28766
sudo ipsec status