Eu tenho um problema com a conexão de duas redes com o IPsec. De um lado está o Cisco ASA 55xx no outro roteador TP-Link com Debian 8.3 com StrongSwan atrás do NAT. O problema também é que eu tenho de alguma forma a rede NETMAP / SNAT no lado TP-Link. Mas mesmo sem essas regras, a conexão não quer estabelecer. Como depurar conexão?
Minha configuração (ipsec.conf):
conn %default
ikelifetime=1440m
keylife=60m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
conn intel
left=3.3.3.3 #Actual IP of Debian is 192.168.1.238
leftsubnet=192.168.1.0/24 #This should be NETMAP/SNAT
leftfirewall=yes
leftid=3.3.3.3 #external IP of TP-Link
right=4.4.4.4 #external IP of ASA
rightsubnet=172.29.106.0/24
rightid=4.4.4.4
auto=start
ike=3des-sha1-modp1024
esp=3des-sha1
keyexchange=ikev2
dpdaction=restart
dpddelay=30s
forceencaps=yes
type=tunnel
então eu verifico o status que ele mostra por alguns minutos, mas depois de um minuto ou dois - "Associações de segurança (0 up, 0 connecting):":
root@vpnServer:/var/log# ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 3.16.0-4-amd64, x86_64):
uptime: 35 seconds, since Feb 05 22:54:36 2016
malloc: sbrk 2273280, mmap 0, used 316592, free 1956688
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default stroke updown
Listening IP addresses:
192.168.1.238
Connections:
intel: 3.3.3.3...4.4.4.4 IKEv2, dpddelay=30s
intel: local: [3.3.3.3] uses pre-shared key authentication
intel: remote: [4.4.4.4] uses pre-shared key authentication
intel: child: 192.168.1.0/24 === 172.29.106.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
intel[1]: CONNECTING, 3.3.3.3[%any]...4.4.4.4[%any]
intel[1]: IKEv2 SPIs: 34262c8ac359acf7_i* 0000000000000000_r
intel[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE
Parece que começou a fase 1, mas não pôde receber nenhuma resposta. O TP-LINK tem 500 e 4500 portas encaminhadas para o Debian. ifconfig é:
root@vpnServer:/etc# ifconfig
eth0 Link encap:Ethernet HWaddr 14:da:e9:98:06:1e
inet addr:192.168.1.238 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::16da:e9ff:fe98:61e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:620211 errors:0 dropped:2641 overruns:0 frame:0
TX packets:16517 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 txqueuelen:1000
RX bytes:227442404 (216.9 MiB) TX bytes:6795053 (6.4 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:202 errors:0 dropped:0 overruns:0 frame:0
TX packets:202 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:32939 (32.1 KiB) TX bytes:32939 (32.1 KiB)
rota ip
root@vpnServer:/etc# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
iptables permitem tudo em qualquer lugar
root@vpnServer:/var/log# iptables -nvL
Chain INPUT (policy ACCEPT 129 packets, 21866 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 46 packets, 5360 bytes)
pkts bytes target prot opt in out source destination
por algumas razões, o tcpdump não vê pedidos para o 4.4.4.4. encaminhamento é permitido
root@vpnServer:/var/log# cat /proc/sys/net/ipv4/ip_forward
1
Estou preso nisso. Qualquer ajuda será apreciada.
Tags cisco ipsec strongswan