Scenarios (IPv6 and IP Security) Part 2

Creating Star Topology VPN

The example described in the previous subsection can be extended to an arbitrary number of networks. However, it is not scalable, apparently. One solution for creating a VPN network with a number of networks is to design the network as a star topology.

FIGURE 5-30

FIGURE 5-30

Figure 6-31 is an example of a VPN with a star topology. This figure represents the internal topology of the organization in which the IPv6 block is 2001:db8:100::/48. This organization has 4 sites, A to D. Site A connects to all other sites. Sites B to D are not connected directly to each other.

Setting Up Security Policies

In this example, the following policies are needed.

• All traffic from site A to site B must be tunneled from SG A to SG B.

• All traffic from site A to site C must be tunneled from SG A to SG C.

• All traffic from site A to site D must be tunneled from SG A to SG D.

• All traffic from site B to other sites must be tunneled from SG B to SG A.


• All traffic from site C to other sites must be tunneled from SG C to SG A.

• All traffic from site D to other sites must be tunneled from SG C to SG A.

These policies can be written in a setkey form as Figure 6-32.

If we design the network as a full mesh network as the previous example, we must have 6 policies for each site. This results in 24 policies in total. Using a star topology reduces the number of security policies. In addition, adding a new site is easier than a full mesh topology. In a star topology, we only need to add two policies to add a new site. One policy is from SG A to a new SG, another is from the new SG to SG A. Other SGs need not be modified, while a full mesh topology requires modification on all SGs to add security policies to the newly added SG.

Setting Up racoon

We apply the same parameters used in the previous example.

FIGURE 5-31

FIGURE 5-31

• Phase-I parameters

— lifetime of ISAKMP SA entries is 24 hours

— pre-shared key for authentication

— 3des algorithm for encryption

— sha1 algorithm for integrity

— mpdp1024 group for Diffie-Hellman exponentiation

— always obey an initiator

• Phase-II parameters

— lifetime of IPsec SA entries is 12 hours

— possible encryption algorithms are: 3des, cast128, blowfish with a 448-bit key, des, rijndael

— possible authentication algorithms are: hmac_sha1, hmac_md5

— mpdp1024 group for Diffie-Hellman exponentiation

The configuration file used for this example is not very different from the previous one. Figure 6-33 shows the configuration files for SG A and SG B.

FIGURE 5-32

FIGURE 5-32

Using Transport Mode IP Security

IPsec can be used to enhance end-to-end security by using the transport mode IPsec. In this subsection, we use Figure 6-11 as a reference network and provide configuration files for racoon to create SA entries dynamically.

FIGURE 5-33

FIGURE 5-33

 

 

 

 

 

FIGURE 5-33

In Figure 6-11, there are two nodes. One is node A and the other is POP server B. In this configuration, we consider protecting all POP3 traffic by using transport mode IP security. The configuration of security policies is the same as that described in Figure 6-10. Corresponding racoon configuration files are described in Figure 6-34. We use the same parameters in the previous examples.

FIGURE 6-34

FIGURE 6-34

 

 

 

 

 

FIGURE 6-34

• Phase-I parameters

— lifetime of ISAKMP SA entries is 24 hours

— pre-shared key for authentication

— 3des algorithm for encryption

— sha1 algorithm for integrity

— mpdp1024 group for Diffie-Hellman exponentiation

— always obey an initiator

• Phase-II parameters

— lifetime of IPsec SA entries is 12 hours

— possible encryption algorithms are: 3des, cast128, blowfish with a 448-bit key, des, rijndael

— possible authentication algorithms are: hmac_sha1, hmac_md5

— mpdp1024 group for Diffie-Hellman exponentiation

As we can see, there is no difference between the configuration files for tunnel mode. 6.11.4 Connecting to the Server from Public Access Points

Recently, many Internet Service Providers are offering many access points in various locations. It is natural that we see the demand to use these access points to connect to the VPN server of our office. In this case, the IP address we will have at the access point is not fixed as shown in Figure 6-35. Unlike the previous configurations described before, we cannot specify the exact addresses in the Phase-I setting.

FIGURE 5-35

FIGURE 5-35

FIGURE 6-36

FIGURE 6-36tmp36-349tmp36349_thumb

FIGURE 6-37

FIGURE 6-37

Figure 6-36 shows a part of the Phase-I configuration file of the server side.

The important points of server-side configuration are the following:

• Do not specify peer’s identifier to accept multiple mobile nodes.

• Enable passive mode so that the server never initiates the IKE negotiation. Figure 6-37 shows a part of the Phase-I configuration of the mobile node side.

FIGURE 5-38

FIGURE 5-38

The point of the mobile node side is to specify the identifier as FQDN, not as an IP address. The address may differ depending on the access point that the mobile node attached to. Note that the identifier is used only locally. The value of FQDN need not match the actual domain name of the dynamically assigned address.

Since we use FQDN as their identifiers, the pre-shared secret file must be written based on them. Figure 6-38 shows the pre-shared secret file used in this example.

Next post:

Previous post: