This sounds great, having such a capability will provide a powerful tool supporting an advance set of use cases
Is there a way to get an early peek at the patch so I can test it against some use cases that we have Amir *Amir Naftali* | *CTO and Co-Founder | +972 54 497 2622* <http://www.fortycloud.com/?utm_campaign=amir_email&utm_medium=email&utm_source=signature&utm_content=link&utm_term=amir_sig> On Thu, Oct 29, 2015 at 10:10 PM, Paul Wouters <[email protected]> wrote: > 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 > <%2B972%2054%20497%202622>* > > > <http://www.fortycloud.com/?utm_campaign=amir_email&utm_medium=email&utm_source=signature&utm_content=link&utm_term=amir_sig> > > 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
