Re: [strongSwan] Kernel-netlink issue
Hi Vivek, Now in this Scenario when the stack has exhausted the Max. No. of retries and the SA is still not established, How can we make the stack recover. i.e.when the problem is fixed(destination becomes reachable), how can we make the stack to retry SA establishment. You can set 'keyingtries = %forever' for that connection in ipsec.conf then charon will start the initiation anew after it reached the maximum number of retransmissions. This setting is only relevant for the initiation of an IKE SA, though. If you want your connection to stay up, you will also want to activate DPD by adding 'dpdaction = restart' and most likely 'dpddelay = time' to the config. Regards, Tobias -- == Tobias Brunner tob...@strongswan.org strongSwan - the Linux VPN Solution! http://www.strongswan.org == ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi, 1. I was going through the update SA code, I figured out that the replay data for an SA is fetched separately from the other SA data, however, while adding the updated SA replay value is sent with other entries. What is the reason for this discrepancy. That's due to a limitation of the XFRM API the kernel provides. Unfortunately, the sequence numbers are not included in the response to a XFRM_MSG_GETSA request. These are therefore fetched using a separate XFRM_MSG_GETAE request. On the other hand, the kernel accepts the sequence numbers as part of an XFRM_MSG_NEWSA or XFRM_MSG_UPDSA request. 2. We did not find the query_sa function called from any place in the code, is this function redundtant. It is and it was removed in 4.2.9. 3. Once IKE stack detects that it is behinf NAT, does it still accept packets at port 500. Yes. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi Martin , I went through the stronswan code to understand the IKE_SA and CHILD_SA creation . While going through the code I came across acquire function. The comments for the function indicate that it processes the trigger from the kernel for creation of CHILD_SAs. 1. Is it the only mechanism through which the CHILD_SAs can be created ( i.e through the acquire function, trigger coming from the kernel based on policies installed )? 2. The function also mentioned that the IKE_SA creation can also be triggered through the acquire function sometimes. What are the scenarios under which the IKE_SA creation can be triggered from the kernel? I would highly appretiate your help on these issues. Looking forward for a reply. Thanks, Vivek On 7/6/09, vivek bairathi bairathi.vi...@gmail.com wrote: Hi, Thanks for your help. I still have a doubt that who initiates the IKE SA and CHILD SA. 1. Is it kernel who initiates both? 2. Or Kernel just initiates the CHILD SA (through acquire() function as per the SPD) and the IKE SA is initiated/triggered by reading the ipsec.conf file from which he knows the local and remote IP addresses? 3. If I have asked the wrong question or have wrongly understood your stack code then please do explain me how an IKE SA and CHILD SA is initiated or triggered in your stack? Thank you. Regards, Vivek On 7/2/09, vivek bairathi bairathi.vi...@gmail.com wrote: Hi Martin, Thanks for your help. The problem is that we have a propritary implementaion of the IP stack in micro engine whose development is in assembly language. As per what you have suggested, I think it would make sense that we let the kernel interface remain as is ( just change address family of the sockets with compatiple ones ) and let another process sniff these messages and provide an adpater interface with the network processor/micro engine. This adapter would then provide all required interfaces to the strongswan What are your thoughts on the same ? Regards, Vivek. On 7/2/09, Martin Willi mar...@strongswan.org wrote: Hi, 1. Could you please throw some light on how is the updated IP list is given to the stack The roam job just indicates the network configuration has changed. While processing the job, a route lookup is done to find a new (or keep the existing) path to reach the peer. 2. We saw that the XFRM_Expire message is received from the kernel. Is it then the correct assumptions that strongswan does not maintain the re-keying timer for the child SAs? Yes, IKE_SA lifetimes are handled in the daemon, while CHILD_SA lifetimes are handled in the kernel. The reason for this is that there are (theoretically) other ways to expire an SA, only known to the kernel (e.g. number of bytes/packets processed). 3. Could you let us know the best approach for plugging out the kernel interface and using our own? Removing the kernel interface is probably the most complex option, you would need to work around a lot of functionality in the core daemon. The right way to do it is implement a kernel interface for IPsec and networking for the QNX system. QNX uses a PF_KEY interface [1], so you could try to use our existing PF_KEY plugin. As NetBSD uses a policy handling concept similar to KLIPS (flows), you probably need to borrow some bits from the KLIPS plugin. For the networking part, QNX uses the PF_ROUTE protocol [2] from BSD. You could try to use our PF_ROUTE plugin. It should work, but might not be feature complete. If you are willing to sponsor the development, you could hand over your QNX porting efforts to us. The strongSwan team has some experience in porting to BSD based systems... Regards Martin [1]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ipsec_proto.html [2]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/r/route_proto.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi, Thanks for your help. I still have a doubt that who initiates the IKE SA and CHILD SA. 1. Is it kernel who initiates both? 2. Or Kernel just initiates the CHILD SA (through acquire() function as per the SPD) and the IKE SA is initiated/triggered by reading the ipsec.conf file from which he knows the local and remote IP addresses? 3. If I have asked the wrong question or have wrongly understood your stack code then please do explain me how an IKE SA and CHILD SA is initiated or triggered in your stack? Thank you. Regards, Vivek On 7/2/09, vivek bairathi bairathi.vi...@gmail.com wrote: Hi Martin, Thanks for your help. The problem is that we have a propritary implementaion of the IP stack in micro engine whose development is in assembly language. As per what you have suggested, I think it would make sense that we let the kernel interface remain as is ( just change address family of the sockets with compatiple ones ) and let another process sniff these messages and provide an adpater interface with the network processor/micro engine. This adapter would then provide all required interfaces to the strongswan What are your thoughts on the same ? Regards, Vivek. On 7/2/09, Martin Willi mar...@strongswan.org wrote: Hi, 1. Could you please throw some light on how is the updated IP list is given to the stack The roam job just indicates the network configuration has changed. While processing the job, a route lookup is done to find a new (or keep the existing) path to reach the peer. 2. We saw that the XFRM_Expire message is received from the kernel. Is it then the correct assumptions that strongswan does not maintain the re-keying timer for the child SAs? Yes, IKE_SA lifetimes are handled in the daemon, while CHILD_SA lifetimes are handled in the kernel. The reason for this is that there are (theoretically) other ways to expire an SA, only known to the kernel (e.g. number of bytes/packets processed). 3. Could you let us know the best approach for plugging out the kernel interface and using our own? Removing the kernel interface is probably the most complex option, you would need to work around a lot of functionality in the core daemon. The right way to do it is implement a kernel interface for IPsec and networking for the QNX system. QNX uses a PF_KEY interface [1], so you could try to use our existing PF_KEY plugin. As NetBSD uses a policy handling concept similar to KLIPS (flows), you probably need to borrow some bits from the KLIPS plugin. For the networking part, QNX uses the PF_ROUTE protocol [2] from BSD. You could try to use our PF_ROUTE plugin. It should work, but might not be feature complete. If you are willing to sponsor the development, you could hand over your QNX porting efforts to us. The strongSwan team has some experience in porting to BSD based systems... Regards Martin [1]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ipsec_proto.html [2]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/r/route_proto.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi Martin, Thanks for your help. The problem is that we have a propritary implementaion of the IP stack in micro engine whose development is in assembly language. As per what you have suggested, I think it would make sense that we let the kernel interface remain as is ( just change address family of the sockets with compatiple ones ) and let another process sniff these messages and provide an adpater interface with the network processor/micro engine. This adapter would then provide all required interfaces to the strongswan What are your thoughts on the same ? Regards, Vivek. On 7/2/09, Martin Willi mar...@strongswan.org wrote: Hi, 1. Could you please throw some light on how is the updated IP list is given to the stack The roam job just indicates the network configuration has changed. While processing the job, a route lookup is done to find a new (or keep the existing) path to reach the peer. 2. We saw that the XFRM_Expire message is received from the kernel. Is it then the correct assumptions that strongswan does not maintain the re-keying timer for the child SAs? Yes, IKE_SA lifetimes are handled in the daemon, while CHILD_SA lifetimes are handled in the kernel. The reason for this is that there are (theoretically) other ways to expire an SA, only known to the kernel (e.g. number of bytes/packets processed). 3. Could you let us know the best approach for plugging out the kernel interface and using our own? Removing the kernel interface is probably the most complex option, you would need to work around a lot of functionality in the core daemon. The right way to do it is implement a kernel interface for IPsec and networking for the QNX system. QNX uses a PF_KEY interface [1], so you could try to use our existing PF_KEY plugin. As NetBSD uses a policy handling concept similar to KLIPS (flows), you probably need to borrow some bits from the KLIPS plugin. For the networking part, QNX uses the PF_ROUTE protocol [2] from BSD. You could try to use our PF_ROUTE plugin. It should work, but might not be feature complete. If you are willing to sponsor the development, you could hand over your QNX porting efforts to us. The strongSwan team has some experience in porting to BSD based systems... Regards Martin [1]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ipsec_proto.html [2]http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/r/route_proto.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi Martin, Thanks for your help. For our implementation we need to port the strongswan stack on QNX. QNX does not have a kernel, but only a microkernel. This we need to remove any interface with the kernel in the strongswan stack and replace it with our own interface. Since Kernel net-interface is designed as a plugin, we were wondering whether it is feasible to plug out this interface with minimal effort and make the stronswan use our own plugin. In attempt to figure out the interface of the kernel-netlink plugin with the stack, we found that it is using the fire_roam_job function to update IKE SAs with respect to change in IP addresses. I am sure we are missing something, but fireroam job does not seem to use the updated adress list in the private_kernel_netlink_net_t structure. Hence, we are unable to get the interface of kernel-net-link with the stack for IP address update. 1. Could you please throw some light on how is the updated IP list is given to the stack 2. We saw that the XFRM_Expire message is received from the kernel. Is it then the correct assumptions that strongswan does not maintain the re-keying timer for the child SAs? 3. Could you let us know the best approach for plugging out the kernel interface and using our own? Many thanks for your help in advance Regards, Vivek. On 6/30/09, Martin Willi mar...@strongswan.org wrote: Hi, 1. How does the stack know of the change in the IP address? The IKEv2 daemon listens to netlink notification messages sent by the Linux kernel. 2. Does the stack listen to such events from the kernel? If yes, could you point us to the location in the stack that listens to kernel for such events? Charon listens for notifications from the kernel in the receive_events() function found in kernel_netlink_net.c. There it handles link/address/route changes. If something changes, it finally calls fire_roam_job() to update existing IKE_SAs. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
