Here is the status of the output counters from both sides. Could anything be concluded? Why the IKEv2 doesn't work under the same conditions? Serge
[root@karma strongswan]# ping 10.0.2.15 PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data. --- 10.0.2.15 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 2999ms [root@karma strongswan]# strongswan statusall karmaIKE2: %any...%any IKEv1 karmaIKE2: child: 192.168.4.0/24 === 10.0.2.0/24 TUNNEL Security Associations (2 up, 0 connecting): karmaIKE2[5]: ESTABLISHED 2 minutes ago, 192.168.4.10[karma.hmnet.ucp]...192.168.4.87[[email protected]] karmaIKE2[5]: IKEv1 SPIs: 714776a1942be636_i 69cdaed984ddd6db_r*, public key reauthentication in 2 hours karmaIKE2[5]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 karmaIKE2{4}: INSTALLED, TUNNEL, ESP SPIs: c51580dd_i 7789acc8_o karmaIKE2{4}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 608 bytes_o (4 pkts, 7s ago), rekeying in 43 minutes karmaIKE2{4}: 192.168.4.0/24 === 10.0.2.0/24 [root@karma strongswan]# ping 10.0.2.15 PING 10.0.2.15 (10.0.2.15) 56(84) bytes of data. --- 10.0.2.15 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3000ms karmaIKE2{4}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 1216 bytes_o (8 pkts, 2s ago), rekeying in 41 minutes karmaIKE2{4}: 192.168.4.0/24 === 10.0.2.0/24 root@bt:~# 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 999ms root@bt:~# ipsec statusall 000 "karmaIKE2": 10.0.2.0/24===10.0.2.15[[email protected]]---10.0.2.2...192.168.4.10[@karma.hmnet.ucp]===192.168.4.0/24; erouted; eroute owner: #2 000 "karmaIKE2": ike_life: 10800s; ipsec_life: 3600s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 3 000 "karmaIKE2": policy: PUBKEY+ENCRYPT+TUNNEL+UP; prio: 24,24; interface: eth0; 000 "karmaIKE2": newest ISAKMP SA: #1; newest IPsec SA: #2; 000 "karmaIKE2": IKE proposal: AES_CBC_128/HMAC_SHA1/MODP_2048 000 "karmaIKE2": ESP proposal: AES_CBC_128/HMAC_SHA1/<N/A> 000 000 #2: "karmaIKE2" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2573s; newest IPSEC; eroute owner 000 #2: "karmaIKE2" [email protected] (420 bytes, 4s ago) [email protected] (0 bytes); tunnel more pings: root@bt:~# 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 --- 4 packets transmitted, 0 received, 100% packet loss, time 3008ms 000 #2: "karmaIKE2" STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2458s; newest IPSEC; eroute owner 000 #2: "karmaIKE2" [email protected] (756 bytes, 7s ago) [email protected] (0 bytes); tunnel 000 #1: "karmaIKE2" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 9416s; newest ISAKMP > ----- Original Message ----- > From: Noel Kuntze > Sent: 01/05/14 10:55 PM > To: s s, [email protected] > Subject: Re: [strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb > > -----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 '[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 > > -----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 [email protected] https://lists.strongswan.org/mailman/listinfo/users
