<p dir="ltr">Are IPv6 host to host connections with right specified as a subnet supported?</p>
<div class="gmail_quote">On May 26, 2015 10:41 PM, "Paul Wouters" <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 26 May 2015, Brandon Enochs wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I was looking to add a entry to /etc/ipsec.d/policies/private, but the documentation was unclear.<br>
</blockquote>
<br>
Ah, you were (accidentally) trying Opportunistic Encryption. We are<br>
currently hard at work at reviving that code, and we will update the<br>
documentation for those policy files. For now though, do not use them.<br>
<br>
When the special OE connections are loaded (currently via handcrafted<br>
.conf file), it will create a few meta-connections. These are called<br>
"block", "clear", "private", "private-or-clear", "clear-or-private"<br>
and "packetdefault".<br>
<br>
For each entry in /etc/ipsec.d/policies/XXX, it will add an instance of<br>
the connection. So adding <a href="http://1.2.3.4/32" target="_blank">1.2.3.4/32</a> in "clear" would add a connection<br>
"clear#<a href="http://1.2.3.4/32" target="_blank">1.2.3.4/32</a>" which would place a type=passthrough policy in the<br>
kernel.<br>
<br>
For the entry private-or-clear, it will put a policy in the kernel that<br>
causes a packet that matches the remote network to cause a kernel<br>
ACQUIRE to be sent to pluto. Once pluto receives this, it will try to<br>
find a matching connection. This connection is not a traditional static<br>
VPN but based on however pluto get obtain a public IPsec KEY for that<br>
remote endpoint. In the past this was a TXT record in the reverse of<br>
the IP address. In the next libreswan release, there will be AUTH_NULL<br>
support to do IKE without authentication. The release after that will<br>
have support for IPSECKEY lookups in the forward (and reverse) DNS,<br>
and possibly other methods such as Kerberos.<br>
<br>
But all of this is most likely not what you wanted. If you want an<br>
ondemand tunnel between two endpoints, you need to configure a full<br>
connection with either a preshared key or certificates or raw RSA<br>
key. See our wiki for configuration examples.<br>
<br>
Paul<br>
</blockquote></div>