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 '[email protected]' (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 [email protected] right=192.168.4.10 rightsubnet=192.168.4.0/24 rightcert=peercerts/karmaY2034.hostCert.pem [email protected] 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: [[email protected]] 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[[email protected]] 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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
