[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
s s
y52 at europe.com
Sun Jan 5 23:30:33 CET 2014
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 at 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 at 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[btvm at hmnet.ucp]
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 at 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 at 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 at bt:~# ipsec statusall
000 "karmaIKE2": 10.0.2.0/24===10.0.2.15[btvm at hmnet.ucp]---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" esp.c51580dd at 192.168.4.10 (420 bytes, 4s ago) esp.7789acc8 at 10.0.2.15 (0 bytes); tunnel
more pings:
root at 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" esp.c51580dd at 192.168.4.10 (756 bytes, 7s ago) esp.7789acc8 at 10.0.2.15 (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, users at lists.strongswan.org
> 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 at 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 'btvm at 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=btvm at 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 at 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: [btvm at 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[btvm at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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-----
More information about the Users
mailing list