> So before I go further on my effort I figured I would ask, does the > architecture of libipsec somehow preclude the inclusion of passthrough > and drop?
Drop policies could be implemented pretty easily. For instance, by dropping packets if we find such a policy, or alternatively if we don't find an associated SA, which actually is already the case, so we only had to store drop policies in the policy manager (but this currently produces log messages for each packet). This feature could also be implemented in kernel-libipsec by installing blackhole routes, which could, of course, also be done outside of strongSwan. Implementing passthrough policies is trickier. Basically, libipsec is currently limited to working with TUN devices and UDP sockets. So in the current architecture it is simply not possible to properly forward packets without encapsulating them. Instead we could, for instance, install the routes via TUN device for regular policies so that they exclude the traffic that is to be passed through. This would have to be done in kernel-libipsec e.g. by keeping track of the passthrough policies and then e.g. split subnets that overlap with them and install individual routes that exclude such traffic (more problematic would be the installation of passthrough policies after an overlapping IPsec policy has already been installed). Installing specific routes for pass through policies would also work but determining the parameters (nexthop, outgoing interface, source address etc.) might be trickier. Yet another option would be to use policy routing to install specific policies that direct traffic that is to be passed through to the main routing table instead of table 220, which we use for our routes. This would limit such a solution to Linux though. The latter two solution could also be implemented outside of strongSwan, of course. And all these solutions currently don't rely on libipsec actually supporting passthrough policies. In order for libipsec to serve as a more general purpose IPsec implementation, where support for shunt policies makes more sense, we'd also have to implement e.g. IP tunneling and UDP encapsulation ourselves. Besides being quite some work this would require unwrapping the packets again in the current users (kernel-libipsec, Android app), which can only send packets via charon's UDP socket (providing different public interfaces for different users could be an option). Anyway, this would complicate things quite a it, for a feature that we currently really have no use for (and for which workarounds are readily available). Regards, Tobias _______________________________________________ Dev mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/dev
