I also ran into this issue. In cases where multiple endpoints are residing behind the same NAT, the port numbers are also needed to identify the correct policy for each endpoint.
strongSwan reuses the same reqid for all of the endpoints sitting behind the same NAT IP, and it becomes impossible to associate outbound policies with outbound SA’s using just the reqid. You can modify the strongSwan code to pass them in (which is what I did), but you do need to update the plug-in interfaces in a decent number of places. It would be great if everyone saw the utility of this if we could make it part of the mainline. /Ryan On 9/14/15, 1:26 PM, "Dmitry Shubin" <[email protected]> wrote: >Hi. > >I am working on a custom IPSec implementation and have a >question/proposal about kernel_interface. > >I've noticed that there is a certain asymmetry between add_policy() and >del_policy() methods: del_policy() receives a smaller set of parameters >than add_policy(), namely there are no spi, src and dst values provided. >That makes it hard (or, perhaps, harder than necessary) to actually >delete policies since there is no way to determine which child_sa a >del_policy() call came from. One has to either do some weird stuff to >recover the aforementioned parameters (if that is at all possible) or >(re)design your SPD/SAD so that it can handle duplicate policies and/or >is reliant on the ordering of {add,del}_policy() calls and reqid (which >doesn't have a very well defined meaning as far as I can tell). > >On the other hand all these issues (seem to) go away if del_policy() >comes with {spi,src,dst}: we know exactly which policy to delete, we >don't have to rely on ordering, we don't have to rely on reqid to search >for SA after an SP match has occurred, no need to maintain auxiliary >mapping to recover missing data, etc. > >I've poked around the code a bit and at a first glance it appears to be >a viable idea. Actually, I've done some quick-and-dirty experiments and >it seems to work just fine, at very least regular connections, traps and >rekeying do work as expected. Am I missing something? >_______________________________________________ >Dev mailing list >[email protected] >https://lists.strongswan.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
