[strongSwan] stongswan tunnel up but child subnets not pinging
christopher kamutumwa
chriskamutumwa at gmail.com
Thu Feb 18 10:54:42 CET 2016
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 <noel at familie-kuntze.de> 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 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
>
>
>
More information about the Users
mailing list