Typically, you use a tunnel address to hide the internal topology of a network. It can also be used when an internal network uses illegal or unroutable IP addresses to enable the packet to be routed over the Internet.
You can configure tunneling and use encryption on a Screen in routing mode as well as in stealth mode.
For the network example, FIGURE 5-1 shows the Boston and Hong-Kong segments of the network. Looking at the diagram, a VPN is configured between the Boston and Hong-Kong offices. It shows tunnel addresses between the stealth Screen (bos-screen1) and the routing Screen (hk-screen1). SunScreen SKIP encrypts the entire original packet, including the IP header, and inserts a new IP header. The new IP header can use either the same addresses as the original packet or different (or tunnel) addresses.
The hosts in Boston have non-routable addresses (10.0.2.0 in this example), so a tunnel address is used to hide these addresses. The stealth Screen in Boston (bos-screen1) has no IP address on its filtering interface (hme2). Thus, when the Screen in Hong-Kong inserts a new IP header on packets destined for bos-screen1, it adds a tunnel address on the 192.168.1.0 subnet and routes the packet over the Internet to the Boston router. Although bos-screen1 does not have an IP address, it responds to ARPs from the Boston router for the tunnel address so the packets from hk-screen1 are passed to bos-screen1 and decrypted.
Encryption and decryption are done by the hk-screen1 and bos-screen1 Screens. Thus, if someone ran snoop on the packets on the Internet, they would only see encrypted IP packets (Protocol 57). While, if someone ran snoop on the packets on the inside of either Screen they would find them unencrypted and using their original IP addresses.
Before you begin this example, set up an open policy on both Screens and confirm that they can communicate.
Install SunScreen on both Screens.
Define the tunnel address of the stealth Screen.
Define the address of the routing Screen as an address object.
Define the networks behind each Screen.
Add the certificate of bos-screen1 to the configuration of hk-screen1.
Add the certificate of hk-screen1 to the configuration of bos-screen1.
Add rules to encrypt traffic between the two networks to both of the Screen configurations.
Install bos-screen1 as a stealth Screen.
Follow the installation as described in the Stealth Mode example.
Install hk-scree1 as a routing Screen.
Follow the installation as described in the Routing Mode example.
If both Screens are installed using remote administration, then the installation process generated a certificate ID (local identity) for both Screens. The default name for this certificate is screenname .admin. For example: bos-screen1.admin.
Make sure both Screens have a local certificate ID. If they do not, generate a certificate ID using the administration GUI (that is, use Certificate --> Generate Screen Certificate).
Decide on a tunnel address for the Screen.
This is the IP address that is used to send packets over the Internet. The tunnel address should be on the local network that bos-screen1 is connected to (192.168.1.100 in this example).
Define the tunnel address of bos-screen1 as an address object called bos-tunnel.
Make sure that the interface group definition for the external interface contains the tunnel address object (that is, hme2_grp contains bos-tunnel).
Define an address object for the other Screen in the configuration (hk-screen in this example).
The address of this object is the IP address of the interface nearest the Internet (192.168.6.2 in this example).
It is possible to define a tunnel address for hk-screen1 as well.
Define the networks (bos-net and hk-net in this example) behind both Screens as address objects.
Make sure the interface groups for the interfaces on bos-screen are correctly defined.
The interface definition for the interface nearest the Internet (hme2) needs to have the router field filled in, as shown in Figure 6-2, with the address of a default router on this network (192.168.1.1 in this example). This is required because the stealth Screen is actually generating packets with a source IP address set to the tunnel address, but it has no routing table (because it is not a router) and therefore needs to send the packets to a router that knows where "hk-screen1" is.
Add the certificate name of hk-screen1.
To generate a certificate object called hk-screen1.cert, use Certificate --> Associate MKID.
Add a rule to encrypt the traffic between bos-net and hk-net.
The following figure, Figure 6-4, and Figure 6-5 show the parameters used. The example uses Common Services, but the actual service you use reflects the security policy that you are implementing.
The configuration shows a second rule as well. The first rule enables connections from bos-net to be established to hk-net, and the return packets to pass, but does not enable connections to be established from hk-net to bos-net. If this is required, add a second rule, but reverse the source and destination addresses, and the certificates.
Save and activate the policy.
For SunScreen SKIP encryption to work, both Screens must have the same system time set. When they are located in different parts of the world, the time set should be correct for that part of the world. Also, set the TimeZone for that part of the world. That is, the local time that is corrected with the TimeZone must be the same on both machines.
Check that the pass-CDP (Certificate Discovery Protocol) option is selected under the Screen object.
Define an address object for the other Screen in the configuration (bos-screen in this example).
The address of this object is the tunnel address.
Define the networks behind both Screens as address objects (that is, bos-net and hk-net).
Add the certificate name for bos-screen1.
Use Certificate --> Associate MKID to generate a certificate object called bos-screen1.cert.
Add a rule to the configuration to encrypt the traffic between bos-net and hk-net.
The following figure, Figure 6-7, and Figure 6-8 show the parameters used. The example uses Common Services, but the actual service you use reflects the security policy that you are implementing.
Add a rule to pass CDP in the clear before the encryption rules.
Save and activate the policy.