On Tue, 26 May 2015, Brandon Enochs wrote:
I was looking to add a entry to /etc/ipsec.d/policies/private, but the documentation was unclear.
Ah, you were (accidentally) trying Opportunistic Encryption. We are currently hard at work at reviving that code, and we will update the documentation for those policy files. For now though, do not use them. When the special OE connections are loaded (currently via handcrafted .conf file), it will create a few meta-connections. These are called "block", "clear", "private", "private-or-clear", "clear-or-private" and "packetdefault". For each entry in /etc/ipsec.d/policies/XXX, it will add an instance of the connection. So adding 1.2.3.4/32 in "clear" would add a connection "clear#1.2.3.4/32" which would place a type=passthrough policy in the kernel. For the entry private-or-clear, it will put a policy in the kernel that causes a packet that matches the remote network to cause a kernel ACQUIRE to be sent to pluto. Once pluto receives this, it will try to find a matching connection. This connection is not a traditional static VPN but based on however pluto get obtain a public IPsec KEY for that remote endpoint. In the past this was a TXT record in the reverse of the IP address. In the next libreswan release, there will be AUTH_NULL support to do IKE without authentication. The release after that will have support for IPSECKEY lookups in the forward (and reverse) DNS, and possibly other methods such as Kerberos. But all of this is most likely not what you wanted. If you want an ondemand tunnel between two endpoints, you need to configure a full connection with either a preshared key or certificates or raw RSA key. See our wiki for configuration examples. Paul _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
