Remote Section

A Remote section is used to configure the parameters required to establish an ISAKMP SA with a given Peer. It also contains some additional parameters that control some features that are useful for VPN Client connectivity.

Two configuration examples are shown below. The first can be used for PSK authentication and the second can be used for RSA.

A remote section can be defined using an address value or anonymous immediately following the remote keyword as shown below:

When IKE communications are initiated with your VPN Gateway, racoon will first attempt to select a remote section that matches the Peer address. If no remote section was found, racoon will select an anonymous remote section if available. A remote section that supports Site to Site VPN connectivity would specify the Peer Gateway address. A remote section that supports VPN Client connectivity would use anonymous as the Peer Client address will be unknown.

The allowed exchange modes can be defined as main, aggressive or a comma separated list of several modes. Due to the payload information contained in an initial aggressive mode packet, the hash algorithm and DH group parameters cannot be auto-negotiated between a VPN Client and a Gateway. It is recommended that main mode be used whenever possible.

The identifier verification setting can be defined as on or off. If set to off, the Peer identity value will not be compared with the locally defined peer identifier value. It is recommended that identifier verification be enabled whenever possible.

A remote section that supports preshared key authentication will always use an aggressive mode exchange with a Fully Qualified Domain Name or a User Fully Qualified Domain Name identification type. The IKE protocol standard only allows an address identity type to be used with the combination of main mode and preshared key authentication. Using an identity value to lookup the preshared key would be impossible since the address value will be unknown until an initial packet is received. This prevents main mode and preshared key authentication from being used with a dynamically addressed Client.

In our example, the exchange mode is defined as aggressive and two Fully Qualified Domain Name identifier values are specified. The my_identifier value will be sent to the Peer for validation. The peers_identifier value will be used to validate the identity value received from the Peer. Lastly, the proposal is defined using the xauth_psk_server authentication method.

A remote section that supports RSA authentication can use a main or aggressive mode exchange with an asn1dn identification type. Racoon should verify the identity value against the Peer certificate subject value which prevents you from using an alternate identity type.

In our example, the exchange mode is defined as main and both the local and Peer identifier types are specified as asn1dn. When the asn1dn type is used and no value is specified, racoon will automatically use the subject name from the certificate as an identification value. The certificate_type statement is used to specify the Gateway certificate information which includes the certificate format, the certificate file name and the certificate private key file name. The ca_type statement is used to specify the certificate authority that will be used to verify the client certificate which includes the certificate authority format and the certificate authority file name. Lastly, the proposal is defined using the xauth_rsa_server authentication method.

The passive setting can be defined as either on or off. If set to on, racoon will not attempt to initiate negotiations with a remote peer. A remote section that supports VPN Client connectivity should enable passive mode whenever possible.

The policy generation setting can be defined as require, unique or off. When defined as require or unique, racoon will generate a policy on behalf of a peer during phase 2 negotiations if an appropriate policy does not already exist. Using unique instead of require will force racoon to generate a separate security association for each outbound policy used by a client. When defined as off, policy generation will not be performed. A remote section that supports VPN Client connectivity should use unique policy generation.

The IKE fragmentation setting can be defined as either on or off. If set to on, racoon will allow the IKE fragmentation to be used which is helpful when communicating with a client behind a troublesome firewall or router. It is recommended that IKE fragmentation be enabled whenever possible.

The NAT Traversal setting can be defined as either on or off. If set to on, racoon will allow the NAT Traversal to be used which is helpful when communicating with a client behind a firewall or router that performs Network Address Translation. It is recommended that NAT Traversal be enabled whenever possible.

The DPD delay value can be defined to enable Dead Peer Detection. The value specifies how many seconds racoon should wait between attempts to validate that a Client is still connected to the Gateway. Dead Peer Detection is useful in preventing unnecessary Gateway resources being dedicated to a Client connection that is no longer active. It is recommended that DPD be enabled whenever possible.

The proposal check setting can be defined as obey, strict, claim or exact. If obey is used, a responder will always use the initiators lifetime value. If strict is used, a responder will use the initiators lifetime value if it is shorter than the responders. A responder will reject the proposal if the initiators value is greater than the responders. If claim is used, a responder will use the initiators lifetime value if it is shorter than the responders. A responder will use its own value if it is shorter than the initiators. In the second case, the responder will send a responder lifetime notification to the initiator when responding to a phase 2 proposal. If exact is used, a responder will reject the proposal if the initiators value is not equal to the responders. It is recommended that proposal check be set to claim whenever possible.

The lifetime setting is defined as a value and a time unit of seconds, minutes or hours. The value specifies the ISAKMP Security Association lifetime and will be used to compare with the Peer proposed lifetime during phase 1 negotiations.

A remote section must define at least one proposal subsection that contains a list of statements. The statements define the parameters used to negotiate an ISAKMP SAs with Peers during phase 1 negotiations.

The proposal encryption algorithm can be defined as aes, 3des, blowfish, cast128 or des.

The proposal authentication method can be defined as pre_shared_key, rsasig, hybrid_rsa_server, xauth_rsa_server or xauth_psk_server. It is recommended that the authentication method be set to hybrid or an xauth mode to enable user based authentication.

Specifies the IKE phase 1 parameters for each remote node. The default port is 500. If anonymous is specified, the statements apply to all peers which do not match any other remote directive.

Sections with inherit parent statements ( where parent is either an address or the anonymous keyword ) have all values predefined to those of a given parent. In these sections, it is enough to redefine only the changed parameters.

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:

my_identifier address [address];	The type is the IP address. This is the default type if you do not specify an identifier to use.
my_identifier user_fqdn string;	The type is a USER_FQDN (user fully-qualified domain name).
my_identifier fqdn string;	The type is a FQDN (fully-qualified domain name)
my_identifier keyid [file] file;	The type is a KEY_ID, read from the file.
my_identifier keyid tag string;	The type is a KEY_ID, specified in the quoted string.
my_identifier asn1dn [string];	The type is an ASN.1 distinguished name. If string is omitted, racoon will get the DN from the Subject field in the certificate.

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:

x509 certfile privkeyfile;	certfile means a file name of a certificate. privkeyfile means a file name of a secret key.
plain_rsa privkeyfile;	privkeyfile means a file name of a private key generated by plainrsa-gen. Required for RSA authentication.

ca_type cacertspec;

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

x509 cacertfile;

cacertfile means a file name of the root certificate authority. Default is /etc/openssl/cert.pem

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:

LOCAL_ADDR	The local address of the phase 1 SA.
LOCAL_PORT	The local port used for IKE for the phase 1 SA.
REMOTE_ADDR	The remote address of the phase 1 SA.
REMOTE_PORT	The remote port used for IKE for the phase 1 SA.

The following variables are only set if mode_cfg was enabled:

INTERNAL_ADDR4	An IPv4 internal address obtained by ISAKMP mode config.
INTERNAL_NETMASK4	An IPv4 internal netmask obtained by ISAKMP mode config.
INTERNAL_CIDR4	An IPv4 internal netmask obtained by ISAKMP mode config, in CIDR notation.
INTERNAL_DNS4	The first internal DNS server IPv4 address obtained by ISAKMP mode config.
INTERNAL_DNS4_LIST	A list of internal DNS servers IPv4 address obtained by ISAKMP mode config, separated by spaces.
INTERNAL_WINS4	The first internal WINS server IPv4 address obtained by ISAKMP mode config.
INTERNAL_WINS4_LIST	A list of internal WINS servers IPv4 address obtained by ISAKMP mode config, separated by spaces
SPLIT_INCLUDE	The space separated list of IPv4 addresses and masks (address slash mask) that define the networks to be encrypted (as opposed to the default where all the traffic should be encrypted); obtained by ISAKMP mode config.
SPLIT_LOCAL	The space separated list of IPv4 addresses and masks (address slash mask) that define the networks to be considered local, and thus excluded from the tunnels; obtained by ISAKMP mode config.
DEFAULT_DOMAIN	The DNS default domain name obtained by ISAKMP mode config.

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:

Type asn1dn:	The entire certificate subject name is comparedwith the identifier, e.g. "C=XX, O=YY, ...".
Type address, fqdn, or user_fqdn:	The certificate's subjectAltName is compared with the identifier.

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:

obey	The responder will obey the initiator anytime.
strict	If the responder's lifetime length is longer than the initiator's one, or if responder's key length is shorter than the initiator's one, the responder uses the initiator's. Otherwise it rejects the proposal. If PFS is not required by the responder, the responder will obey the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's, then the responder will reject the proposal.
claim	If the responder's length is longer than the initiator's, or if responder's key length is shorter than the initiator's one, the responder will use the initiator's. If the responder's length is shorter than the initiator's, the responder uses its own length AND sends a RESPONDER-LIFETIME notify message to an initiator in the case of lifetime (phase 2 only). For PFS, this directive behaves the same as strict.
exact	If the initiator's lifetime or key length is not equal to the responder's, the responder will reject the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's, then the responder will reject the proposal.

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:

on	NAT-T is used when a NAT gateway is detected between the peers.
off	NAT-T is not proposed/accepted. This is the default.
force	NAT-T is used regardless of whether NAT is detected between the peers or not.

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 optionnal number to identify the remote proposal and to link it only with sainfos who have the same number. Defaults to 0.

proposal { sub-substatements }

encryption_algorithm algorithm;	Specifies the encryption algorithm used for the phase 1 negotiation. This directive must be defined. algorithm is one of following: des, 3des, blowfish, cast128, aes, camellia for Oakley. For other transforms, this statement should not be used.
hash_algorithm algorithm;	Defines the hash algorithm used for the phase 1 negotiation. This directive must be defined. algorithm is one of following: md5, sha1, sha256, sha384, sha512 for Oakley.
authentication_method type;	Defines the authentication method used for the phase 1 negotiation. This directive must be defined. type is one of: pre_shared_key, rsasig (for plain RSA authentication), gssapi_krb, hybrid_rsa_server, hybrid_rsa_client, xauth_rsa_server, xauth_rsa_client, xauth_psk_server or xauth_psk_client.
dh_group group;	Defines the group used for the Diffie-Hellman exponentiations. This directive must be defined. group is one of following: modp768, modp1024, modp1536, modp2048, modp3072, modp4096, modp6144, modp8192. Or you can define 1, 2, 5, 14, 15, 16, 17, or 18 as the DH group number. When you want to use aggressive mode, you must define the same DH group in each proposal.
lifetime time number timeunit;	Defines the lifetime for the phase 1 SA proposal. Refer to the description of the lifetime directive defined in the remote directive.
gss_id string;	Defines the GSS-API endpoint name, to be included as an attribute in the SA if the gssapi_krb authentication method is used. If this is not defined, the default value of `host/hostname' is used, where hostname is the value returned by the hostname command.