Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

initial_contact (on | off);
Enable this to send an INITIAL-CONTACT message. The default value is on. This message is useful only when the responder implementa-
tion chooses an old SA when there are multiple SAs with different established time and the initiator reboots. If racoon did not send
the message, the responder would use an old SA even when a new SA was established. For systems that use a KAME derived IPSEC stack,
the sysctl(8) variable net.key.preferred_oldsa can be used to control this preference. When the value is zero, the stack always uses
a new SA.
...
rekey (on | off | force);
Enable automatic renegotiation of expired phase1 when there are non-dying phase2 SAs. Possible values are:
force Rekeying is done unconditionally.
on Rekeying is done only if DPD monitoring is active. This is the default.
off No automatic rekeying. Do note that turning off automatic rekeying will result in inaccurate DPD monitoring.
...

The INITIAL_CONTACT notification asserts that this IKE SA is the only
IKE SA currently active between the authenticated identities. It MAY
be sent when an IKE SA is established after a crash, and the
recipient MAY use this information to delete any other IKE SAs it has
to the same authenticated identity without waiting for a timeout.
This notification MUST NOT be sent by an entity that may be
replicated (e.g., a roaming user's credentials where the user is
allowed to connect to the corporate firewall from two remote systems
at the same time). The INITIAL_CONTACT notification, if sent, MUST
be in the first IKE_AUTH request or response, not as a separate
exchange afterwards; receiving parties MAY ignore it in other
messages.

Since IKE is designed to operate in spite of DoS attacks from the
network, an endpoint MUST NOT conclude that the other endpoint has
failed based on any routing information (e.g., ICMP messages) or IKE
messages that arrive without cryptographic protection (e.g., Notify
messages complaining about unknown SPIs). An endpoint MUST conclude
that the other endpoint has failed only when repeated attempts to
contact it have gone unanswered for a timeout period or when a
cryptographically protected INITIAL_CONTACT notification is received
on a different IKE SA to the same authenticated identity. An
endpoint should suspect that the other endpoint has failed based on
routing information and initiate a request to see whether the other
endpoint is alive. To check whether the other side is alive, IKE
specifies an empty INFORMATIONAL message that (like all IKE requests)
requires an acknowledgement (note that within the context of an IKE
SA, an "empty" message consists of an IKE header followed by an
Encrypted payload that contains no payloads). If a cryptographically
protected (fresh, i.e., not retransmitted) message has been received
from the other side recently, unprotected Notify messages MAY be
ignored. Implementations MUST limit the rate at which they take
actions based on unprotected messages.

...
flush [protocol] ;
Clear all SAD entries matched by the options. -F on the command line achieves the same functionality.
...
spdflush ;
Clear all SPD entries. -FP on the command line achieves the same functionality.
...
spdadd [-46n] src_range dst_range upperspec label policy ;
Add an SPD entry.

spdadd tagged tag policy ;
Add an SPD entry based on a PF tag. tag must be a string surrounded by double quotes.
...
src_range
dst_range
These select the communications that should be secured by IPsec. They can be an IPv4/v6 address or an IPv4/v6 address range, and may be
accompanied by a TCP/UDP port specification. This takes the following form:

address
address/prefixlen
address[port]
address/prefixlen[port]

prefixlen and port must be decimal numbers. The square brackets around port are really necessary, they are not man page meta-characters.
For FQDN resolution, the rules applicable to src and dst apply here as well.
...
upperspec
Upper-layer protocol to be used. You can use one of the words in /etc/protocols as upperspec, or icmp6, ip4, gre, or any. any stands for
“any protocol”. You can also use the protocol number. Additional specification can be placed after the protocol name for some protocols.
You can specify a type and/or a code of ICMP or ICMPv6. The type is separated from a code by single comma and the code must always be speci-
fied. GRE key can be specified in dotted-quad format or as plain number. When a zero is specified, the kernel deals with it as a wildcard.
Note that the kernel can not distinguish a wildcard from an ICPMv6 type of zero.

For example, the following means that the policy doesn’t require IPsec for any inbound Neighbor Solicitation.
spdadd ::/0 ::/0 icmp6 135,0 -P in none;

A second example of requiring transport mode encryption of specific GRE tunnel:
spdadd 0.0.0.0 0.0.0.0 gre 1234 ipsec esp/transport//require;

Note: upperspec does not work against forwarding case at this moment, as it requires extra reassembly at the forwarding node (not implemented
at this moment). There are many protocols in /etc/protocols, but all protocols except of TCP, UDP, GRE, and ICMP may not be suitable to use
with IPsec. You have to consider carefully what to use.
...
policy policy is in one of the following three formats:
-P direction [priority specification] discard
-P direction [priority specification] none
-P direction [priority specification] ipsec protocol/mode/src-dst/level [...]

You must specify the direction of its policy as direction. Either out, in, or fwd can be used.

priority specification is used to control the placement of the policy within the SPD. Policy position is determined by a signed integer
where higher priorities indicate the policy is placed closer to the beginning of the list and lower priorities indicate the policy is placed
closer to the end of the list. Policies with equal priorities are added at the end of groups of such policies.

Priority can only be specified when setkey has been compiled against kernel headers that support policy priorities (Linux >= 2.6.6). If the
kernel does not support priorities, a warning message will be printed the first time a priority specification is used. Policy priority takes
one of the following formats:

{priority,prio} offset
offset is an integer in the range from -2147483647 to 214783648.

{priority,prio} base {+,-} offset
base is either low (-1073741824), def (0), or high (1073741824)

offset is an unsigned integer. It can be up to 1073741824 for positive offsets, and up to 1073741823 for negative offsets.

discard means the packet matching indexes will be discarded. none means that IPsec operation will not take place onto the packet. ipsec
means that IPsec operation will take place onto the packet.

The protocol/mode/src-dst/level part specifies the rule how to process the packet. Either ah, esp, or ipcomp must be used as protocol. mode
is either transport or tunnel. If mode is tunnel, you must specify the end-point addresses of the SA as src and dst with ‘-’ between these
addresses, which is used to specify the SA to use. If mode is transport, both src and dst can be omitted. level is to be one of the follow-
ing: default, use, require, or unique. If the SA is not available in every level, the kernel will ask the key exchange daemon to establish a
suitable SA. default means the kernel consults the system wide default for the protocol you specified, e.g. the esp_trans_deflev sysctl
variable, when the kernel processes the packet. use means that the kernel uses an SA if it’s available, otherwise the kernel keeps normal
operation. require means SA is required whenever the kernel sends a packet matched with the policy. unique is the same as require; in addi-
tion, it allows the policy to match the unique out-bound SA. You just specify the policy level unique, racoon(8) will configure the SA for
the policy. If you configure the SA by manual keying for that policy, you can put a decimal number as the policy identifier after unique
separated by a colon ‘:’ like: unique:number in order to bind this policy to the SA. number must be between 1 and 32767. It corresponds to
extensions -u of the manual SA configuration. When you want to use SA bundle, you can define multiple rules. For example, if an IP header
was followed by an AH header followed by an ESP header followed by an upper layer protocol header, the rule would be:
esp/transport//require ah/transport//require;
The rule order is very important.

When NAT-T is enabled in the kernel, policy matching for ESP over UDP packets may be done on endpoint addresses and port (this depends on the
system. System that do not perform the port check cannot support multiple endpoints behind the same NAT). When using ESP over UDP, you can
specify port numbers in the endpoint addresses to get the correct matching. Here is an example:

spdadd 10.0.11.0/24[any] 10.0.11.33/32[any] any -P out ipsec
esp/tunnel/192.168.0.1[4500]-192.168.1.2[30000]/require ;

These ports must be left unspecified (which defaults to 0) for anything other than ESP over UDP. They can be displayed in SPD dump using
setkey -DPp.

Note that “discard” and “none” are not in the syntax described in ipsec_set_policy(3). There are a few differences in the syntax. See
ipsec_set_policy(3) for detail.
...