Hi, Thanks for your help.
Some more queries:- 1.Did you mean that if I change any parameter in ipsec.conf then I have to delete the IKE SA and all the corresponding CHILD SA's and then apply the new configuration? 2. Is it possible to not to delete an SA and apply the new settings on the CHILD SA's that will be created in future? 3. If suppose an IKE SA has been created for a connection and I want to create a CHILD SA for it, then how do I tell stack to do that? Is it through ipsec.conf or what? 4. If I provide all the ip addresses to the stack in the ipsec.conf and disable the kernel-netlink-net interface will there be any problem with the working of the stack? Thanks & Regards, Vivek On 7/27/09, Andreas Steffen <andreas.stef...@strongswan.org> wrote: > Hi Vivek, > > you can change any connection parameter by > > 1) redefining it in ipsec.conf > > 2) taking down the active connection executing > > ipsec down <connection name> > > 3) execute > > ipsec update > > which transfers the new connection definition to the charon daemon. > > 4) execute > > ipsec up <connection name> > > if auto=add. with auto=start the connection will be restarted by > ipsec update. > > Best regards > > Andreas > >> Hi, >> >> Thanks for your detailed response. >> >> 1. We had a requirement to change the internal/virtual IP at runtime >> after charon is spawned. Is it possible to change the internal/virtual >> IP in a tunnel once the stack is spawned? We went through the code and >> found that deletion of outer/tunnel IP and inner/virtual IP is >> detected and handled by charon. However addition, of IP address is >> detected only for outer/tunnel IP? How can I change internal IP >> associated with tunnel IP after charon is spawned? >> >> Can the following parameters be changed at runtime after charon is spawned >> :- >> 1. The authentication parameter be changed from PSK to CERT/ CERT to >> PSK? >> 2. Re-keying time of IKE/IPSEC SA: can the new re-keying value be >> assinged to new SA created henceforth? >> 3. Encryption algorithm can be changed for an IKE SA? >> >> It would be great help if you could answer the above queries. >> >> Thanks & Regards, >> Vivek >> >> >> >> On 7/27/09, Andreas Steffen <andreas.stef...@strongswan.org> wrote: >>> Hi Vivek, >>> >>> vivek bairathi wrote: >>>> Hi all, >>>> >>>> I have a requirement for creating tunnel SAs. After reading >>>> strongswan documentation and code I arrived at the following >>>> conclusion:- >>>> >>>> 1. left| right source IP in the conn section of ipsec.conf is used to >>>> specify the internal IP in the tunnel( virtual IP). The external >>>> tunnel IP will be filled in left| right parameters. Is this assumtion >>>> correct? >>>> >>> This is not correct. Let us assume that left is local and right is >>> remote. Then >>> >>> leftsourceip=<virtual IP address> >>> >>> or >>> >>> leftsourceip=%config >>> >>> define a virtual IP address to be used as source address within >>> the IPsec tunnel. This is equivalent to setting the source >>> traffic selector to >>> >>> leftsubnet=<virtual IP address>/32 >>> >>> but does not change in any way left= which is used as the source >>> address of the ESP packet. >>>> 2. How does the stack distinguish that the IPaddress that is being >>>> added is external IP or internal IP in the tunnel ? >>>> >>> See point 1 above. >>> >>>> 3. How does the addition/deletion of external tunnel IP address and >>>> internal IP handled differently by the charon? >>>> >>> Available external IP addresses are automatically detected by >>> strongSwan using RT_NETLINK. E.g. defining >>> >>> left=%any >>> >>> will select the outer source address based on the actual route to >>> right. This can be very helpful in multi-homing environments. >>> >>> Virtual IP addresses are installed and by strongSwan via RT_NETLINK >>> by adding a new virtual IP address as an alias of the physical >>> interface used. >>> >>> ip addr list dev eth0 >>> >>> will show the virtual IPs associated with eth0. By installing a source >>> route in table 220 which is shown by the command >>> >>> ip route list table 220 >>> >>> All plaintext packets with destination "rightsubnet" will assume the >>> virtual IP as their source address before being encapsulated by ESP. >>> >>> >>>> Thanks & Regards, >>>> Vivek >>> Regards >>> >>> Andreas > > ====================================================================== > Andreas Steffen andreas.stef...@strongswan.org > strongSwan - the Linux VPN Solution! www.strongswan.org > Institute for Internet Technologies and Applications > University of Applied Sciences Rapperswil > CH-8640 Rapperswil (Switzerland) > ===========================================================[ITA-HSR]== > _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
