-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Serge,
When you ping, check the traffic counters "ipsec statusall" shows you for the connections. If the output counter (bytes_o) is incremented each ping, your packets go through the tunnel. If it doesn't, it's a routing problem on your side. Taking the error message "ping" gives to you and interpreting it, might help, too. Regards Noel Kuntze On 05.01.2014 22:50, s s wrote: > Hello, > > I made some homework and found out different elements, which may help to > troubleshoot. > >>> This packet was a large packet and was sent as two UDP fragments. > What looked like to be a packet fragmentation, in fact appeared to be two > different CAs sent in the key exchange. > I had 2 CAs in the "cacert" folder due to the coming expiration of one of > them. So I removed the expired one and the packet duplication was solved. > > Now comes to the other issues, which I am unable to resolve. > I tried to switch to the IKE v1. > > The initial authentication is successful: > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[4] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > authentication of 'b...@hmnet.ucp' (myself) with RSA signature successful > > > establishing CHILD_SA karmaIKE2 <<-- this step fails > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 1 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > Examining the other side logs gives: > Jan 5 18:30:45 karma charon: 04[CFG] received proposals: > ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, > ESP:3DES_CBC/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ > Jan 5 18:30:45 karma charon: 04[CFG] configured proposals: > ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, > ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, > ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ > Jan 5 18:30:45 karma charon: 04[IKE] no matching proposal found, sending > NO_PROPOSAL_CHOSEN > > Comparing the security received/configured proposals differs with MODP_2048 > > I found the workaround this issue adding the pfs = no to the conn > configuration: > > conn karmaIKE2 > left=%defaultroute > leftsubnet=10.0.2.0/24 > leftcert=btvm34.hostCert.pem > leftid=b...@hmnet.ucp > right=192.168.4.10 > rightsubnet=192.168.4.0/24 > rightcert=peercerts/karmaY2034.hostCert.pem > rightid=@karma.hmnet.ucp > keyexchange=ikev1 > pfs = no > # keyexchange=ikev2 > # mobike=yes > auto=add > > This allowed to set up a tunnel : > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > 002 "karmaIKE2" #1: initiating Main Mode > 104 "karmaIKE2" #1: STATE_MAIN_I1: initiate > 003 "karmaIKE2" #1: received Vendor ID payload [XAUTH] > 003 "karmaIKE2" #1: received Vendor ID payload [Dead Peer Detection] > 106 "karmaIKE2" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > 002 "karmaIKE2" #1: we have a cert and are sending it upon request > 108 "karmaIKE2" #1: STATE_MAIN_I3: sent MI3, expecting MR3 > 002 "karmaIKE2" #1: Peer ID is ID_FQDN: '@karma.hmnet.ucp' > 002 "karmaIKE2" #1: crl not found > 002 "karmaIKE2" #1: certificate status unknown > 002 "karmaIKE2" #1: ISAKMP SA established > 004 "karmaIKE2" #1: STATE_MAIN_I4: ISAKMP SA established > 002 "karmaIKE2" #2: initiating Quick Mode PUBKEY+ENCRYPT+TUNNEL+UP {using > isakmp#1} > 112 "karmaIKE2" #2: STATE_QUICK_I1: initiate > 002 "karmaIKE2" #2: sent QI2, IPsec SA established {ESP=>0xcf739c9c > <0xca7ad5d1} > 004 "karmaIKE2" #2: STATE_QUICK_I2: sent QI2, IPsec SA established > {ESP=>0xcf739c9c <0xca7ad5d1} > > ipsec statusall > karmaIKE2: %any...%any IKEv1 > karmaIKE2: local: [karma.hmnet.ucp] uses public key authentication > karmaIKE2: cert: "OU=hmnet, CN=karma.hmnet.ucp" > karmaIKE2: remote: [b...@hmnet.ucp] uses public key authentication > karmaIKE2: cert: "OU=testbed, CN=btvm.hmnet.ucp" > karmaIKE2: child: 192.168.4.0/24 === 10.0.2.0/24 TUNNEL > Security Associations (2 up, 0 connecting): > karmaIKE2[8]: ESTABLISHED 16 seconds ago, > 192.168.4.10[karma.ucp-is.com]...192.168.4.87[b...@hmnet.ucp] > karmaIKE2[8]: IKEv1 SPIs: 2175d162c1d066eb_i 1fb55e5a7f044c32_r*, public > key reauthentication in 2 hours > karmaIKE2[8]: IKE proposal: > AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 > karmaIKE2{3}: INSTALLED, TUNNEL, ESP SPIs: cf739c9c_i ca7ad5d1_o > karmaIKE2{3}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in > 45 minutes > karmaIKE2{3}: 192.168.4.0/24 === 10.0.2.0/24 > > Anyway, the routing doesn't work in between the net-net : > > root@bt:/etc/ipsec.d# ping 192.168.4.10 > PING 192.168.4.10 (192.168.4.10) 56(84) bytes of data. > ^C > --- 192.168.4.10 ping statistics --- > 2 packets transmitted, 0 received, 100% packet loss, time 1008ms > > root@bt:/etc/ipsec.d# iptables -L -n -v > Chain INPUT (policy ACCEPT 0 packets, 0 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 > 0 0 ACCEPT all -- eth0 * 192.168.4.0/24 > 10.0.2.0/24 policy match dir in pol ipsec reqid 16389 proto 50 > 0 0 ACCEPT all -- * eth0 10.0.2.0/24 > 192.168.4.0/24 policy match dir out pol ipsec reqid 16389 proto 50 > > root@bt:/etc/ipsec.d# ip xfrm policy > src 10.0.2.0/24 dst 192.168.4.0/24 > dir out priority 2344 > tmpl src 10.0.2.15 dst 192.168.4.10 > proto esp reqid 16389 mode tunnel > src 192.168.4.0/24 dst 10.0.2.0/24 > dir fwd priority 2344 > tmpl src 192.168.4.10 dst 10.0.2.15 > proto esp reqid 16389 mode tunnel > src 192.168.4.0/24 dst 10.0.2.0/24 > dir in priority 2344 > tmpl src 192.168.4.10 dst 10.0.2.15 > proto esp reqid 16389 mode tunnel > > > > If I switch back to the IKE v2 configuration settings removing the remarks > from > # keyexchange=ikev2 > # mobike=yes, > than I am stuck with the initial problem of being unable to authenticate a > tunnel. > > > Is there any way to troubleshoot this? > > Serge > > > > > > >> ----- Original Message ----- >> From: Volker Rümelin >> Sent: 12/31/13 04:25 PM >> To: s s >> Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb >> >>> Hello Volker, >>> >>>> This packet was a large packet and was sent as two UDP fragments. One or >>>> possibly both fragments were >>>> dropped on the route to the other side. >>> Is it possible to handle the packets fragmentation to fix the problem? >>> Unfortunately, the real world situation is such that in the majority of >>> cases it is impossible to intervene on the intermediate router (provider's >>> setup, hot spots etc). >>> Initially this was the reason that we started to store the certificated >>> locally on each side. Otherwise even initial IKE handshake was unsuccessful. >>> >>>> I can see this is still your setup with the NAT router. >>>> you should try to fix the router. >>> There is no possibility to do that. >>> >>> Looking forward to your thoughts and wish you a Happy New Year! >>> Regards, >>> Serge >>> >>> >> >> Hello Serge, >> >> for a fixed site to site tunnel I would complain to my provider, as I >> pay for the service and they have to fix the router if it's broken. >> >> I agree this is not a real option for the road warrior case. >> >> I only have some limited experience with Windows road warriors. If >> ikev2 VPN doesn't work, it's possible to switch back to ikev1 ipsec/l2tp >> VPN. The proprietary ikev1 fragmentation extension >> (http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection and >> search for fragmentation) allows to build up the tunnel and if you >> select a small enough MTU/MRU in the ppp setup, the data packets don't >> get fragmented. You can do the same. I have to admit this is a ugly >> solution, but it works. >> >> I wish you a Happy New Year, >> Volker > > > > > ---- > Hello, > > I am having a persistent problem of being unable to establish a tunnel > between two strongswan hosts > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[3] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > received cert request for "STR4.3CA" > received cert request for unknown ca with keyid > b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 > sending cert request for "STR4.3CA" > authentication of 'STR4.3host.cert' (myself) with RSA signature successful > sending end entity cert "STR4.3host.cert" > establishing CHILD_SA karmaIKE2 > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 1 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 2 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > The status is stuck on "CONNECTING", which never happens: > > root@bt:/etc/ipsec.d# ipsec statusall > > karmaIKE2: 10.0.2.15...192.168.4.10 > karmaIKE2: local: [STR4.3host.cert] uses public key authentication > karmaIKE2: cert: "STR4.3host.cert" > karmaIKE2: remote: [karma.ucp-is.com] uses any authentication > karmaIKE2: cert: "KRM5.1host.cert" > karmaIKE2: child: 10.0.2.0/24 === 192.168.4.0/24 > Security Associations: > karmaIKE2[15]: CONNECTING, > 10.0.2.15[STR4.3host.cert]...192.168.4.10[KRM5.1host.cert] > karmaIKE2[15]: IKE SPIs: 6d2c0e380935a207_i* 518160338263e01f_r > > After 5 rekying attempts, it stops. > > Dec 29 22:23:27 bt charon: 07[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Dec 29 22:23:27 bt charon: 07[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/syslog <== > Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 > Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/daemon.log <== > Dec 29 22:23:31 bt charon: 09[IKE] retransmit 1 of request with message ID 1 > Dec 29 22:23:31 bt charon: 09[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > ==> /var/log/syslog <== > Dec 29 22:23:38 bt charon: 15[IKE] retransmit 2 of request with message ID 1 > Dec 29 22:23:38 bt charon: 15[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > > > The policy for the channel does sets up, but nothing works > > [root@karma strongswan]# ip xfrm policy > src 10.0.2.0/24 dst 192.168.4.0/24 > dir in priority 1859 > tmpl src 192.168.4.87 dst 192.168.4.10 > proto esp reqid 4 mode tunnel > src 192.168.4.0/24 dst 10.0.2.0/24 > dir out priority 1859 > tmpl src 192.168.4.10 dst 192.168.4.87 > proto esp reqid 4 mode tunnel > src 10.0.2.0/24 dst 192.168.4.0/24 > dir fwd priority 1859 > tmpl src 192.168.4.87 dst 192.168.4.10 > proto esp reqid 4 mode tunnel > > > Any hint how to fix it would be highly appreciated, > Regards, > Serge > > > > > > > Is the 4.xx branch compatible with the 5.x one? > I am unable to establish a tunnel in between 2 strongswan hosts one running > the strongSwan U4.3.2/K2.6.38 > and the second strongSwan U5.1.1/K2.6.18-308.16.1.el5PAE > > The configuration is more than classical: net-net > > > conn karmaIKE2 > left=%defaultroute > leftsubnet=10.0.2.0/24 > leftcert=btvm34.hostCert.pem > right=192.168.4.10 > rightsubnet=192.168.4.0/24 > rightcert=peercerts/karmaY2034.hostCert.pem > keyexchange=ikev2 > mobike=yes > auto=add > > > root@bt:/etc/ipsec.d# ipsec up karmaIKE2 > initiating IKE_SA karmaIKE2[1] to 192.168.4.10 > generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] > sending packet: from 10.0.2.15[500] to 192.168.4.10[500] > received packet: from 192.168.4.10[500] to 10.0.2.15[500] > parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ > N(MULT_AUTH) ] > local host is behind NAT, sending keep alives > received cert request for "STR4.3CA" > received cert request for unknown ca with keyid > b0:31:27:8b:2e:4b:cd:53:6d:c4:a7:fb:e9:56:1b:9f:34:cc:71:a7 > sending cert request for "STR4.3CA" > authentication of 'STR4.3host.cert' (myself) with RSA signature successful > sending end entity cert "STR4.3host.cert" > establishing CHILD_SA karmaIKE2 > generating IKE_AUTH request 1 [ IDi CERT CERTREQ IDr AUTH SA TSi TSr > N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > retransmit 1 of request with message ID 1 > sending packet: from 10.0.2.15[4500] to 192.168.4.10[4500] > > > But the tunnel > > root@bt:/etc/ipsec.d# ipsec statusall > 000 Status of IKEv1 pluto daemon (strongSwan 4.3.2): > 000 interface lo/lo ::1:500 > 000 interface lo/lo 127.0.0.1:500 > 000 interface eth0/eth0 10.0.2.15:500 > 000 %myid = (none) > 000 loaded plugins: curl ldap random pubkey openssl hmac gmp > 000 debug options: none > 000 > Status of IKEv2 charon daemon (strongSwan 4.3.2): > uptime: 7 minutes, since Dec 23 10:27:59 2013 > worker threads: 9 idle of 16, job queue load: 0, scheduled events: 1 > loaded plugins: curl ldap random x509 pubkey openssl xcbc hmac agent gmp > kernel-netlink stroke updown eapidentity eapmd5 eapgtc eapaka eapmschapv2 > Listening IP addresses: > 10.0.2.15 > Connections: > karmaIKE2: 10.0.2.15...192.168.4.10 > karmaIKE2: local: [STR4.3host.cert] uses public key authentication > karmaIKE2: cert: "STR4.3host.cert" > karmaIKE2: remote: [STR5.1host.cert] uses any authentication > karmaIKE2: cert: STR5.1host.cert" > karmaIKE2: child: 10.0.2.0/24 === 0.0.0.0/0 > Security Associations: > karmaIKE2[1]: CREATED, > 10.0.2.15[STR4.3host.cert]...192.168.4.10[STR5.1host.cert] > karmaIKE2[1]: IKE SPIs: 3483591a1d20afaf_i* 0000000000000000_r > karmaIKE2[1]: IKE proposal: > AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 > > The logs show > Dec 23 10:32:01 bt charon: 16[IKE] establishing CHILD_SA karmaIKE2 > Dec 23 10:32:01 bt charon: 16[ENC] generating IKE_AUTH request 1 [ IDi CERT > CERTREQ IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) ] > Dec 23 10:32:01 bt charon: 16[NET] sending packet: from 10.0.2.15[4500] to > 192.168.4.10[4500] > > But this child tunnel could not be setup. > Which result in the inability to reach the hosts and the the networks behind > them. > > I am still running the routing problem between the same two strongSwan > U5.1.1/K2.6.18-308.16.1.el5PAE hosts, one of them being behind the NATed > gateway and unable to reach it through the tunnel, which apparently doesn't > route the packets. > > Any help would be much appreciated. > Rgds, > Serge > > > ---- > > Is standard Centos 5.x kernel 2.6.18-308.16.1.el5PAE compatible at all with > [root@ ~]# strongswan version > Linux strongSwan U5.1.1/K2.6.18-308.16.1.el5PAE > > We are unable to fix the routing problem. When the remote host is behind the > NAT'ed provider's server, it can not be reached at all: > > > msc-hmnet{12}: 192.168.4.0/24 === 192.168.3.0/24 > [root@karma ~]# ping 192.168.3.56 > PING 192.168.3.56 (192.168.3.56) 56(84) bytes of data. > > --- 192.168.3.56 ping statistics --- > 2 packets transmitted, 0 received, 100% packet loss, time 999ms > > > > > ---- >>> But out of the 2 tunnels only 1 is reachable. The other one doesn't ping. >> Does that tunnel work if you don't establish the other one? > No, it doesn't. > Besides, once the 192.168.3.0/24 host is behind the NAT'ed gateway, neither > of the tunnels work. > >> Also, I'd try to disable IPComp for testing. There seems to be an issue >> with IPcomp on some kernels in some scenarios. > What an IPComp is and how to disable it ? > > We use a standard Centos 5.x kernel > 2.6.18-308.16.1.el5PAE #1 SMP Tue Oct 2 22:49:17 EDT 2012 i686 i686 i386 > GNU/Linux > > Could anyone help to troubleshoot the problem and resolve the issue? > > Rgds, > Serge > > _______________________________________________ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSydSzAAoJEDg5KY9j7GZYgNYQAJJDDbE4v6y0fTVdEno4/F5I 2PgURqSGisC/xq0yrI8K6MHY+dN29mGv7VRboGbtU3sd1LhfiNb2dFHougtmXoYc oEErCyboAjXt9NDprOuDzgSSgEEU9LpUp10r50K26RszMR5GA36TAiyurj7PHmHw zbvi9xcQAtL58XUiZ7GMJv1wijDtnxiB8uCxXjNTkwylGnqFO3Ic7usPB0ObRZJt htE8Yowbc0viPrOQfne906odd+tqMhf71kTKI5fXzbloEPulwXu3Yc4wSxTsZ1wN nKndvPF6ibB9q5vJ1UjPbKDUb9YeyoVKq84+lRirkdpYUWsiqeR9X3tktiNKiwv3 hDJmgDJk3mjLRp8eSUetE4qTgyJd1nr3+SB8YUuazd5ig0aCoXci5bWe0nJbaweu nU4pSSD35kUKAqPtm4PeWHuUKKoLkyKwf4z8k6bKP2SoEuNk+0ax9QCks/2jo71O PUFIea6xEErB7xRe55GzbbrxZb5cviXvmK8BLt2g0WSNml0SgLvVnYFACO7T8hcR YFDtMez+AEM6Bk/rcMgVO6/kOL13Ssy81S/jdS4TtkL+BW405122I5pCcRJoEUre 86obyXW6C3Z44myE8CRW9XgqK/84ml4tf9MdmlciLZBQEUEaxbUMFYNvR+tr6zjL llbXG2kORpFtiFLUAAy9 =vWL2 -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users