Eu tenho uma implementação OpenSWAN em funcionamento para RA, usando transporte IPsec e l2tp para o túnel, em execução no AWS. A instância tem um IP privado, com um EIP público mapeado para ele.
Eu uso o ip privado para os parâmetros left e leftsubnet e o público no leftid .
Agora estou tentando configurar uma conexão IPSec do mesmo cliente para um novo endpoint, que está executando o StrongSWAN (4.5.2). Eu tentei replicar a configuração do openswan para o strongswan, tanto quanto possível. Por enquanto, estou apenas tentando obter o IPSec configurado (não me preocupando com o l2tp ainda) e estou tendo problemas com a fase 2 (a fase 1 está concluindo ok).
As diferenças na configuração são:
--- openswan.conf 2014-07-18 11:48:01.740966015 +0200
+++ strongswan.conf 2014-07-18 11:46:58.927569703 +0200
@@ -1,11 +1,14 @@
+version 2.0
+
config setup
- protostack=netkey
+ charonstart=no
+ interfaces="%none"
nat_traversal=yes
- virtual_private=%v4:192.168.10.0/24
oe=off
- nhelpers=0
- interfaces=%defaultroute
+ virtual_private="%v4:192.168.11.0/24"
+
+conn %default
+ keyexchange=ikev1
conn remote-access
forceencaps=yes
type=transport
ike=3des-sha1
- phase2alg=3des-sha1
Quando eu levanto a conexão do meu cliente, recebo o seguinte:
003 "myconn" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
108 "myconn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "myconn" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp2048}
117 "myconn" #2: STATE_QUICK_I1: initiate
E nos registros do servidor
"remote-access"[3] 105.1.1.1 #2: NAT-Traversal: Result using RFC 3947: both are NATed
"remote-access"[3] 105.1.1.1 #2: Peer ID is ID_IPV4_ADDR: '192.168.2.2'
"remote-access"[4] 105.1.1.1 #2: deleting connection "remote-access" instance with peer client.ip.addr {isakmp=#0/ipsec=#0}
"remote-access"[4] 105.1.1.1:4500 #2: sent MR3, ISAKMP SA established
"remote-access"[4] 105.1.1.1:4500 #2: cannot respond to IPsec SA request because no connection is known for 54.1.1.1/32===10.0.0.2:4500[54.1.1.1]:17/1701...105.1.1.1.1:4500[192.168.2.2]:17/%any==={192.168.2.2/32}
"remote-access"[4] 105.1.1.1:4500 #2: sending encrypted notification INVALID_ID_INFORMATION to 105.1.1.1:4500
192.168.2.2 é o IP privado do cliente e 105.1.1.1 é o IP público para o qual é NAT.
Procurei por "não posso responder à solicitação de SA do IPsec porque nenhuma conexão é conhecida por" e só obtenho 1 relacionado a strongswan em link , bem como isto mas nenhuma das sugestões funciona (ajustando o rightid no par ou adicionando o leftsourceip no servidor strongswan).
O par / cliente com o qual estou me conectando com o strongswan é o libreswan 3.7
editar aqui estão as configurações
StrongSWAN na CE:
conn remote-access
authby=secret
pfs=no
left=10.0.0.2
leftid=54..1.1.1
leftsubnet=10.0.0.2/32
leftnexthop=%defaultroute
leftprotoport=17/1701
right=%any
rightid=%any
rightsubnetwithin=0.0.0.0/0
rightprotoport=17/%any
type=transport
forceencaps=yes
auto=add
ike=3des-sha1
dpddelay=15
dpdtimeout=45
dpdaction=clear
auth=esp
esp=aes256-sha1,3des-sha1!
O arquivo de segredos neste host:
54.1.1.1 %any : PSK "XXX"
Minha configuração do cliente RA local:
conn myconn
authby=secret
pfs=no
rekey=yes
keyingtries=3
type=transport
left=%defaultroute
leftprotoport=17/1701
right=54.1.1.1
rightprotoport=17/1701
auto=add
phase2=esp
phase2alg=3des-md5;modp1024
forceencaps=yes
segredos:
0.0.0.0 %any 54.1.1.1 : PSK "XXX"
Eu adicionei recentemente os parâmetros phase2 e forceencaps no meu cliente local.
Os diffs mostrados anteriormente eram entre dois hosts baseados em EC2 aos quais estou me conectando. A conexão "myconn" é da minha estação de trabalho, e eu tenho 2 conns, 1 para o ponto openswan (que funciona) e uma cópia dele para o par strongswan (que não funciona). Eu imaginei que usar a mesma abordagem para configurações esquerda / direita resultaria em uma configuração de trabalho.