Hi does this mean if I flush my iptables and routing tables strongswan will route and rewrite firwall? ive done all changes but still no joy
On Tuesday, 16 February 2016, Noel Kuntze <[email protected]> wrote: > > 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@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 > > > _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
