To create a VPN between two separate organizations (such as two firms working together as partners), it is most likely that an IPSec tunnel is required. This may be to a non-Smoothwall, so a degree of co-ordination is required to decide upon a compatible tunnel specification.

This example uses certificates created by an external, commercial Certificate Authority so that each organization can authenticate certificates presented by the other using a Certificate Authority that is independent of both organizations.

This configuration example assumes the following:



Local Smoothwall.



Host certificates created by the same commercial Certificate Authority.



Host certificate, Certificate A created by the commercial Certificate Authority for the Smoothwall.



Host certificate, Certificate B created by the commercial Certificate Authority for the other organization’s VN gateway.

Firstly, import the certificate created for the local Smoothwall (Certificate A).

Next, configure the local tunnel specification in co-operation with the other organization. This is most likely to be an IPSec site-to-site connection, though it is possible that you could connect to their network as a roadwarrior. In either case, full consultation between both organizations is required to decide on the configuration options to be used on the respective VPN gateways.

Follow these steps to create a site-to-site connection:

1.

Connect to Smoothwall on the Smoothwall and go to the Network > VPN > IPSec subnets page.

2.

In the local tunnel specification, choose Default local cert subject or Default local cert subject alt.name from the Local ID type drop-down list. However, it may be necessary to use user specified values if the other VPN gateway is not directly compatible with the Smoothwall's communication of certificate subjects.

3.

Choose Certificate A from the Local certificate drop-down list to ensure that this tunnel overrides any default local certificate that might be configured.

4.

Choose Certificate provided by peer from the Authenticate by drop-down list. This will ensure that the Smoothwall will authenticate Certificate B when is presented by the other organization’s VPN gateway.

5.

Choose the remote ID type from the Remote ID type drop-down list that was entered during the creation of Certificate B using the commercial Certificate Authority.

6.

Confer with the other organization regarding all other configuration settings and ensure that they authenticate the tunnel using the Certificate Authority's certificate and Certificate A as provided by the Smoothwall as connection time.

A useful feature of the Smoothwall is its ability to use the VPN as a means of linking multiple networks together by creating a centralized VPN hub. The hub is used to route traffic to between different networks and subnets by manipulation of the local and remote network settings in each tunnel specification.

This potentially allows every network to be linked to every other network without the need for a fully routed network of VPN tunnels, that is, a tunnel from every site to every other site. A fully routed network can be awkward to configure and maintain.

This configuration example assumes the following:



Site A – Local network: 192.168.10.0/255.255.255.0 – Tunnel A connects to Site B.



Site B – Local network: 192.168.20.0/255.255.255.0 – Tunnel A connects to Site A, Tunnel C connects to Site C.



Site C – Local network: 192.168.30.0/255.255.255.0 – Tunnel C connects to Site B.

The advantage of this approach is that only one tunnel is required for each remote network. The disadvantage is that the central VPN gateway is now routing traffic not destined for it, thus it requires additional resources for its bandwidth. Also, the central VPN creates a single point of failure in the network. An improved approach would incorporate backup tunnel definitions that could be used to create a fail-over VPN hub elsewhere on the network.

A definition for Tunnel A (connecting Site A to Site B) is required. Use the following local and remote network settings:



Local network – 192.168.10.0/255.255.255.0



Remote network – 192.168.0.0/255.255.0.0

With this configuration, any traffic destined for the Site B network (any address in the range 192.168.20.0 to 192.168.20.255) is routed to Site B, as this range falls within the definition of the remote end of Tunnel A.

Any traffic destined for the Site C network (any address in the range 192.168.30.0 to 192.168.30.255) will also be routed to Site B, as this range also falls within the definition of the remote end of Tunnel A. However, this traffic still needs to be forwarded to Site C to reach its destination – Tunnel C from Site B will ensure this.

First, a definition for Tunnel A (connecting Site B to Site A) is required. Use the following local and remote network settings:



Local network – 192.168.0.0/255.255.0.0



Remote network – 192.168.10.0/255.255.255.0

With this configuration, any traffic destined for the Site A network (any address in the range 192.168.10.0 to 192.168.10.255) is routed to Site A, as this range falls within the definition of the remote end of Tunnel A.

Next, a definition for Tunnel C (connecting Site B to Site C) is required. Use the following local and remote network settings:



Local network – 192.168.0.0/255.255.0.0



Remote network – 192.168.30.0/255.255.255.0

With this configuration, any traffic destined for the Site C network (any address in the range 192.168.30.0 to 192.168.30.255) is routed to Site C, as this range falls within the definition of the remote end of Tunnel C.

A definition for Tunnel C (connecting Site C to Site B) is required. Use the following local and remote network settings:



Local network – 192.168.30.0/255.255.255.0



Remote network – 192.168.0.0/255.255.0.0

With this configuration, any traffic destined for the Site B network (any address in the range 192.168.20.0 to 192.168.20.255) is routed to Site B, as this range falls within the definition of the remote end of Tunnel C.

Any traffic destined for the Site A network (any address in the range 192.168.10.0 to 192.168.10.255) will also be routed to Site B, as this range also falls within the definition of the remote end of Tunnel C. However, this traffic still needs to be forwarded to Site A to reach its destination – Tunnel A from Site B will ensure this.