[strongSwan] stongswan tunnel up but child subnets not pinging

Tue Feb 16 17:01:03 CET 2016

> hello i managed to install strongswan and managed to establish a connection to remote partner but child subnets are not pinging each other what could be the problem?

> Security Associations (1 up, 0 connecting):
>          MTN[10]: ESTABLISHED 2 minutes ago, 185.3.95.94[185.3.95.94]...41.223.117.190[41.223.117.190]
>          MTN[10]: IKEv1 SPIs: 28e33873f54aaaff_i* 6d3ab411e92b6c05_r, pre-shared key reauthentication in 7 hours
>          MTN[10]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>          MTN[10]: Tasks queued: QUICK_MODE
>          MTN[10]: Tasks active: MODE_CONFIG
The tunnel is not actually up. Only the IKE_SA is. The IKE_SA does not transport traffic, CHILD_SAs do that.

> [root at li788-94 strongswan]# iptables -nvL
Don't show `iptables -L` or something. Always show `iptables-save`. `iptables -L` only
shows the *filter table. `iptables-save` shows all tables. It's also more readable.

>
> conn %default
>         ikelifetime=28800s
>         keylife=200s
>         rekeymargin=300
>         keyingtries=1
>         keyexchange=ikev1
>         ike=aes128-sha1-modp1024-diffie-hellman group 2
>
>         esp=3des-sha1
>         ike=3des-sha1-modp1024
>         mobike=yes
>         leftikeport=4500
>         rightikeport=4500
>         authby=secret
>  conn MTN
>   type=tunnel
>     left=185.3.95.94
>     # left=%defaultroute
>     # leftcert=client.cert
>     #     authby=secret
>     leftsubnet=192.168.200.172/17
>     leftsourceip=%config
>      leftfirewall=yes
>      right=41.223.117.190
>      #rightid=41.223.117.190
>     rightsubnet=172.25.48.36/32,172.25.48.43/32
>      #      rightsubnet=172.25.48.36/16
>      #  rightsubnet=172.25.48.36
>    auto=start
>     rightsubnet=172.25.48.36/32,172.25.48.43/32
IKEv1 does not support several subnets in a single CHILD_SA. You need to specify
a CHILD_SA per subnet pair.

>         ike=aes128-sha1-modp1024-diffie-hellman group 2
That line is formatted wrong. "-diffie-hellman group 2" is invalid.
Read the man page.

> conn %default
>         ike=aes128-sha1-modp1024-diffie-hellman group 2
> [...]
>         ike=3des-sha1-modp1024
Don't declare options multiple times in a conn section.

>  conn MTN
>   type=tunnel
>     left=185.3.95.94
>     # left=%defaultroute
Indent your config correctly.

> ip route add 172.25.48.43 via 41.223.117.190 dev eth0 proto static src 192.168.200.177
> ip route add 172.25.48.36 via 41.223.117.190 dev eth0 proto static src 192.168.200.177
>
> 172.25.48.36 via 41.223.117.190 dev eth0 proto static src 192.168.200.177
>
> ip route add 41.223.117.190 dev eth0
>
> ip route add 41.223.117.190 via 185.3.95.1 dev eth0:1
>
> ip route add 41.223.117.190/32 via 185.3.95.1 dev eth0
strongSwan does the routing for you. Don't install routes yourself.

> tup: Starting Openswan IPsec U2.6.32/K4.4.0-x86_64-linode63...
> Feb 14 16:04:24 li788-94 ipsec_setup: Using NETKEY(XFRM) stack
What's up with that? strongSwan is not openswan.

> Feb 16 09:47:05 li788-94 charon: 03[IKE] IKE_SA MTN[11] established between 185.3.95.94[185.3.95.94]...41.223.117.190[41.223.117.190]
> Feb 16 09:47:05 li788-94 charon: 03[IKE] scheduling reauthentication in 28221s
> Feb 16 09:47:05 li788-94 charon: 03[IKE] maximum IKE_SA lifetime 28521s
> Feb 16 09:47:05 li788-94 charon: 03[ENC] generating TRANSACTION request 689769898 [ HASH CPRQ(ADDR DNS) ]
> Feb 16 09:47:05 li788-94 charon: 03[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:47:09 li788-94 charon: 15[IKE] sending retransmit 1 of request message ID 689769898, seq 4
> Feb 16 09:47:09 li788-94 charon: 15[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:47:16 li788-94 charon: 16[IKE] sending retransmit 2 of request message ID 689769898, seq 4
> Feb 16 09:47:16 li788-94 charon: 16[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:47:29 li788-94 charon: 04[IKE] sending retransmit 3 of request message ID 689769898, seq 4
> Feb 16 09:47:29 li788-94 charon: 04[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:47:53 li788-94 charon: 01[IKE] sending retransmit 4 of request message ID 689769898, seq 4
> Feb 16 09:47:53 li788-94 charon: 01[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:48:35 li788-94 charon: 11[IKE] sending retransmit 5 of request message ID 689769898, seq 4
> Feb 16 09:48:35 li788-94 charon: 11[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (76 bytes)
> Feb 16 09:49:28 li788-94 charon: 03[NET] received packet: from 41.223.117.190[4500] to 185.3.95.94[4500] (164 bytes)
> Feb 16 09:49:28 li788-94 charon: 03[ENC] parsed QUICK_MODE request 959964764 [ HASH SA No ID ID ]
> Feb 16 09:49:28 li788-94 charon: 03[IKE] received 28800s lifetime, configured 200s
> Feb 16 09:49:28 li788-94 charon: 03[IKE] received 1843200000 lifebytes, configured 0
> Feb 16 09:49:28 li788-94 charon: 03[ENC] generating QUICK_MODE response 959964764 [ HASH SA No ID ID ]
> Feb 16 09:49:28 li788-94 charon: 03[NET] sending packet: from 185.3.95.94[4500] to 41.223.117.190[4500] (180 bytes)
> Feb 16 09:49:28 li788-94 charon: 02[NET] received packet: from 41.223.117.190[4500] to 185.3.95.94[4500] (52 bytes)
> Feb 16 09:49:28 li788-94 charon: 02[ENC] parsed QUICK_MODE request 959964764 [ HASH ]
> Feb 16 09:49:28 li788-94 charon: 02[IKE] CHILD_SA MTN{1} established with SPIs cead478f_i 1c001196_o and TS 192.168.200.177/32 === 172.25.48.43/32
> Feb 16 09:49:28 li788-94 vpn: + 41.223.117.190 172.25.48.43/32 == 41.223.117.190 -- 185.3.95.94 == 192.168.200.177/32
> Feb 16 09:49:50 li788-94 charon: 13[IKE] giving up after 5 retransmits
Go and find out why there are retransmits. Look at the logs of the other side.
I think it's possible that there's some issue with the other side.

> iptables -I OUTPUT -o eth0 -p all  -j ACCEPT
Filtering output is pretty useless in most cases, and so is specifying -p all.
Specifying -p all does not have any effect except makes you take more time to type the command and take up some bytes.

-- 

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20160216/c887b70e/attachment.pgp>