Hi does this mean if I flush my iptables and routing tables strongswan willroute and write firewall.and how can I tell that?<span></span><br><br>On Tuesday, 16 February 2016, Noel Kuntze <<a href="mailto:noel@familie-kuntze.de">noel@familie-kuntze.de</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">> 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?<br>
<br>
> Security Associations (1 up, 0 connecting):<br>
> MTN[10]: ESTABLISHED 2 minutes ago, 185.3.95.94[185.3.95.94]...41.223.117.190[41.223.117.190]<br>
> MTN[10]: IKEv1 SPIs: 28e33873f54aaaff_i* 6d3ab411e92b6c05_r, pre-shared key reauthentication in 7 hours<br>
> MTN[10]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024<br>
> MTN[10]: Tasks queued: QUICK_MODE<br>
> MTN[10]: Tasks active: MODE_CONFIG<br>
The tunnel is not actually up. Only the IKE_SA is. The IKE_SA does not transport traffic, CHILD_SAs do that.<br>
<br>
> [root@li788-94 strongswan]# iptables -nvL<br>
Don't show `iptables -L` or something. Always show `iptables-save`. `iptables -L` only<br>
shows the *filter table. `iptables-save` shows all tables. It's also more readable.<br>
<br>
><br>
> conn %default<br>
> ikelifetime=28800s<br>
> keylife=200s<br>
> rekeymargin=300<br>
> keyingtries=1<br>
> keyexchange=ikev1<br>
> ike=aes128-sha1-modp1024-diffie-hellman group 2<br>
><br>
> esp=3des-sha1<br>
> ike=3des-sha1-modp1024<br>
> mobike=yes<br>
> leftikeport=4500<br>
> rightikeport=4500<br>
> authby=secret<br>
> conn MTN<br>
> type=tunnel<br>
> left=185.3.95.94<br>
> # left=%defaultroute<br>
> # leftcert=client.cert<br>
> # authby=secret<br>
> leftsubnet=<a href="http://192.168.200.172/17" target="_blank">192.168.200.172/17</a><br>
> leftsourceip=%config<br>
> leftfirewall=yes<br>
> right=41.223.117.190<br>
> #rightid=41.223.117.190<br>
> rightsubnet=<a href="http://172.25.48.36/32,172.25.48.43/32" target="_blank">172.25.48.36/32,172.25.48.43/32</a><br>
> # rightsubnet=<a href="http://172.25.48.36/16" target="_blank">172.25.48.36/16</a><br>
> # rightsubnet=172.25.48.36<br>
> auto=start<br>
> rightsubnet=<a href="http://172.25.48.36/32,172.25.48.43/32" target="_blank">172.25.48.36/32,172.25.48.43/32</a><br>
IKEv1 does not support several subnets in a single CHILD_SA. You need to specify<br>
a CHILD_SA per subnet pair.<br>
<br>
> ike=aes128-sha1-modp1024-diffie-hellman group 2<br>
That line is formatted wrong. "-diffie-hellman group 2" is invalid.<br>
Read the man page.<br>
<br>
> conn %default<br>
> ike=aes128-sha1-modp1024-diffie-hellman group 2<br>
> [...]<br>
> ike=3des-sha1-modp1024<br>
Don't declare options multiple times in a conn section.<br>
<br>
> conn MTN<br>
> type=tunnel<br>
> left=185.3.95.94<br>
> # left=%defaultroute<br>
Indent your config correctly.<br>
<br>
> ip route add 172.25.48.43 via 41.223.117.190 dev eth0 proto static src 192.168.200.177<br>
> ip route add 172.25.48.36 via 41.223.117.190 dev eth0 proto static src 192.168.200.177<br>
><br>
> 172.25.48.36 via 41.223.117.190 dev eth0 proto static src 192.168.200.177<br>
><br>
> ip route add 41.223.117.190 dev eth0<br>
><br>
> ip route add 41.223.117.190 via 185.3.95.1 dev eth0:1<br>
><br>
> ip route add <a href="http://41.223.117.190/32" target="_blank">41.223.117.190/32</a> via 185.3.95.1 dev eth0<br>
strongSwan does the routing for you. Don't install routes yourself.<br>
<br>
> tup: Starting Openswan IPsec U2.6.32/K4.4.0-x86_64-linode63...<br>
> Feb 14 16:04:24 li788-94 ipsec_setup: Using NETKEY(XFRM) stack<br>
What's up with that? strongSwan is not openswan.<br>
<br>
> 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]<br>
> Feb 16 09:47:05 li788-94 charon: 03[IKE] scheduling reauthentication in 28221s<br>
> Feb 16 09:47:05 li788-94 charon: 03[IKE] maximum IKE_SA lifetime 28521s<br>
> Feb 16 09:47:05 li788-94 charon: 03[ENC] generating TRANSACTION request 689769898 [ HASH CPRQ(ADDR DNS) ]<br>
> 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)<br>
> Feb 16 09:47:09 li788-94 charon: 15[IKE] sending retransmit 1 of request message ID 689769898, seq 4<br>
> 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)<br>
> Feb 16 09:47:16 li788-94 charon: 16[IKE] sending retransmit 2 of request message ID 689769898, seq 4<br>
> 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)<br>
> Feb 16 09:47:29 li788-94 charon: 04[IKE] sending retransmit 3 of request message ID 689769898, seq 4<br>
> 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)<br>
> Feb 16 09:47:53 li788-94 charon: 01[IKE] sending retransmit 4 of request message ID 689769898, seq 4<br>
> 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)<br>
> Feb 16 09:48:35 li788-94 charon: 11[IKE] sending retransmit 5 of request message ID 689769898, seq 4<br>
> 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)<br>
> 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)<br>
> Feb 16 09:49:28 li788-94 charon: 03[ENC] parsed QUICK_MODE request 959964764 [ HASH SA No ID ID ]<br>
> Feb 16 09:49:28 li788-94 charon: 03[IKE] received 28800s lifetime, configured 200s<br>
> Feb 16 09:49:28 li788-94 charon: 03[IKE] received 1843200000 lifebytes, configured 0<br>
> Feb 16 09:49:28 li788-94 charon: 03[ENC] generating QUICK_MODE response 959964764 [ HASH SA No ID ID ]<br>
> 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)<br>
> 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)<br>
> Feb 16 09:49:28 li788-94 charon: 02[ENC] parsed QUICK_MODE request 959964764 [ HASH ]<br>
> Feb 16 09:49:28 li788-94 charon: 02[IKE] CHILD_SA MTN{1} established with SPIs cead478f_i 1c001196_o and TS <a href="http://192.168.200.177/32" target="_blank">192.168.200.177/32</a> === <a href="http://172.25.48.43/32" target="_blank">172.25.48.43/32</a><br>
> Feb 16 09:49:28 li788-94 vpn: + 41.223.117.190 <a href="http://172.25.48.43/32" target="_blank">172.25.48.43/32</a> == 41.223.117.190 -- 185.3.95.94 == <a href="http://192.168.200.177/32" target="_blank">192.168.200.177/32</a><br>
> Feb 16 09:49:50 li788-94 charon: 13[IKE] giving up after 5 retransmits<br>
Go and find out why there are retransmits. Look at the logs of the other side.<br>
I think it's possible that there's some issue with the other side.<br>
<br>
> iptables -I OUTPUT -o eth0 -p all -j ACCEPT<br>
Filtering output is pretty useless in most cases, and so is specifying -p all.<br>
Specifying -p all does not have any effect except makes you take more time to type the command and take up some bytes.<br>
<br>
--<br>
<br>
Mit freundlichen Grüßen/Kind Regards,<br>
Noel Kuntze<br>
<br>
GPG Key ID: 0x63EC6658<br>
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658<br>
<br>
<br>
</blockquote>