[strongSwan] StrongSwan IPSEC/L2TP VPN Client to Zyxel USG-20W

Sat Oct 29 08:15:20 CEST 2016

I got past this issue by switching from strongswan to openswan.  I never figured out what's wrong with the strongswan connection, but openswan worked more or less "out of the box" on the Linux box as did the Windows 10 native client in my earlier trials.

________________________________
From: Users <users-bounces at lists.strongswan.org> on behalf of Tom Jackson <tjtj999999 at outlook.com>
Sent: Monday, October 24, 2016 8:19:22 PM
To: users at lists.strongswan.org
Subject: [strongSwan] StrongSwan IPSEC/L2TP VPN Client to Zyxel USG-20W

I've configured a Zyxel USG-20W at the office as a IPsec/L2TP VPN server.  I can successfully connect to this from multiple Windows 10 machines using the built-in client, and have tested this on multiple remote networks.  This setup uses a pre-shared key, and "Type of sign-in info" in the Windows configuration is "User name and password."  The pre-shared key, user name, and password are all correspondingly entered into the configuration of the Zyxel.

I'm trying now to configure a Linux client, running StrongSwan on the Debian Linux machine.  This is not working.

In the configuration info that follows, office-public-ip is a place holder for the actual IP in W.X.Y.Z format, home-public-ip is the IP (same format) that I get from the home location where I'm running the test, and home-lan-ip is the IP for the Linux box as assigned via DHCP from my home router, e.g. a number in the range 192.168.A.B.

I think this doesn't matter, but... I am accessing the Zyxel from home during the testing via an IPsec/L2TP VPN session from a Windows 10 machine.  That Windows 10 machine then has the same public IP as the Linux box that I'm trying to test, but, of course, a different local number at home 192.168.A.C, and also a IP address representing it on the work network ala the VPN connection as 192.168.D.1.  The Zyxel's local IP address is 192.168.E.1, where A, D, and E are all different numbers corresponding to different subnets.

Setup on the Linux machine in ipsec.conf:

-------

config setup

charondebug="ike 5"

conn Conn

authby=secret

keyexchange=ikev1

esp=aes256-sha256

ike=aes256-sha256-modp1024!

auto=add

type=transport

left=%defaultroute

right=office-public-ip

--------

The IKE and ESP match protocols configured on the Zyxel. (If I change them to something that doesn't match, I get a different error than what I'm going to show below.)

I restarted ipsec after changing the file with

sudo /etc/init.d/ipsec restart

and then I try to bring up the connection with

sudo ipsec up Conn

In the terminal on the Debian box, I get these messages:

--------
initiating Main Mode IKE_SA Conn[1] to office-public-ip
generating ID_PROT request 0 [SA V V V V]
sending packet: from home-lan-ip[500] to office-public-ip[500] (156 bytes)
received packet from office-public-ip[500] to home-lan-ip[500] (84 bytes)
parsed ID_PROT response 0 [ SA ]
generating ID_PROT request 0 [ KE No ]
sending packet: from home-lan-ip[500] to office-public-ip[500] (196 bytes)
received packet from office-public-ip[500] to home-lan-ip[500] (91 bytes)
parsed INFORMATIONAL_V1 request 3824697940 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED error notify
establishing connection ‘Conn’ failed

--------

The log messages on the Zyxel are (abbreviating the various cookie values):

--------
Recv Main Mode request from [home-public-ip]
The cookie pair is : 0x027... / 0x074…
Recv: [SA] [VID][VID] [VID][VID]
Recv: IKE sa: SA([0] protocol = IKE(1), AES CBC key len = 256, HMAC-SHA256 PRF, HMAC-SHA265-128, 1024 bit MODP;).
The cookie pair is 0x074… / 0x027…
[SA] : No proposal chosen
Send:[SA]
Recv:[KE][NONCE]
Send:[NOTIFY:AUTHENTICATION_FAILED]
The cookie pair is : 0x074… / 0x027…
ISAKMP SA [] is disconnected

--------

In contrast, the Phase 1 log messages from a successful session initiated by one of the Windows clients are

--------
Recv Main Mode request from [home-public-ip]
The cookie pair is : 0xe099… / 0xe98…
Recv: [SA] [VID][VID] [VID][VID] [VID][VID] [VID][VID]
Recv IKE sa: SA([0] protocol = IKE(1), AES CBC key len = 256, HMAC-SHA1 PRF, HMAC-SHA1-96, 384 bin ECP, AES CBC key len = 128, 256 bit ECP, 2048 bit MODP, 3DES, 1024 bit MODP;).
The cookie pair is 0x099… / 0xe098…
Send: [SA] [VID][VID] [VID][VID] [VID][VID] [VID][VID]
Recv: [KE][NONCE][PRV][PRV]
Send: [KE][NONCE][PRV][PRV]
Recv: [ID][HASH]
The cookie pair is : 0x099… / 0xe098
Send: [ID][HASH]
The cookie pair is : 0x099… / 0xe098
Phase 1 IKE SA process done

--------

(From this point, the successful session has another sequences of log messages corresponding to Phase 2.  Also, the Windows machine must be accepted using 3DES-SHA1-DH2 since that's the apparent overlap between the Windows proposal and what's allowed by the Zyxel's current configuration.)

It would seem that the StrongSwan client is sending less information for authentication, but I have not figured out exactly what's not being sent and how to make it go.

Other things that I've tried:

1. keyexchange=ikev2.  Result: Major number error

2. leftauth (with various options).  Result:  Won't run with ikev1 because it says (on Linux box) that authorization method is not supported, and ikev2 gives error in #1.

3. Changing the algorithms provided to the "ike" option.  Result:  If I change to something consistent with what's on the Zyxel, no real difference.  I see the algorithms reflected in the corresponding IKE message in the Zyxel log, but the result is the same.  If I change to something not consistent with what's on the Zyxel (just for kicks since it's broken anyway), then the process stops at "No Proposal Chosen."

4. Changing the algorithms provided to the "ike" option so that it appears to match the proposal provided by the Windows client.  In this case, the "Recv IKE" messages look identical between Windows and Linux, but the process from the Linux client fails in the same way as before.

Any help would be greatly appreciated.  I've been stuck on this on and off for over a week!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20161029/dc333fdf/attachment-0001.html>