我有一个与IPsec连接两个networking的问题。 一方面是在另一个带有Debian 8.3的TP-Link路由器上的思科ASA 55xx，后面是NAT中的StrongSwan。 问题也在于我对TP-Link端的NETMAP / SNATnetworking有所了解。 但即使没有这些规则连接也不想build立。 如何debugging连接？
我的configuration（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 然后我检查状态它显示了几分钟，但一两分钟后 – “安全关联（0上，0连接）：”：
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
它看起来像开始阶段1，但无法收到任何答案。 TP-LINK有500个和4500个端口转发到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)
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允许所有的东西
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
由于某些原因，tcpdump没有看到任何对4.4.4.4的请求。 转发是允许的
root@vpnServer:/var/log# cat /proc/sys/net/ipv4/ip_forward 1
我坚持这一点。 任何帮助将不胜感激。