<refsect1 id='choosing_a_connection'><title>CHOOSING A CONNECTION [THIS SECTION IS EXTREMELY OUT OF DATE</title>
<para>When choosing a connection to apply to an outbound packet caught with a
<emphasis remap='B'>%trap,</emphasis>
the system prefers the one with the most specific eroute that
includes the packet's source and destination IP addresses.
Source subnets are examined before destination subnets.
For initiating, only routed connections are considered. For responding,
unrouted but added connections are considered.</para>

<para>When choosing a connection to use to respond to a negotiation which
doesn't match an ordinary conn, an opportunistic connection
may be instantiated. Eventually, its instance will be /32 -&gt; /32, but
for earlier stages of the negotiation, there will not be enough
information about the client subnets to complete the instantiation.</para>
</refsect1>

<refsect1 id='files'><title>FILES</title>
<literallayout remap='.nf'>
/etc/ipsec.conf
/etc/ipsec.d/policies/clear
/etc/ipsec.d/policies/clear-or-private
/etc/ipsec.d/policies/private-or-clear
/etc/ipsec.d/policies/private
/etc/ipsec.d/policies/block
</literallayout> <!-- .fi -->
</refsect1>

<refsect1 id='see_also'><title>SEE ALSO</title>
<para><citerefentry><refentrytitle>ipsec</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>ipsec_ttoaddr</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>ipsec_auto</refentrytitle><manvolnum>8</manvolnum></citerefentry>, <citerefentry><refentrytitle>ipsec_rsasigkey</refentrytitle><manvolnum>8</manvolnum></citerefentry></para>
</refsect1>

<refsect1 id='history'><title>HISTORY</title>
<para>Designed for the FreeS/WAN project
&lt;<ulink url='http://www.freeswan.org'>http://www.freeswan.org</ulink>&gt;
by Henry Spencer.</para>
</refsect1>

<refsect1 id='bugs'><title>BUGS</title>
<para>Before reporting new bugs, please ensure you are using the latest
version of Libreswan, and if not using KLIPS, please ensure you are using
the latest kernel code for your IPsec stack.</para>

<para>When
<emphasis remap='B'>type</emphasis>
or
<emphasis remap='B'>failureshunt</emphasis>
is set to
<emphasis remap='B'>drop</emphasis>
or
<emphasis remap='B'>reject,</emphasis>
Libreswan blocks outbound packets using eroutes, but assumes inbound
blocking is handled by the firewall. Libreswan offers firewall hooks
via an &ldquo;updown&rdquo; script.  However, the default
<emphasis remap='B'>ipsec _updown</emphasis>
provides no help in controlling a modern firewall.</para>

<para>Including attributes of the keying channel (authentication methods,
<emphasis remap='B'>ikelifetime</emphasis>, etc.) as an attribute of a
connection, rather than of a participant pair, is dubious and incurs
limitations.</para>

<para>The use of <emphasis remap='B'>%any</emphasis> with the
<emphasis remap='I'>protoport=</emphasis> option is ambiguous. Should
the SA permits any port through or should the SA negotiate any single
port through?  The first is a basic conn with a wildcard. The second
is a template. The second is the current behaviour, and it's wrong
for quite a number of uses involving TCP. The keyword
<emphasis remap='B'>%one</emphasis> may be introduced in the future to
separate these two cases.</para>

<para>It would be good to have a line-continuation syntax,
especially for the very long lines involved in
RSA signature keys.</para>

<para><emphasis remap='B'>First packet caching</emphasis> is only implemented
for the KLIPS(NG) and MAST stacks. NETKEY returns POSIX-breaking responses,
visible as <emphasis remap='I'>connect: Resource temporarily unavailable</emphasis>
errors. This affects Opportunistic Encryption and DPD. Functionality on the BSD
and Windows stacks is unknown.</para>

<para>Some state information is only available when using KLIPS, and will
return errors on other IPsec stacks. These include
<emphasis remap='I'>ipsec eroute</emphasis>,
<emphasis remap='I'>ipsec spi</emphasis> and
<emphasis remap='I'>ipsec look</emphasis>.</para>

<para> Multiple L2TP clients behind the same NAT router, and multiple L2TP
clients behind different NAT routers using the same Virtual IP is currently
only working for the KLIPSNG stack.</para>

<para>The ability to specify different identities,
<emphasis remap='B'>authby</emphasis>,
and public keys for different automatic-keyed connections
between the same participants is misleading;
this doesn't work dependably because the identity of the participants
is not known early enough.
This is especially awkward for the &ldquo;Road Warrior&rdquo; case,
where the remote IP address is specified as
<literal>0.0.0.0</literal>,
and that is considered to be the &ldquo;participant&rdquo; for such connections.</para>

<para>In principle it might be necessary to control MTU on an
interface-by-interface basis,
rather than with the single global override that
<emphasis remap='B'>overridemtu</emphasis>
provides. This feature is planned for a future release.</para>

<para>If conns are to be added before DNS is available,
<emphasis remap='B'>left=</emphasis><emphasis remap='I'>FQDN</emphasis>,
<emphasis remap='B'>leftnextop=</emphasis><emphasis remap='I'>FQDN</emphasis>,
and
<emphasis remap='B'>leftrsasigkey=%dnsonload</emphasis>
will fail.
<citerefentry><refentrytitle>ipsec_pluto</refentrytitle><manvolnum>8</manvolnum></citerefentry>
does not actually use the public key for our side of a conn but it
isn't generally known at a add-time which side is ours (Road Warrior
and Opportunistic conns are currently exceptions).</para>

<para>The <emphasis remap='B'>myid</emphasis> option does not affect explicit <emphasis remap='B'> ipsec auto --add</emphasis> or <emphasis remap='B'>ipsec auto --replace</emphasis> commands for implicit conns.</para>
</refsect1>
</refentry>

