Go to main content

Securing the Network in Oracle® Solaris 11.3

Exit Print View

Updated: April 2019
 
 

Configuring IKEv1 for Mobile Systems

IPsec and IKE require a unique ID to identify source and destination. For off-site or mobile systems that do not have a unique IP address, you must use another ID type. ID types such as DNS, DN, or email can be used to uniquely identify a system.

Off-site or mobile systems that have unique IP addresses are still best configured with a different ID type. For example, if the systems attempt to connect to a central site from behind a NAT box, their unique addresses are not used. A NAT box assigns an arbitrary IP address, which the central system would not recognize.

Preshared keys also do not work well as an authentication mechanism for mobile systems, because preshared keys require fixed IP addresses. Self-signed certificates, or certificates from a CA enable mobile systems to communicate with the central site.

The following task map lists procedures to configure IKEv1 to handle systems that log in remotely to a central site.

Table 16  Configuring IKEv1 for Mobile Systems Task Map
Task
Description
For Instructions
Communicate with a central site from off-site.
Enables off-site systems to communicate with a central site. The off-site systems might be mobile.
Use a CA's public certificate and IKEv1 on a central system that accepts traffic from mobile systems.
Configures a gateway system to accept IPsec traffic from a system that does not have a fixed IP address.
Use a CA's public certificate and IKEv1 on a system that does not have a fixed IP address.
Configures a mobile system to protect its traffic to a central site, such as company headquarters.
Use self-signed certificates and IKEv1 on a central system that accepts traffic from mobile systems.
Configures a gateway system with self-signed certificates to accept IPsec traffic from a mobile system.
Use self-signed certificates and IKEv1 on a system that does not have a fixed IP address.
Configures a mobile system with self-signed certificates to protect its traffic to a central site.

How to Configure IKEv1 for Off-Site Systems

Before You Begin

You must assume the root role. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3. If you administer remotely, see Example 31, Configuring IPsec Policy Remotely by Using an ssh Connection and How to Remotely Administer ZFS With Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3 for secure remote login instructions.

  1. Configure the central system to recognize mobile systems.
    1. Configure the ipsecinit.conf file.

      The central system needs a policy that allows a wide range of IP addresses. Later, certificates in the IKE policy ensure that the connecting systems are legitimate.

      # /etc/inet/ipsecinit.conf on central
      # Keep everyone out unless they use this IPsec policy:
      {} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
    2. Configure the IKEv1 configuration file.

      DNS identifies the central system. Certificates are used to authenticate the system.

      ## /etc/inet/ike/ike.config on central
      # Global parameters
      #
      # Find CRLs by URI, URL, or LDAP
      # Use CRL from organization's URI
      use_http
      #
      # Use web proxy
      proxy "http://somecache.domain:port/"
      #
      # Use LDAP server
      ldap_server   "ldap-server1.example.org,ldap2.example.org:port"
      #
      # List CA-signed certificates
      cert_root    "C=US, O=Domain Org, CN=Domain STATE"
      #
      # List self-signed certificates - trust server and enumerated others
      #cert_trust    "DNS=central.example.org"
      #cert_trust    "DNS=mobile.example.org"
      #cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
      #cert_trust    "email=root@central.example.org"
      #cert_trust    "email=user1@mobile.example.org"
      #
      
      # Rule for mobile systems with certificate
      {
        label "Mobile systems with certificate"
        local_id_type DNS
      # CA's public certificate ensures trust,
      # so allow any remote_id and any remote IP address.
        remote_id ""
        remote_addr 0.0.0.0/0
      
      p2_pfs 14
      
      p1_xform
      {auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256 }
      }
  2. Log in to each mobile system, and configure the system to find the central system.
    1. Configure the /etc/hosts file.

      The /etc/hosts file does not need an address for the mobile system, but can provide one. The file must contain a public IP address for the central system, central.

      # /etc/hosts on mobile
      central 192.xxx.xxx.x
    2. Configure the ipsecinit.conf file.

      The mobile system needs to find the central system by its public IP address. The systems must configure the same IPsec policy.

      # /etc/inet/ipsecinit.conf on mobile
      # Find central
      {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
    3. Configure the IKEv1 configuration file.

        The identifier cannot be an IP address. The following identifiers are valid for mobile systems:

      • DN=ldap-directory-name

      • DNS=domain-name-server-address

      • email=email-address

      Certificates are used to authenticate the mobile system, mobile.

      ## /etc/inet/ike/ike.config on mobile
      # Global parameters
      #
      # Find CRLs by URI, URL, or LDAP
      # Use CRL from organization's URI
      use_http
      #
      # Use web proxy
      proxy "http://somecache.domain:port/"
      #
      # Use LDAP server
      ldap_server   "ldap-server1.example.org,ldap2.example.org:port"
      #
      # List CA-signed certificates
      cert_root    "C=US, O=Domain Org, CN=Domain STATE"
      #
      # Self-signed certificates - trust me and enumerated others
      #cert_trust    "DNS=mobile.example.org"
      #cert_trust    "DNS=central.example.org"
      #cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
      #cert_trust    "email=user1@example.org"
      #cert_trust    "email=root@central.example.org"
      #
      # Rule for off-site systems with root certificate
      {
      	label "Off-site mobile with certificate"
      	local_id_type DNS
      
      # NAT-T can translate local_addr into any public IP address
      # central knows me by my DNS
      
      	local_id "mobile.example.org"
      	local_addr 0.0.0.0/0
      
      # Find central and trust the root certificate
      	remote_id "central.example.org"
      	remote_addr 192.xxx.xxx.x
      
      p2_pfs 14
      
      p1_xform
      {auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256 }
      }
  3. Enable the ike:default service.
    # svcadm enable svc:/network/ipsec/ike:default
Example 48  Configuring a Central Computer That Uses IKEv1 to Accept Protected Traffic From a Mobile System

IKE can initiate negotiations from behind a NAT box. However, the ideal setup for IKE is without an intervening NAT box. In the following example, the CA's public certificate has been placed on the mobile system and the central system. A central system accepts IPsec negotiations from a system behind a NAT box. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 49, Configuring a System Behind a NAT With IPsec and IKEv1.

## /etc/hosts on main1
main1 192.0.2.100
## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.example.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.example.org,ldap2.example.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExampleCA Inc, OU=CA-Example, CN=Example CA"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.example.org"
  local_addr 192.0.2.100

# CA's public certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 14

p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256}
p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256}
p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256}
p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256}
}
Example 49  Configuring a System Behind a NAT With IPsec and IKEv1

In the following example, the CA's public certificate is placed on the mobile system and the central system. mobile1 is connecting to the company headquarters from home. The Internet service provider (ISP) network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. For setting up the computer at company headquarters, see Example 48, Configuring a Central Computer That Uses IKEv1 to Accept Protected Traffic From a Mobile System.

## /etc/hosts on mobile1
mobile1 192.0.2.3
main1 192.0.2.100
## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.0.2.100} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.example.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.example.org,ldap2.example.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExampleCA Inc, OU=CA-Example, CN=Example CA"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.example.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.example.org"
  remote_addr 192.0.2.100

p2_pfs 14

p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256 }
}
Example 50  Accepting Self-Signed Certificates From a Mobile System

In the following example, self-signed certificates have been issued and are on the mobile and the central system. main1 is the company system that can accept connections from off-site systems. To set up the off-site systems, see Example 51, Using Self-Signed Certificates to Contact a Central System.

## /etc/hosts on main1
main1 192.0.2.100
## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.example.org"
cert_trust    "jdoe@example.org"
cert_trust    "user2@example.org"
cert_trust    "user3@example.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.example.org"
  local_addr 192.0.2.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 14

p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256 }
}
Example 51  Using Self-Signed Certificates to Contact a Central System

In the following example, mobile1 is connecting to the company headquarters from home. The certificates have been issued and placed on the mobile and the central system. The ISP network uses a NAT box to enable the ISP to assign mobile1 a private address. The NAT box then translates the private address into a public IP address that is shared with other ISP network nodes. Company headquarters is not behind a NAT. To set up the computer at company headquarters, see Example 50, Accepting Self-Signed Certificates From a Mobile System.

## /etc/hosts on mobile1
mobile1 192.0.2.3
main1 192.0.2.100
## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.0.2.100} ipsec {encr_algs aes encr_auth_algs sha256 sa shared}
## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@example.org"
cert_trust    "DNS=main1.example.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@example.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.example.org"
  remote_addr 192.0.2.100

p2_pfs 14

p1_xform
{auth_method rsa_sig oakley_group 14 encr_alg aes auth_alg sha256 }
}

Next Steps

If you have not completed establishing IPsec policy, return to the IPsec procedure to enable or refresh IPsec policy. For examples of IPsec policy protecting VPNs, see Protecting a VPN With IPsec. For other examples of IPsec policy, see How to Secure Network Traffic Between Two Servers With IPsec.