I have a pending patch that allows configuring a mark= that you can use in the updown script. There are some people interested in it but it would be good to define some common support in updown
Sent from my iPhone > On Oct 29, 2015, at 10:10, Amir Naftali <[email protected]> wrote: > > Thanks Paul, > > I'm well aware to the advantages of using SA (and totally agree that its > better) per subnet pair put I can't change my customer specification (it's > given on their side), so > > I'm still looking for a technique that will let me support multiple of those > SA per GW connection to multiple different CP VPN GWs > > If manually changing xfrm policy is not the right way, than I'm left with > classification via the connection configuration - is there an option to > classify traffic using a "mark"? > > As far as I tested, xfrm policies support the mark option - this will allow > me to "mark" traffic using iptables which will let me send the outgoing > traffic via the right tunnel > (connection1 will fwd traffic marked with 1, connection2 will fwd traffic > marked 2...etc) > > Any thoughts? > > Amir > > > > > > Amir Naftali | CTO and Co-Founder | +972 54 497 2622 > > > >> On Thu, Oct 29, 2015 at 11:46 AM, Paul Wouters <[email protected]> wrote: >> On Thu, 29 Oct 2015, Amir Naftali wrote: >> >>> That might do for the simple case but my Libreswan based VPN server is >>> aggregating many such connections >>> including connection where SAs are negotiated per subnet pairs >> >> Well, "routing based VPNs" are not the best choice. It is much more >> secure and easier to configure "policy based VPNs". That is where you >> specifically define the traffic allowed to pass using leftsubnet= and >> rightsubnet=. >> >>> Please note that the wildcard negotiation is just a technical requirement >>> - I'm not really looking to >>> install a wildcard xfrm policies. The installed policy will have a src/dst >>> subnets blocks allocated to >>> them. >>> >>> Basically I'm still looking for a way to take control over xfrm policies >>> instrumentation using the >>> leftupdown option in the connection configuration and the issue I described >>> (partial xfrm policy >>> instrumentation during re-key) is the only thing that prevents me from >>> being able to do so. >>> >>> Is there a way to tell a connection not to install xfrm policies at all or >>> is there a way to prevent form >>> libreswan to install the partial xfrm "out" policy during re-key? >> >> You should never manually modify the xfrm tables outside the running IKE >> daemon. The IKE daemon is not aware of your manual tweaks and it could >> lead to mismatched policies, unexpected state and packet leaks. >> >> Paul >
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
