4

I have 2 computers - both on Debian 10. I need to connect them both to the same remote VPN server. One has a desktop manager (with Network Manager), and the other does not. I will refer to the one with the desktop manager as Debian GUI and the other as Debian Server.

I have successfully connected Debian GUI to the remote VPN server using Network Manager, however I am stuck unable to connect Debian Server to the remote VPN server.

Here are the Network Manager settings, with details modified for privacy:

My LAN IP address on client PC before turning on the VPN: 192.168.0.1
VPN Type: TTL2TP VPN
VPN Gateway public IP address: 100.100.100.100
Remote network domain: mywindowsdomain
Remote network username: me
Remote network password: mypassword
Enable IPSec tunnel to L2TP host: yes
Pre-shared key: mypresharedkey
Phase 1 Algorithms: aes256-md5-modp1024
Phase 2 Algorithms: aes256-md5
Enforce UDP encapsulation: yes
L2TP PPP authentication: MS Chap v2
Allow BSD data compression: yes
Allow deflate compression: yes
Use TCP header compression: yes
Use protocol field compression negotiation: yes
Use address/control compression: yes
MTU: 1400
MRU: 1400

network manager

network manager ipsec settings

network manager ppp settings

These are the only settings I used in Network Manager, and I am able to successfully connect to the remote VPN server on Debian GUI. However I have been unable to do the same on Debian Server. In Debian Server I installed strongswan and xl2tpd. I don't care which client I use as long as I can get it working, these were just the ones I found available in Debian 10. I attempted to configure them like so:

$ cat /etc/xl2tpd/xl2tpd.conf
[lac vpn-connection]
lns = 100.100.100.100
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes

$ cat /etc/sysctl.conf
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

$ cat /etc/ipsec.secrets
include /var/lib/strongswan/ipsec.secrets.inc
192.168.0.1 100.100.100.100 : PSK "mypresharedkey"

$ cat /etc/ipsec.conf
config setup                                                                    
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12        
    nat_traversal=yes
    protostack=netkey
    plutoopts="--interface=eth0"
    strictcrlpolicy=yes
    uniqueids = no
conn L2TP-PSK
    pfs=no
    auto=add
    authby=secret
    # phase 1
    keyexchange=ikev1
    ike=aes256-md5-modp1024
    # phase 2
    esp=aes256-md5
    forceencaps=yes
    keyingtries=3
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear
    rekey=yes
    ikelifetime=8h
    keylife=1h
    type=transport
    type=tunnel
    left=192.168.0.1
    leftprotoport=17/1701
    right=100.100.100.100
    rightprotoport=17/1701

include /var/lib/strongswan/ipsec.conf.inc

$ cat /etc/ppp/options.l2tpd.client
ipcp-accept-local
ipcp-accept-remote
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
nobsdcomp
nodeflate
noccp
noauth
idle 1800
mtu 1400
mru 1400
defaultroute
usepeerdns
debug
connect-delay 5000
name mywindowsdomain\\me
password mypassword

$ cat /etc/strongswan.conf
charon {
    # this line commented out on 2020-11-19
    #load_modular = yes
    plugins {
        include strongswan.d/charon/*.conf
    }
}

include strongswan.d/*.conf

Let me know if any files needed to diagnose this issue are missing and I can add their contents here.

Then I started everything and got the following results:

$ sudo systemctl restart xl2tpd.service
$ sudo systemctl status xl2tpd.service 
● xl2tpd.service - LSB: layer 2 tunelling protocol daemon
   Loaded: loaded (/etc/init.d/xl2tpd; generated)
   Active: active (running) since Thu 2020-11-19 21:13:41 ACDT; 12s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 11111 ExecStart=/etc/init.d/xl2tpd start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 4915)
   Memory: 876.0K
   CGroup: /system.slice/xl2tpd.service
           └─11112 /usr/sbin/xl2tpd

$ sudo systemctl restart strongswan.service
$ sudo systemctl status strongswan.service 
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-11-19 21:17:16 ACDT; 9s ago
 Main PID: 11113 (starter)
    Tasks: 18 (limit: 4915)
   Memory: 3.4M
   CGroup: /system.slice/strongswan.service
           ├─11114 /usr/lib/ipsec/starter --daemon charon --nofork
           └─11115 /usr/lib/ipsec/charon

$ # all good so far i guess, but then this fails:
$ sudo ipsec up L2TP-PSK
initiating Main Mode IKE_SA L2TP-PSK[2] to 100.100.100.100
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 192.168.0.1[500] to 100.100.100.100[500] (240 bytes)
received packet: from 100.100.100.100[500] to 192.168.0.1[500] (188 bytes)
parsed ID_PROT response 0 [ SA V V V V V ]
received NAT-T (RFC 3947) vendor ID
received DPD vendor ID
received unknown vendor ID: 88:77:44:11:55:aa:66:88:cc:aa:22:dd:00:00:00:00
received FRAGMENTATION vendor ID
received FRAGMENTATION vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 192.168.0.1[500] to 100.100.100.100[500] (236 bytes)
received packet: from 100.100.100.100[500] to 192.168.0.1[500] (220 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 192.168.0.1[4500] to 100.100.100.100[4500] (92 bytes)
received packet: from 100.100.100.100[4500] to 192.168.0.1[4500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA L2TP-PSK[2] established between 192.168.0.1[192.168.0.1]...100.100.100.100[100.100.100.100]
scheduling reauthentication in 28017s
maximum IKE_SA lifetime 28557s
generating QUICK_MODE request 3034622638 [ HASH SA No ID ID ]
sending packet: from 192.168.0.1[4500] to 100.100.100.100[4500] (204 bytes)
received packet: from 100.100.100.100[4500] to 192.168.0.1[4500] (76 bytes)
parsed INFORMATIONAL_V1 request 3102838840 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'L2TP-PSK' failed

Sources I used (I have tried a lot of combinations):

https://wiki.archlinux.org/index.php/Openswan_L2TP/IPsec_VPN_client_setup https://github.com/xelerance/Openswan/wiki/L2tp-ipsec-configuration-using-openswan-and-xl2tpd http://manpages.ubuntu.com/manpages/bionic/man5/ipsec.conf.5.html

1 Answer 1

0

It is failing at the IPsec quick mode proposal (i.e. phase 2 proposal), what you have in the GUI doesn't match what you have in the ipsec.conf file, the missing exclamation mark can be significant.

Is the Debian Server not using NetworkManager at all for its wired (or WiFi) networking? NetworkManager has a command line interface.

You can use the NetworkManager CLI with the nmcli command:

  • list all NM connections: nmcli con
  • bring up VPN connection : nmcli con up id VPN-Connection-Name
  • bring down VPN connection: nmcli con down id VPN-Connection-Name

Where VPN-Connection-Name is the actual name of the VPN connection as listed in the nmcli con output.

You can copy the corresponding NetworkManager VPN connection profile file which is stored under /etc/NetworkManager/system-connections/ from the desktop computer to the headless server.

To pickup the new VPN connection profile file (or changes that you might make to the file if you edit it), issue the following:

  • nmcli con reload

Be sure to to install network-manager-l2tp, you won't need the GNOME GUI network-manager-l2tp-gnome package.

3
  • 1
    I forgot to mention, not sure if both Debian boxes are behind the same NAT. The L2TP/IPsec server might not allow multiple clients behind same NAT at the same time. Some L2TP/IPsec servers can be configured to do so, most aren't. Commented Nov 20, 2020 at 6:51
  • This ^^ is important enough that it should be in your excellent answer, not left as a comment Commented Nov 20, 2020 at 7:43
  • Although this limitation of most L2TP/IPsec VPN servers not allowing multiple clients behind the same NAT isn't related to the NO_PROPOSAL_CHOSEN error. I just thought I would mention it as it could be the next problem faced after solving the quick mode proposal issue. Commented Nov 22, 2020 at 6:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .