Re: [strongSwan] strongSwan, swanctl and systemd]
Hi John, We have some definite plans to introduce native systemd support Any chance this can be a compile-time selection for those of us who don't use systemd? Definitely; that systemd specific IKE daemon will be completely optional, and not the default. ipsec.conf based configuration and the traditional charon daemon won't go away in the foreseeable future. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] StrongSwan and Android
Hello- After much searching on the internet I am looking for a definitive answer from the source. I have successfully configured iOS devices to VPN into my StrongSwan test environment in Amazon. I have also gotten the StrongSwan client to work on Android 4.4.2 (which tells me my certificate creation is good for both sides). My question is if there is any way to have Android clients connect with the native IPSec client in Android? When in the native IPsec client in Android it will not let me pick the installed certificate that the StrongSwan client can see just fine. Thank you for your time. Alex ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] IKE_SA reauth failed with dual link.
Hello all, I have 2 gateways running Linux strongSwan U4.3.5/K2.6.32-526 configured for IKEv2, net-to-net with MOBIKE enabled. Gateway-A, the initiator, has 2 links. Gateway-B the responder, has only one link. These are the IP addresses. gateway-A_link1 = 172.19.78.72 gateway-A_link2 = 10.5.102.102 gateway-B_link1 = 192.168.10.10 Gateway-A uses both links, alternatively, as default link (depending of its location). MOBIKE works beautifully when switching links. Gateway-A can only reach gateway-B using the default route. The problem I'm observing is that if IKE_SA is established on one of gateway-A's link and the link switches before IKE_REAUTH starts, StrongSwan tries (and fails) to initiate the new IKE_SA using the IP address of the initial link. It doesn't matter which link starts, it happens regarding of the direction of the link switch. I also tested another machine in place of gateway-A, running Linux strongSwan U5.1.2/K3.4.11-527, with the same result. Here is an example. The tunnel initially established while gateway-A_link2 was the default route. Default route changed at around 16:00, making gateway-A_link1 the default route. Jul 7 16:22:34 gateway-A charon: 09[IKE] queueing IKE_REAUTH task Jul 7 16:22:34 gateway-A charon: 09[IKE] activating new tasks Jul 7 16:22:34 gateway-A charon: 09[IKE] activating IKE_REAUTH task Jul 7 16:22:34 gateway-A charon: 09[IKE] deleting IKE_SA Net-Net[1] between 172.19.78.72[gateway-A]...192.168.10.10[gateway-B] Jul 7 16:22:34 gateway-A charon: 09[IKE] IKE_SA Net-Net[1] state change: ESTABLISHED = DELETING Jul 7 16:22:34 gateway-A charon: 09[IKE] sending DELETE for IKE_SA Net-Net[1] Jul 7 16:22:34 gateway-A charon: 09[NET] sending packet: from 172.19.78.72[4500] to 192.168.10.10[4500] Jul 7 16:22:34 gateway-A charon: 05[NET] sending packet: from 172.19.78.72[4500] to 192.168.10.10[4500] Jul 7 16:22:34 gateway-A charon: 06[NET] received packet: from 192.168.10.10[4500] to 172.19.78.72[4500] Jul 7 16:22:34 gateway-A charon: 06[NET] waiting for data on raw sockets Jul 7 16:22:34 gateway-A charon: 08[NET] received packet: from 192.168.10.10[4500] to 172.19.78.72[4500] Jul 7 16:22:34 gateway-A charon: 08[IKE] IKE_SA deleted Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_INIT task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_NATD task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CERT_PRE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_AUTHENTICATE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CERT_POST task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_CONFIG task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_AUTH_LIFETIME task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing IKE_MOBIKE task Jul 7 16:22:34 gateway-A charon: 08[IKE] queueing CHILD_CREATE task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating new tasks Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_INIT task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_NATD task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_CERT_PRE task Jul 7 16:22:34 gateway-A charon: 08[IKE] activating IKE_AUTHENTICATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_CERT_POST task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_CONFIG task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating CHILD_CREATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_AUTH_LIFETIME task Jul 7 16:22:35 gateway-A charon: 08[IKE] activating IKE_MOBIKE task Jul 7 16:22:35 gateway-A charon: 08[IKE] initiating IKE_SA Net-Net[2] to 192.168.10.10 Jul 7 16:22:35 gateway-A charon: 08[IKE] IKE_SA Net-Net[2] state change: CREATED = CONNECTING Jul 7 16:22:35 gateway-A charon: 08[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:35 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:35 gateway-A charon: 05[NET] error writing to socket: Operation not permitted Jul 7 16:22:35 gateway-A charon: 08[IKE] queueing CHILD_CREATE task Jul 7 16:22:35 gateway-A charon: 08[IKE] delaying task initiation, exchange in progress Jul 7 16:22:35 gateway-A charon: 08[IKE] IKE_SA Net-Net[1] state change: DELETING = DESTROYING Jul 7 16:22:39 gateway-A charon: 08[IKE] retransmit 1 of request with message ID 0 Jul 7 16:22:39 gateway-A charon: 08[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:39 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:39 gateway-A charon: 05[NET] error writing to socket: Operation not permitted Jul 7 16:22:46 gateway-A charon: 09[IKE] retransmit 2 of request with message ID 0 Jul 7 16:22:46 gateway-A charon: 09[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul 7 16:22:46 gateway-A charon: 05[NET] sending packet: from 10.5.102.102[500] to 192.168.10.10[500] Jul
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Friday, July 11, 2014 03:04:27 PM +0200 Martin Willi mar...@strongswan.org wrote: ipsec_starter[3318]: notifying watcher failed: Broken pipe I got: no trusted RSA public key found for NAME Btw, I don't think these two issues are directly related. While asynchronous IPC operation is affected, starter actually doesn't use that. Probably something else is wrong with that key: trust chain validation, certificate exchange, or loading trusted certificates. Your log might have more details. was there a change in 5.2 about charon asking for the certificate of the peer? I can establish a connection when I add leftsendcert=yes to the configuration of my roadwarrior. If I don't add it I get a connection with 5.1.3 but on 5.2 I get: [IKE] no trusted RSA public key found for 'C=DE, O=' in the log of the server. Best Regards Dirk pgpKoigv8o7Ll.pgp Description: PGP signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Dirk, was there a change in 5.2 about charon asking for the certificate of the peer? I can establish a connection when I add leftsendcert=yes to the configuration of my roadwarrior. None that I'm aware of. leftsendcert=ifasked was the policy ever since. If I don't add it I get a connection with 5.1.3 but on 5.2 I get: [IKE] no trusted RSA public key found for 'C=DE, O=' in the log of the server. As the default policy is ifasked, this most likely implies that your server does not send a certificate request. By default certificate requests are sent; what is your rightsendcert setting on the server? charon logs the certificates and certificate requests sent/received during the exchange, that should help in analyzing what is missing. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
With this connection active it doesn't matter if I set rightsendcert to ifasked or yes in the default section or the specific connection section of my linux roadwarrior. I can't connect because charon doesn't send a certificate request. If I remove the conn section for win 7 eap, I can connect. Certificate requests are sent very early in the IKE negotiation. As a responder, it is sent in the first IKE_SA_INIT response. At this stage, charon can not reliably select a configuration, as no peer identities or authentication methods are known yet. If no IP address selectors are in place (using left/right), usually just the first matching configuration is used. This probably is the win7 connection in your configuration. I set rightsendcert = never as mentioned in the wiki page While this recommendation is fine if you handle Windows clients only, for mixed setups it can result in these issues. I'll add a note to the wiki. If you can't apply IP based selectors to your configuration using left/right, you should consider removing the rightsendcert option. Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Tuesday, July 15, 2014 01:52:45 PM +0200 Martin Willi mar...@strongswan.org wrote: With this connection active it doesn't matter if I set rightsendcert to ifasked or yes in the default section or the specific connection section of my linux roadwarrior. I can't connect because charon doesn't send a certificate request. If I remove the conn section for win 7 eap, I can connect. Certificate requests are sent very early in the IKE negotiation. As a responder, it is sent in the first IKE_SA_INIT response. At this stage, charon can not reliably select a configuration, as no peer identities or authentication methods are known yet. If no IP address selectors are in place (using left/right), usually just the first matching configuration is used. This probably is the win7 connection in your configuration. ah ok I see I set rightsendcert = never as mentioned in the wiki page While this recommendation is fine if you handle Windows clients only, for mixed setups it can result in these issues. I'll add a note to the wiki. If you can't apply IP based selectors to your configuration using left/right, you should consider removing the rightsendcert option. Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. It's probably the new parser. Checking the logs on the gateway running 5.1.3 I discovered that the rightsendcert = never wasn't honoured for any connection. Windows 7 eap clients received a cert request too. So your suggestion to remove this option from our config should be no problem. Thanks Dirk ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] How to overcome the dpd re-transmission task for IKE_DELETE task?
While testing ipsec ,it seems that with “ipsec stroke conn name”, IKE_DELETE task is being queued on eNB but delayed by the ongoing dpd re-transmission task. Is there any other way to administratively shutdown the connection, overriding the dpd re-transmission task? -- Regards Nandagopal ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
