[Swan] GW To GW IPSec connection between CheckPoint and Libreswan

Amir Naftali amir at fortycloud.com
Thu Oct 29 08:51:38 UTC 2015

Thanks Paul

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

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?

Will appreciate your insight here


*Amir Naftali* | *CTO and Co-Founder | +972 54 497 2622*


On Thu, Oct 29, 2015 at 1:44 AM, Paul Wouters <paul at nohats.ca> wrote:

> If your enpoints are on static IP, you should put a type=passthrough in
> with left/right set to those IP addresses. That will exclude them from
> being caught in the 0/0, because passthrough has a higher priority.
> Sent from my iPhone
> On Oct 28, 2015, at 15:57, Amir Naftali <amir at fortycloud.com> wrote:
> Hi All
> Thank you for supporting this important opensource initiative.
> I'm using libreswan(3.15)/netkey running on an AWS/EC2/Ubuntu/14.04
> machine  to connect to a CheckPoint device where the CP device is
> configured to establish an SA per GW (as oppose per subnet pair)
> This means that the negotiated subnets during IPSec phase that the CP
> devices will send and accept are and
> The connection can be established but once the IPSec phase is complete it
> will install xfrm policies that will shutdown communication (src
> dst [in/out/fwd]...)
> Since libreswan installs xfrm policies automatically I thought to use the
> leftupdown option to write a script that manage xfrm policies myself
> (basically allow the wildcard to be negotiated during IPSec phase but
> afterwards install a more specific xfrm policies so communication will not
> shutdown.
> My script works fine until IPSec re-key happens, once re-key happens swan
> installs an xfrm policy w/o making a call to the leftupdown script I
> provide. The new installed xfrm policy is not complete and looks like this
> (I call it partial since it only deploy the "out" policy w/o the "in" and
> "fwd")
> Here is how the partial policy it looks like
> src dst
> dir out priority 3128
> tmpl src <my ip> dst <remote ip>
> proto esp reqid 16401 mode tunnel
> The above policy also shut down my communication to/from the machine.
> Here is my connection config...
> conn connLG
>         connaddrfamily=ipv4
> authby=secret
> dpdaction=restart_by_peer
> dpddelay=30
> dpdtimeout=120
> forceencaps=yes
> ike=aes128-sha1;modp1024
> ikelifetime=86400s
> keyingtries=3
> left=<my ip>
> leftid=<mu id>
> leftsubnets=
>         leftupdown="/etc/ipsec.d/myUpDown.sh"
> pfs=yes
> phase2alg=aes128-sha1
> right=<right ip>
> rightid=<right id>
> rightsubnets=
> salifetime=180s
> My questions are:
> 1) Is this the right way to do it (how else can i connect to a peer device
> that negotiates wildcard subnets)?
> 2) How can I better control xfrm policies (there are more options I would
> like to use like mark and using multiple tmpl in the same policy) that are
> not supported by libreswan?
> 3) Is the behaviour I described above regarding IPSec re-key and partial
> xfrm policy instrumentation is a known issue or am I missing something here
> in how it should work?
> Will appreciate any response regarding this one
> Kind Regards,
> *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>
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20151029/90d3774c/attachment.html>

More information about the Swan mailing list