<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>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.</p>
<p><br>
</p>
<p>I'm trying now to configure a Linux client, running StrongSwan on the Debian Linux machine. This is not working.</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Setup on the Linux machine in ipsec.conf:</p>
<p><br>
</p>
<p>-------</p>
<p>config setup</p>
<p>charondebug="ike 5"</p>
<p><br>
</p>
<p>conn Conn</p>
<p>authby=secret</p>
<p>keyexchange=ikev1</p>
<p>esp=aes256-sha256</p>
<p>ike=aes256-sha256-modp1024!</p>
<p>auto=add</p>
<p>type=transport</p>
<p>left=%defaultroute</p>
<p>right=office-public-ip</p>
<p>--------</p>
<p><br>
</p>
<p>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.)</p>
<p><br>
</p>
<p>I restarted ipsec after changing the file with </p>
<p><br>
</p>
<p>sudo /etc/init.d/ipsec restart</p>
<p><br>
</p>
<p>and then I try to bring up the connection with</p>
<p><br>
</p>
<p>sudo ipsec up Conn</p>
<p><br>
</p>
<p>In the terminal on the Debian box, I get these messages:</p>
<p>--------<br>
initiating Main Mode IKE_SA Conn[1] to office-public-ip <br>
generating ID_PROT request 0 [SA V V V V] <br>
sending packet: from home-lan-ip[500] to office-public-ip[500] (156 bytes) <br>
received packet from office-public-ip[500] to home-lan-ip[500] (84 bytes) <br>
parsed ID_PROT response 0 [ SA ] <br>
generating ID_PROT request 0 [ KE No ] <br>
sending packet: from home-lan-ip[500] to office-public-ip[500] (196 bytes) <br>
received packet from office-public-ip[500] to home-lan-ip[500] (91 bytes) <br>
parsed INFORMATIONAL_V1 request 3824697940 [ N(AUTH_FAILED) ] <br>
received AUTHENTICATION_FAILED error notify <br>
establishing connection Conn failed</p>
<p><span>--------</span></p>
<p><span><br>
</span></p>
<p>The log messages on the Zyxel are (abbreviating the various cookie values):</p>
<p><span>--------</span><br>
Recv Main Mode request from [home-public-ip] <br>
The cookie pair is : 0x027... / 0x074
<br>
Recv: [SA] [VID][VID] [VID][VID] <br>
Recv: IKE sa: SA([0] protocol = IKE(1), AES CBC key len = 256, HMAC-SHA256 PRF, HMAC-SHA265-128, 1024 bit MODP;).
<br>
The cookie pair is 0x074
/ 0x027
<br>
[SA] : No proposal chosen <br>
Send:[SA] <br>
Recv:[KE][NONCE] <br>
Send:[NOTIFY:AUTHENTICATION_FAILED] <br>
The cookie pair is : 0x074
/ 0x027
<br>
ISAKMP SA [] is disconnected</p>
<p><span>--------</span></p>
<p><br>
</p>
<p>In contrast, the Phase 1 log messages from a successful session initiated by one of the Windows clients are</p>
<p><span>--------</span><br>
Recv Main Mode request from [home-public-ip] <br>
The cookie pair is : 0xe099
/ 0xe98
<br>
Recv: [SA] [VID][VID] [VID][VID] [VID][VID] [VID][VID] <br>
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;).
<br>
The cookie pair is 0x099
/ 0xe098
<br>
Send: [SA] [VID][VID] [VID][VID] [VID][VID] [VID][VID] <br>
Recv: [KE][NONCE][PRV][PRV] <br>
Send: [KE][NONCE][PRV][PRV] <br>
Recv: [ID][HASH] <br>
The cookie pair is : 0x099
/ 0xe098 <br>
Send: [ID][HASH] <br>
The cookie pair is : 0x099
/ 0xe098 <br>
Phase 1 IKE SA process done</p>
<p><span>--------</span></p>
<p><br>
</p>
<p>(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.)</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Other things that I've tried:</p>
<p>1. keyexchange=ikev2. Result: Major number error</p>
<p>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.</p>
<p>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."</p>
<p>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.</p>
<p><br>
</p>
<p>Any help would be greatly appreciated. I've been stuck on this on and off for over a week!</p>
<p><br>
</p>
</div>
</body>
</html>