[strongSwan] : help --- can not insmod esp4.ko
Hi all, When I want to run strongswan on the basis of NETKEY, I encountered the following problem. Please help to check. Thanks! Issue description: = Linux Kernel: 2.6.18 Selected module: 1) user configuration interface 2) PF_key sockets 3) Advanced router 4) Policy routing 5) AH transformation 6) ESP transformation 7) IPComp Transformation 8) IPsec transport mode 9) IPsec tunnel mode 10）ipsec “policy” match support Encountered issue: when I cross-compiled the kernel, generated uImage and download the .ko file to ARM and then I insmod the .ko. Escept the esp4.ko can not be installed, other .ko file can be installed successfully. And the following error can be seen: ~~~` Esp4: Unknown symbol skb_cow_data Esp4: Unknown symbol pskb_put Esp4: Unknown symbol skb_to_sgvec Insmod: error inserting ‘esp4.ko’: -1 Unknown symbol in module ~~~ After I checked the /proc/kallsyms, and found that actually there are no these symbols in it. But when I checked the System.map, I found these symbols. Did anybody encounter the same issue? Please help me, Thanks in advance! Best Regards, David ___ 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
[strongSwan] problem with traffic selector negotiation
Hi all, (sorry for re-sending, my first post was emptied by the server) I am currently using charon from strongSwan 4.3.2 with the following configuration: [ 10.22.8.0/24 ] [ 10.23.8.0/24 ] [ 10.24.8.0/24 ] (NETA)--- [GTWA] == [GTWB] --- (NETB) .118 .218 Where GTWA and GTWB are two strongSwan IPsec gateways. I defined 3 connections between GTWA and GTWB for: - TCP traffic between NETA and NETB - UDP traffic between NETA and NETB - any other traffic between NETA and NETB The configuration is the same on GTWA and GTWB (just local and remote addresses are swapped). TCP and UDP traffic sent from NETA to NETB triggers IKE negotiations and is properly IPsec encrypted. But when using ICMP traffic, which matches the any policies, an SA pair is established for the TCP policies instead of for the any policies. As I could see in the GTWB log file, the initiator GTWA proposes 2 traffic selectors for TSi and 2 traffic selectors for TSr: 10.24.8.139/32[icmp] 10.24.8.0/24 === 10.22.8.51/32[icmp/8] 10.22.8.0/24 After comparing to its SPD, the responder narrows the TS to: 10.24.8.0/24[tcp] === 10.22.8.0/24[tcp] and CHILD_SAs are hence established for the TCP traffic. It is obviously not the expected behavior. Intuitively, we expect that a CHILD_SA is negotiated for traffic 10.24.8.0/24 === 10.22.8.0/24, the first TSi and TSr traffic selectors are just the parameters of the packet that triggered the acquire and must be used as hints for the responder in case it would have to narrow the traffic selector (which is not needed here). Note: although the expected result is obvious in this case, (we want the responder to choose 10.24.8.0/24 === 10.22.8.0/24), it is not clear for other possible cases. The RFC4306 does not explicit what is the meaning of including several members in TSi and TSr. This makes it difficult to specify the right algorithm to negotiate the traffic selectors... any idea on how to fix it and on the general meaning of including several members in TSi and TSr? Regards, Christophe. initiator ipsec.conf file: == version 2.0 config setup charonstart=yes plutostart=no charondebug=cfg 2 conn %default auto=route keyexchange=ikev2 conn myvpn~ruletcp mobike=no left=10.23.8.108 right=10.23.8.208 leftsubnet=10.22.8.0/24 rightsubnet=10.24.8.0/24 leftprotoport=tcp rightprotoport=tcp left...@soo.6wind.com rightid=%any type=tunnel ike=3des-md5-modp768 esp=3des-md5-modp768 ikelifetime=57600s rekeymargin=5760s keylife=28800s authby=secret auto=route rekey=yes reauth=no conn myvpn~ruleudp mobike=no left=10.23.8.108 right=10.23.8.208 leftsubnet=10.22.8.0/24 rightsubnet=10.24.8.0/24 leftprotoport=udp rightprotoport=udp left...@soo.6wind.com rightid=%any type=tunnel ike=3des-md5-modp768 esp=3des-md5-modp768 ikelifetime=57600s rekeymargin=5760s keylife=28800s authby=secret auto=route rekey=yes reauth=no conn myvpn~ruleany mobike=no left=10.23.8.108 right=10.23.8.208 leftsubnet=10.22.8.0/24 rightsubnet=10.24.8.0/24 leftprotoport=%any rightprotoport=%any left...@soo.6wind.com rightid=%any type=tunnel ike=3des-md5-modp768 esp=3des-md5-modp768 ikelifetime=57600s rekeymargin=5760s keylife=28800s authby=secret auto=route rekey=yes reauth=no responder ipsec.conf file: == version 2.0 # conforms to second version of ipsec.conf specification config setup charonstart=yes plutostart=no charondebug=cfg 2 conn %default auto=route keyexchange=ikev2 conn myvpn~ruletcp mobike=no left=10.23.8.208 right=10.23.8.108 leftsubnet=10.24.8.0/24 rightsubnet=10.22.8.0/24 leftprotoport=tcp rightprotoport=tcp left...@mee.6wind.com rightid=%any type=tunnel ike=3des-md5-modp768 esp=3des-md5-modp768 ikelifetime=57600s rekeymargin=5760s keylife=28800s authby=secret auto=route rekey=yes reauth=no conn myvpn~ruleudp mobike=no left=10.23.8.208 right=10.23.8.108 leftsubnet=10.24.8.0/24 rightsubnet=10.22.8.0/24 leftprotoport=udp rightprotoport=udp left...@mee.6wind.com rightid=%any type=tunnel ike=3des-md5-modp768 esp=3des-md5-modp768 ikelifetime=57600srekeymargin=5760s keylife=28800s authby=secret auto=route rekey=yes reauth=no conn myvpn~ruleany mobike=no
