[strongSwan] strongswan-5.1.1 with 4.xx, tunnel pb
Noel Kuntze
noel at familie-kuntze.de
Sun Jan 5 22:55:00 CET 2014
-----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