[Dr.WoW] [No.35] Template IPSec

Latest reply: Aug 18, 2015 02:30:52 2787 1 0 0

Similar to the IKE IPSec policy, the template IPSec policy also must rely on an IKE negotiated IPSec tunnel. The greatest improvement that comes with the template IPSec policy is that it does not require fixed peer IP addresses: a peer IP address can be strictly designated (single IP), broadly designated (IP address segment) or simply left undesignated (i.e. the peer IP can be any IP).

The template IPSec policy is like a valiant general, leaving no peer IP behind enemy lines; fixed, dynamic, private… all are welcome to join the ranks. It's precisely because of this demeanor that the template IPSec policy is suitable for Tiandihui hosts because it allows them to respond to a multitude of sub-host negotiation requests. The benefits become ever more obvious as the ranks of sub-hosts begin to swell:

l   IKE IPSec policy is used. Hosts must configure n-number of IPSec policies and IKE peers, where n equals the number of sub-hosts.

l   Template IPSec policy is used. Hosts only need to configure one IPSec policy and one IKE peer, irrespective of n.

In conclusion, the template IPSec policy's two main advantages secure its ticket to the IPSec "Hall of Fame":

l   For seldom initiation requests, non-fixed public IPs are okay

l   Simple configuration; only one IKE peer is needed

However, even stars have their own unspoken difficulties; template IPSec policies can only respond to peer-initiated negotiation requests and cannot actively initiate negotiations.

1 Point-to-Multi-Point Networking Applications

As shown in Figure 1-1, sub-host 1 and sub-host 2's interfaces use the dynamic method of retrieving public IP addresses. Respective IPSec tunnels must be established between sub-host 1 and the host and sub-host 2 and the host. Moreover, sub-host 1 and sub-host 2 can also communicate through the IPSec VPN.

Figure 1-1 IPSec VPN point-to-multi-point networking

[Dr.WoW] [No.35] Template IPSec-1257395-1

 

The logic behind IPSec Policy template configuration is as shown in Figure 1-2.

Figure 1-2 Schematic of IPSec policy template configuration

[Dr.WoW] [No.35] Template IPSec-1257395-2

 

The template IPSec policy configuration is as shown in Table 1-1. We won't go over IKE and IPSec proposal default configurations again. Sub-host 2 configuration is similar to that of sub-host 1. Simply refer to the sub-host 1 configuration.

Table 1-1 IPSec VPN template configuration

Configuration

Host FW_A (with Template IPSec policy)

Sub-Host 1 FW_B (with IKE IPSec Policy)

IKE proposal Configuration

ike proposal 10

ike proposal 10

IKE Peer Configuration

ike peer a

 ike-proposal 10

pre-shared-key tiandihui1

//can forego remote-address configuration; the remote-address can also be used to designate the IP address segment.

ike peer a

 ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1

ACL

acl number 3000

rule 5 permit ip destination 172.16.1.0 0.0.0.255

rule 10 permit ip destination 172.16.2.0 0.0.0.255

acl number 3000

rule 5 permit ip source 172.16.1.0 0.0.0.255

IPSec Proposal

IPSec proposal a

IPSec proposal a

IPSec Policy

IPSec policy-template tem1 1 //configuration IPSec policy template

 security acl 3000

 proposal a

 ike-peer a

IPSec policy policy1 12 isakmp template tem1//configuration template IPSec policy

IPSec policy policy1 1 isakmp

 security acl 3000

 proposal a

 ike-peer a

IPSec Policy Application

interface GigabitEthernet0/0/2

ip address 1.1.1.1 255.255.255.0

IPSec policy policy1

interface GigabitEthernet0/0/2

ip address 2.2.2.2 255.255.255.0

IPSec policy policy1 auto-neg //once auto-neg is configured, traffic trigger is not needed; IPSec tunnel is established directly.

Route

Route configuration required for each private network exchange of visits

Route configuration required for each private network exchange of visits

 

The configuration above has two differences from the standard IKE method; note the following:

l   Host FW uses template IPSec policy.

The template IPSec policy does not require IKE peers to configure remote-addresses; or remote-addresses can be used to designate IP address segments.

In 32.IKEv1 "Phase 1: Establishing IKE SA (Main Mode)", we discussed the three uses of remote-address, command, and designated IP addresses. Now, let's consider for a moment - if the template IPSec policy does not configure the remote-address command, will it cause confusion? Even if the host gives up its rights, there still won't be any problems:

?       If the host does not configure a remote-address command, there won't be a designated tunneling peer IP address. At this time, the host can only accept active sub-host access and cannot perform sub-host authentication nor can it actively access the sub-host.

?       If the host uses a remote-address to designate the tunneling peer IP address segment, the host can check to see whether the sub-host device ID (IP address) is contained in the IP address segment; requests will only be accepted when the ID is in fact within the segment. Even at this time, the host still cannot actively access the sub-host.

From the two points above it can be seen that the template IPSec policy seems to let hosts get over the issue of "no fixed IP" and "no public IP" peers. But, in fact, this is only achieved when the host actively gives up two rights.

l   ACL configuration is specific; with more sub-hosts, host ACL configuration becomes more complicated.

?       Host FW_A's ACL requirements include two rules:

To allow sub-host 2 and host FW to access sub-host 1 FW, the source must include the sub-host 2 and host network segment, and the destination must be the sub-host 1 network segment. In this case, the source is not designated which means that the source can be sub-host 2 or the host or another IP address segment.

To allow sub-host 1 and the host FW to access the sub-host 2 FW, the source must include the sub-host 1 and host network segment, and the destination must be the sub-host 2 network segment. In this case, there is no designated source which means that the source can be sub-host 1 or the host or another IP address segment.

?       Sub-host FW's ACL requirement:

To allow the sub-host 1 FW to access the sub-host 2 and host FWs, the source must be the sub-host 1network segment, and the destination must be the sub-host 2 and host network segments. In this case, there is no designated destination which means that the source can be sub-host 2 or the host or another IP address segment.

Authentication is performed when configuration is complete:

1.         On the host FW_A, the first and second-phase SAs are normally established between the host and the sub-host 1 and sub-host 2 FWs.

2.         Sub-host 1, sub-host 2, and host can communicate back and forth.

Question: If auto-neg parameters are not configured on the FW_B interface IPSec policy, can sub-host 1 and sub-host 2 communicate directly?

3.         After the IPSec policies are cancelled on the sub-host 1 and sub-host 2 FWs, when re-applied, the auto-neg parameters are not configured. If sub-host 1's PC_B pings sub-host 2's PC_C, the ping will not go through.

4.         Check the status of sub-host 1 FW_B's SA.

<FW_B> display ike sa

current ike sa number: 2

-------------------------------------------------------------------------

conn-id peer flag phase vpn

-------------------------------------------------------------------------

40022 1.1.1.1 RD|ST v2: 2 public

7 1.1.1.1 RD|ST v2: 1 public

The SA established between sub-host 1 and the host is normal.

5.         Check the status of sub-host 2 FW_ C's SA.

<FW_C> display ike sa

current sa Num: 0

There is no SA established between sub-host 2 and the host FW. This is because the host FW configured the template IPSec policy and can only respond to negotiations. As such, sub-host 1 created a normal SA with the host FW, but the host cannot establish an SA with the sub-host 2 FW. Once auto-neg parameters are set up on the IPSec policy applied by the sub-host 1 and sub-host 2 FWs, the IPSec SA will be automatically created. Because SAs are already in place from the sub-host 1 to the host FW and the host to the sub-host 2 FW, sub-host 1 can communicate with sub-host 2. Similarly, he host can send pings to the sub-hosts.

At this point, we have already introduced three different IPSec policies: the manual IPSec policy, IKE IPSec policy, and the template IPSec policy. All three of these IPSec policies can be configured in a single IPSec policy group. This so-called IPSec policy group is a group of IPSec policies with the same name. At most, there can only be one IPSec template in a single IPSec policy group, the serial number of which must also be the largest, set to minimum priority. Otherwise, accession request will first be received by the template IPSec policy; low priority IKE IPSec policies won't have any way to show off their talent.

Template and IKE IPSec policies both need to negotiate IPSec tunnels with IKEs. The negotiation process is the same, and there's no need for Dr. WoW to go over that again. Next, we will focus our discussion on the "characteristics" of the template IPSec policy.

2 Customized Pre-Shared Keys (USG9500-Series Firewall Only)

Only one IKE peer can be cited in the IPSec template. Moreover, a single IKE Peer can only have one pre-shared key configured. As such, all interconnected peers must be configured with the same pre-shared key. Because of this, if even a single firewall leaks the pre-shared key, the security of all other firewalls is compromised.

So, if a host wants to establish interconnected point-to-multi-point networking with multiple sub-hosts, can the sub-host firewalls configure different pre-shared keys? Since the pre-shared key is associated with key generation and identity authentication, the pre-shared key only needs to be linked to the device identity, and identity authentication can be performed with the pre-shared key authentication method for the local IP address or device name. When an IP address or a device name is used to designate a pre-shared key, a "customized pre-shared key" can be configured for each sub-host firewall.

l   Customized pre-shared key designation through peer IP address for each sub-host firewall

This method is suitable for sub-host firewalls with fixed IP addresses. The host firewall ike peer configured remote-address and pre-shared-key are deleted and changed globally so that each sub-host firewall has its own remote-address and pre-shared-key. In this way, the template method can stay ahead of the game and cleverly circumvent its limitations.

Table 1-2 Customized pre-shared key designation through peer IP address

Configuration

Host FW_A

Sub-Host 1 FW_B

IKE Peer Configuration

ike peer a

 local-id-type ip

ike-proposal 10

ike peer a

 local-id-type ip

ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1

Customized Pre-Shared Key Configuration

ike remote-address 2.2.2.2 pre-shared-key tiandihui1

ike remote-address 2.2.3.2 pre-shared-key tiandihui2

-

 

l   Pre-shared key name designation through peer device

When the sub-host firewall does not have a fixed IP address, the device name can be used to verify the identity (ike local-name). At this time, host firewall can then globally configure a unique remote-id and pre-shared-key for each sub-host firewall.

Table 1-3 Customized pre-shared key name designation through peer device

Configuration

Host FW_A

sub-host 1 FW_B

IKE Peer Configuration

ike peer a

 local-id-type ip

ike-proposal 10

ike peer a

 local-id-type fqdn // when identity authentication is performed via the device name, the local authentication must be configured to FQDN or USER-FQDN.

ike-proposal 10

remote-address 1.1.1.1

 pre-shared-key tiandihui1

Local Name Configuration

-

ike local-name tdhfd1

Customized Pre-Shared Key Configuration

ike remote-id tdhfd1 pre-shared-key tiandihui1

ike remote-id tdhfd2 pre-shared-key tiandihui2

-

 NOTE: The host FW_A configured "ike remote-id" must be the same as the sub-host 1 FW_B configured "ike local-name".

3 Designated Peer Domain Name Usage

When a sub-host firewall is accessed with a dynamic IP address, are IKE IPSec policy's hands tied?

In fact, there's also a method out there that can help the IKE IPSec policy: when the peer IP address is not fixed, naturally, a remote-address cannot be configured, but the host can still learn the IP address through other indirect methods, such as through the domain name. In other words, the host can use a designated remote-domain to replace the remote-address; the sub-host firewall configured DNS will then obtain a mapping relationship between the domain name and IP address, and use the DDNS to ensure that the mapping relationship is constantly updated. Of course, dynamically configured domain names can also be used with the template IPSec policy.

Table 1-4 Peer domain name designation in IKE peer

Configuration Adjustments

Host FW_A

Sub-Host 1 FW_B

IPSec Configuration

Only IKE Peer configuration changes

ike peer a

 ike-proposal 10

pre-shared-key tiandihui1

remote-domain www.adcd.3322.org

No changes

Additional Configuration

-

1.    Start domain name resolution

dns resolve

dns server 200.1.1.1

2.    Configure DDNS policy //the following configuration requires contact with the DDNS service provider and must be performed according to the DDNS service provider's instructions.

ddns policy abc

ddns client www.adcd.3322.org

ddns server www.3322.org

ddns username abc123 password abc123

3.    Apply DDNS policy //dialer port is the logical interface that corresponds to the ADSL interface. This solution has relatively more applications for sub-host ADSL dial-up ports; in this case, the sub-host DDNS policy will apply to the dialer port.

ddns client enable

interface dialer 1

ddns apply policy abc

 

The limitation of this solution is that the dynamic access parties must have a fixed domain name and must also add DNS and DDNS configurations, which is a little complicated. As such, it's not as useful as the template IPSec policy. Only use this method when you have no other choice.

4 Summary

So just how great is the template IPSec policy? In practical situations, it's not fighting the battle alone, and the war can only be won if the template and IKE IPSec policies work together. Their compatibility is as shown in Table 1-5.

Table 1-5 Template IPSec policy and IKE IPSec policy compatibility

Scenario

Host FW_A

Sub-Host FW_B

Host IP address fixed + sub-host IP address fixed

IKE IPSec policy or template IPSec policy

IKE IPSec policy

Host IP address fixed + sub-host IP address dynamically assigned

Template IPSec policy or IKE IPSec policy (designated peer domain name)

IKE IPSec policy

Host IP address dynamically assigned + sub-host IP address dynamically assigned

Template IPSec policy or IKE IPSec policy (designated peer domain name)

IKE IPSec policy (designated peer domain name)

 

The template IPSec policy truly is quite powerful, and only with this shield in hand can the host FW connect to sub-host FWs, worry-free, regardless of whether they're using public IP addresses, fixed configuration, or even dynamic addresses. However, after taking a closer look, we can see that the template IPSec policy takes different approaches to public and private IP addresses. When the peer is a private IP address, the template IPSec policy still has to take some other steps to get everything in order!

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

Wayne
Created Aug 18, 2015 02:30:52 Helpful(0) Helpful(0)

thank you for sharing this post
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login