Remote Section

#

# PSK XAuth Remote Section

#

remote anonymous

{

   exchange_mode aggressive;

   verify_identifier on;

   my_identifier fqdn "vpngw.shrew.net";

   peers_identifier fqdn "client.shrew.net";

   passive on;

   generate_policy unique;

   ike_frag on;

   nat_traversal on;

   dpd_delay 30;

   proposal_check claim;

   lifetime time 24 hours;

   proposal

   {

       encryption_algorithm aes 256;

       hash_algorithm sha1;

       authentication_method xauth_psk_server;

       dh_group 5;

   }

}

#

# RSA XAuth Remote Section

#

remote anonymous

{

   exchange_mode main;

   verify_identifier on;

   my_identifier asn1dn;

   peers_identifier asn1dn;

   certificate_type x509 "vpngw.crt" "vpngw.key";

   ca_type x509 "ca.crt";

   passive on;

   generate_policy unique;

   ike_frag on;

   nat_traversal on;

   dpd_delay 30;

   proposal_check claim;

   lifetime time 24 hours;

   proposal

   {

       encryption_algorithm aes 256;

       hash_algorithm sha1;

       authentication_method xauth_rsa_server;

       dh_group 5;

   }

}

remote 1.2.3.4

{

...

}

exchange_mode (main | aggressive | base);

Defines the exchange mode for phase 1 when racoon is the initiator. It also means the acceptable exchange mode when racoon is responder.  More than one mode can be specified by separating them with a comma. All of the modes are acceptable.  The first exchange mode is what racoon uses when it is the initiator.

doi ipsec_doi;

Means to use IPsec DOI as specified in RFC 2407. You can omit this statement.

my_identifier [qualifier] idtype ...;

Specifies the identifier sent to the remote host and the type to use in the phase 1 negotiation.  address, fqdn, user_fqdn, keyid, and asn1dn can be used as an idtype. The qualifier is currently only used for keyid, and can be either file or tag. The possible values are:

peers_identifier idtype ...;

Specifies the peer's identifier to be received. If it is not defined then racoon will not verify the peer's identifier in ID payload transmitted from the peer. If it is defined, the behavior of the verification depends on the flag of verify_identifier.  The usage of idtype is the same as my_identifier except that the individual component values of an asn1dn identifier may be specified as * to match any value (e.g. "C=XX, O=MyOrg, OU=*, CN=Mine"). Alternative acceptable peer identifiers may be specified by repeating the peers_identifier statement.

verify_identifier (on | off);

If you want to verify the peer's identifier, set this to on. In this case, if the value defined by peers_identifier is not the same as the peer's identifier in the ID payload, the negotiation will fail. The default is off.

certificate_type certspec;

Specifies a certificate specification. certspec is one of the following:

ca_type cacertspec;

Specifies a root certificate authority specification. cacertspec is one of the following:

xauth_login [string];

Specifies the login to use in client-side Hybrid authentication. It is available only if racoon has been built with this option. The associated password is looked up in the pre-shared key files, using the login string as the key id.

mode_cfg (on | off);

Gather network information through ISAKMP mode configuration.  Default is off.

weak_phase1_check (on | off);

Tells racoon to act on unencrypted deletion messages for phase 1.  This is a small security risk, so the default is off, meaning that racoon will keep on trying to establish a connection even if the user credentials are wrong, for instance.

peers_certfile (dnssec | certfile | plain_rsa pubkeyfile);

If dnssec is defined, racoon will ignore the CERT payload from the peer, and try to get the peer's certificate from DNS instead.  If certfile is defined, racoon will ignore the CERT payload from the peer, and will use this certificate as the peer's certificate. If plain_rsa is defined, racoon will expect pubkeyfile to be the peer's public key that was generated by plainrsa-gen.

script script phase1_up;

script script phase1_down;

Shell scripts that get executed when a phase 1 SA goes up or down.  Both scripts get either phase1_up or phase1_down as first argument, and the following variables are set in their environment:

The following variables are only set if mode_cfg was enabled:

send_cert (on | off);

If you do not want to send a certificate, set this to off. The default is on.

send_cr (on | off);

If you do not want to send a certificate request, set this to off. The default is on.

verify_cert (on | off);

By default, the identifier sent by the remote host (as specified in its my_identifier statement) is compared with the credentials in the certificate used to authenticate the remote host as follows:

If the two do not match, the negotiation will fail.  If you do not want to verify the identifier using the peer's certificate for some reason, set this to off.

lifetime time number timeunit;

Define a lifetime of a certain time which will be proposed in the phase 1 negotiations. Any proposal will be accepted, and the attribute(s) will not be proposed to the peer if you do not specify it (them).  They can be individually specified in each proposal.

ike_frag (on | off | force);

Enable receiver-side IKE fragmentation if racoon has been built with this feature.  If set to on, racoon will advertise itself as being capable of receiving packets split by IKE fragmentation. This extension is there to work around broken firewalls that do not work with fragmented UDP packets. IKE fragmentation is always enabled on the sender-side, and it is used if the peer advertises itself as IKE fragmentation capable. By selecting force, IKE Fragmentation will be used when racoon is acting as the initiator even before the remote peer has advertised itself as IKE fragmentation capable.

esp_frag fraglen;

This option is only relevant if you use NAT traversal in tunnel mode. Its purpose is to work around broken DSL routers that reject UDP fragments, by fragmenting the IP packets before ESP encapsulation. The result is ESP over UDP of fragmented packets instead of fragmented ESP over UDP packets (i.e., IP:UDP:ESP:frag(IP) instead of frag(IP:UDP:ESP:IP)).  fraglen is the maximum size of the fragments. 552 should work anywhere, but the higher fraglen is, the better the performance.

initial_contact (on | off);

Enable this to send an INITIAL-CONTACT message. The default value is on.  This message is useful only when the implementation of the responder 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.  The KAME stack has the switch in the system wide value net.key.preferred_oldsa. When the value is zero, the stack always uses a new SA.

passive (on | off);

If you do not want to initiate the negotiation, set this to on. The default value is off.  It is useful for a server.

proposal_check level;

specifies the action of lifetime length, key length, and PFS of the phase 2 selection on the responder side, and the action of lifetime check in phase 1. The default level is strict. If the level is:

support_proxy (on | off);

If this value is set to on, then both values of ID payloads in the phase 2 exchange are always used as the addresses of end-point of IPsec-SAs. The default is off.

generate_policy (on | off | require | unique);

This directive is for the responder.  Therefore you should set passive to on in order that racoon only becomes a responder.  If the responder does not have any policy in SPD during phase 2 negotiation, and the directive is set to on, then racoon will choose the first proposal in the SA payload from the initiator, and generate policy entries from the proposal.  It is useful to negotiate with clients whose IP address is allocated dynamically.  Note that an inappropriate policy might be installed into the responder's SPD by the initiator, so other communications might fail if such policies are installed due to a policy mismatch between the initiator and the responder.  The on and require values mean the same thing (generate a require policy).  unique tells racoon to set up unique policies, with a monotoning increasing reqid number (between 1 and IPsec_MANUAL_REQID_MAX).  This directive is ignored in the initiator case.  The default value is off.

nat_traversal (on | off | force);

This directive enables use of the NAT-Traversal IPsec extension (NAT-T).  NAT-T allows one or both peers to reside behind a NAT gateway (i.e., doing address- or port-translation).  Presence of NAT gateways along the path is discovered during phase 1 handshake and if found, NAT-T is negotiated.  When NAT-T is in charge, all ESP and AH packets of a given connection are encapsulated into UDP datagrams (port 4500, by default).  Possible values are:

Please note that NAT-T support is a compile-time option. Although it is enabled in the source distribution by default, it may not be available in your particular build. In that case you will get a warning when using any NAT-T related config options.

dpd_delay delay;

This option activates the DPD and sets the time (in seconds) allowed between 2 proof of liveness requests. The default value is 0, which disables DPD monitoring, but still negotiates DPD support.

dpd_retry delay;

If dpd_delay is set, this sets the delay (in seconds) to wait for a proof of liveness before considering it as failed and sending another request. The default value is 5.

dpd_maxfail number;

If dpd_delay is set, this sets the maximum number of proof of liveness to request (without reply) before considering the peer dead.  The default value is 5.

nonce_size number;

define the byte size of nonce value.  Racoon can send any value although RFC2409 specifies that the value MUST be between 8 and 256 bytes. The default size is 16 bytes.

ph1id number;

An optional number to identify the remote proposal and to link it only with sainfos who have the same number. Defaults to 0.

proposal { sub-substatements }