Home / ubuntu / Questions / 1293690
Accepted
Zulgrib
Asked: 2020-11-20 09:09:01 +0800 CST

Why is DH20 not correctly negotiated with remote host when establishing an IPSec tunnel?

  • 772

Trying to connect a computer to a VPN server configured this way :

Router# show isakmp policy
ISAKMP policy: L2TP_VPN
  IKD_ID: 8
  negotiation mode: main
  proposal: 1
    encryption: aes256
    authentication: sha256
  proposal: 2
    encryption: aes256
    authentication: sha512
  SA lifetime: 86400
  key group: group20
  NAT traversal: yes
  dead peer detection: yes
  my address: wan1
    type: interface
  secure gateway address: 1
    address: 0.0.0.0
  secure gateway address: 2
    address: 0.0.0.0
  fall back: deactivate
  fall back check interval: 300
  authentication method: pre-share
  pre-shared key: PRESHAREDKEYHERE
  certificate: default
  local ID: 0.0.0.0
    type: ip
  peer ID: 
    type: any
  user ID: 
  type: 
  X-Auth: no
    type: server
    method: default
    allowed user: Utilisateurs_VPN
    username: 
    password: 
  EAP-Auth: no
    type: 
    aaa method: 
    allowed user: 
    allowed auth method: mschapv2
    username: 
    auth method: mschapv2
    password: 
  vcp reference count: 0
  IKE_version: IKEv1
  active: yes

The phase 2 part

Router> show crypto map VPN_CONNECTION1
cryptography mapping: VPN_CONNECTION1
  VPN gateway: L2TP_VPN
  Gateway IP Version: IPv4
  encapsulation: transport
  active protocol: esp
  transform set: 1
    encryption: aes256
    authentication: sha512
  transform set: 2
    encryption: aes256
    authentication: sha256
  SA lifetime: 28800
  PFS: group15
  nail up: no
  scenario: remote-access-server
  l2tp: yes
  local policy: L2TP_VPN_LOCAL
  remote policy: any
  protocol type: any
  configuration provide:   
    mode config: no
    configuration payload: no
    address pool: 
    first dns: 
    second dns: 
    first wins: 
    second wins: 
  policy enforcement: no
  replay detection: no
  narrowed: yes
  adjust mss: yes
  mss value: 0
  stop rekeying: no
  NetBIOS broadcast over IPSec: no
  outbound SNAT: no
    source: 
    destination: 
    target: 
  inbound SNAT: no
    source: 
    destination: 
    target: 
  inbound DNAT: no
  vcp reference count: 0
  active: yes
  VTI: 
  VPN ID: 2
  connected: no
  connectivity check: no
    check method: none
    IP address: none
    period: none
    timeout: none
    fail tolerance: none
    port: none
    log: no
  rule type: 4in4

L2TP part :

Router# show l2tp-over-ipsec ;
L2TP over IPSec:
  activate          : yes
  crypto            : VPN_CONNECTION1
  address pool      : L2TP_VPN_IP_ADDRESS_POOL
  authentication    : default
  certificate       : default
  user              : Utilisateurs_VPN
  keepalive timer   : 60
  first dns server  : 
  second dns server : 
  first wins server : 
  second wins server:

This is how ike-scan sees the server :

Zulgrib@computer:~$ sudo ./ike-scan.sh GATEWAYIP | grep SA=
    SA=(Enc=AES Hash=SHA2-512 Auth=PSK Group=21 KeyLength=256 LifeType=Seconds LifeDuration(4)=0x00007080)

I configured the client using NetworkManager.

[connection]
id=MyVpnName
uuid=3a6d0094-ff3e-49a2-95a3-54303542b2da
type=vpn
autoconnect=false
permissions=user:Zulgrib:;
timestamp=1605784830

[vpn]
gateway=GATEWAYIP
ipsec-enabled=yes
ipsec-esp=aes256-sha256-ecp384
ipsec-ike=aes256-sha256-ecp384
ipsec-psk=PRESHAREDKEY
password-flags=1
user=testvpn
service-type=org.freedesktop.NetworkManager.l2tp

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

But router side, logs claim the VPN client tried to use AES128 and modp3072 instead.

Recv:[SA][VID][VID][VID][VID][VID]
Recv IKE sa: SA([0] protocol = IKE (1), AES CBC key len = 256, HMAC-SHA256 PRF, HMAC-SHA256-128, 384 bit ECP, AES CBC key len = 128, 3072 bit MODP; ).
The cookie pair is : 0xhexhexhex / 0xhexhexhex [count=2]
Send:[SA][VID][VID][VID][VID][VID][VID][VID][VID][VID][VID][VID]
Recv:[NOTIFY:INVALID_KEY_INFORMATION]

Client side, there is an error while negotiating too :

nov. 19 17:28:16 computer NetworkManager[1337]: initiating Main Mode IKE_SA 3a6d0094-ff3e-49a2-95a3-54303542b2da[1] to GATEWAYIP
nov. 19 17:28:16 computer NetworkManager[1337]: generating ID_PROT request 0 [ SA V V V V V ]
nov. 19 17:28:16 computer NetworkManager[1337]: sending packet: from 192.168.170.52[500] to GATEWAYIP[500] (216 bytes)
nov. 19 17:28:16 computer NetworkManager[1337]: received packet: from GATEWAYIP[500] to 192.168.170.52[500] (410 bytes)
nov. 19 17:28:16 computer NetworkManager[1337]: parsed ID_PROT response 0 [ SA V V V V V V V V V V V ]
nov. 19 17:28:16 computer NetworkManager[1337]: received unknown vendor ID: f7:58:f2:26:68:75:0f:03:b0:8d:f6:eb:e1:d0:04:03
nov. 19 17:28:16 computer NetworkManager[1337]: received draft-ietf-ipsec-nat-t-ike-02 vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received draft-ietf-ipsec-nat-t-ike-03 vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received NAT-T (RFC 3947) vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received XAuth vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received DPD vendor ID
nov. 19 17:28:16 computer NetworkManager[1337]: received unknown vendor ID: af:ca:d7:13:68:a1:f1:c9:6b:86:96:fc:77:57
nov. 19 17:28:16 computer NetworkManager[1337]: received unknown vendor ID: f9:19:6d:f8:6b:81:2f:b0:f6:80:26:d8:87:6d:cb:7b:00:04:32:00
nov. 19 17:28:16 computer NetworkManager[1337]: received unknown vendor ID: ac:40:f8:c4:38:99:27:c6:e8:ac:24:53:1b:b7:8b:2b:27:fc:b5:21:73:53:c1:94:4a:02:92:52:ac:c9:ab:03:8e:fa:5c:a1:d1:c6:24:15:c3:df:8e:e1:58:61:fa:ea:48:80:9d:c2:a6:c4:b
nov. 19 17:28:16 computer NetworkManager[1337]: received unknown vendor ID: b6:c9:8c:ca:29:0a:eb:be:37:f1:9f:31:12:d2:d7:cb
nov. 19 17:28:16 computer NetworkManager[1337]: negotiated DH group not supported
nov. 19 17:28:16 computer NetworkManager[1337]: generating INFORMATIONAL_V1 request 1203248937 [ N(INVAL_KE) ]
nov. 19 17:28:16 computer NetworkManager[1337]: sending packet: from 192.168.170.52[500] to GATEWAYIP[500] (56 bytes)
nov. 19 17:28:16 computer NetworkManager[1337]: establishing connection '3a6d0094-ff3e-49a2-95a3-54303542b2da' failed
nov. 19 17:28:16 computer charon[30591]: 12[IKE] negotiated DH group not supported
nov. 19 17:28:16 computer charon[30591]: 12[ENC] generating INFORMATIONAL_V1 request 1203248937 [ N(INVAL_KE) ]
nov. 19 17:28:16 computer charon[30591]: 12[NET] sending packet: from 192.168.170.52[500] to GATEWAYIP[500] (56 bytes)
nov. 19 17:28:16 computer NetworkManager[1337]: Stopping strongSwan IPsec...

How do I configure NetworkManager to use ecp384 (DH20) and not modp3072 (DH15), plus AES256 in all phases ?

Router side configuration cannot be changed, because it is currently the strongest configuration that are (supposedly) supported by both strongswan (used by network manager) and Win10 IPSec client.

vpn network-manager 18.04 ipsec l2tp

1 Answers

  1. Best Answer

    Found out OpenSSL is mandatory for ecp384 to work. By default, Canonical package for libstrongswan does not use OpenSSL, it require package libstrongswan-standard-plugins for that.

    • 0