[strongSwan] Problem with IPsec/L2TP VPN!
kman at fastmail.com
Sun Apr 7 17:57:12 CEST 2019
Your log says it's a problem with traffic selectors. Not encryption.
- What is your overall setup?
strongSwan / libreSwan on server / client?
- What are you trying to do?
An L2TP / IPSec connection?
- What are your configs?
Please show config files from both sides (feel free to obfuscate IP addresses).
When using NetworkManager to create an L2TP / IPSec connection, the *swan config should be under /var/run/nm-l2tp-*
Re: strong / libre settings
If you use the "old" config format in strongSwan (it has two) it's same (more or less) as libreSwan. Definitely for encryption / proposals.
On Sun, Apr 7, 2019, at 6:51 PM, A P wrote:
> Ok, it just does not work, no matter what I try and what I read...
> Perhaps, I am using wrong Phase1 and Phase2 settings. What should these entries be for Strongswan and also for Libreswan?
> Here is what ike-scan returned:
> ... SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 ...
> Spasibo for your help!
> *From:* Users <users-bounces at lists.strongswan.org> on behalf of Kostya Vasilyev <kman at fastmail.com>
> *Sent:* Sunday, 7 April 2019 02:08
> *To:* users at lists.strongswan.org
> *Subject:* Re: [strongSwan] Problem with IPsec/L2TP VPN!
> On Sat, Apr 6, 2019, at 5:21 PM, A P wrote:
>> I have tried and tried and tried... With NetworkManager and totally manually, and I get the same error, with nothing much about it on the web... I get "*no acceptable traffic selectors found*"
>> Thank in advance for your help!
>> Here is the log:
>> initiating Main Mode IKE_SA myvpn to 18.104.22.168
>> generating ID_PROT request 0 [ SA V V V V V ]
>> sending packet: from 192.168.1.2 to 22.214.171.124 (176 bytes)
>> received packet: from 126.96.36.199 to 192.168.1.2 (124 bytes)
>> parsed ID_PROT response 0 [ SA V V ]
>> received NAT-T (RFC 3947) vendor ID
>> received FRAGMENTATION vendor ID
>> selected proposal: IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>> generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
>> sending packet: from 192.168.1.2 to 188.8.131.52 (244 bytes)
>> received packet: from 184.108.40.206 to 192.168.1.2 (304 bytes)
>> parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
>> received Cisco Unity vendor ID
>> received XAuth vendor ID
>> received unknown vendor ID: 65:83:ea:08:11:06:75:21:d2:51:cd:44:16:26:47:73
>> received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
>> local host is behind NAT, sending keep alives
>> generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
>> sending packet: from 192.168.1.2 to 220.127.116.11 (100 bytes)
>> received packet: from 18.104.22.168 to 192.168.1.2 (84 bytes)
>> parsed ID_PROT response 0 [ ID HASH V ]
>> received DPD vendor ID
>> IKE_SA myvpn established between 192.168.1.2[192.168.1.2]...22.214.171.124[126.96.36.199]
>> scheduling reauthentication in 3390s
>> maximum IKE_SA lifetime 3570s
>> generating QUICK_MODE request 3689125877 [ HASH SA No ID ID NAT-OA NAT-OA ]
>> sending packet: from 192.168.1.2 to 188.8.131.52 (188 bytes)
>> received packet: from 184.108.40.206 to 192.168.1.2 (204 bytes)
>> parsed QUICK_MODE response 3689125877 [ HASH SA No ID ID N((24576)) NAT-OA NAT-OA ]
>> selected proposal: ESP:3DES_CBC/HMAC_MD5_96/NO_EXT_SEQ
>> *no acceptable traffic selectors found*
>> establishing connection 'myvpn' failed
> l2tp works over UDP and it's a fixed port 1701 on the server.
> You need to have "traffic selectors" that match that - so that IPSec knows what exactly (what *traffic*) you want to encrypt - and they need to agree between the server and the client.
> I assume that Network Manager has set this up correctly on your "local" side.
> Let's check your server config. Please post your tunnel config file - i.e. the file where you have "left=", "right=", and all that fun stuff.
> And please check that you have items like these
> Protocol 17 is UDP and we need port number 1701 on the server.
> Or use names
> This is for "legacy" config file format (which it seems is used more often, because of tutorials on the web).
> PS - this seems like a good tutorial
> PPS - 3DES and MD5 are not considered good enough these days...
> -- K
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users