Domain Based VPN

In This Section: Overview of Domain-based VPN VPN Routing and Access Control Configuring VPN Routing in Domain Based VPN

Overview of Domain-based VPN

Domain Based VPN controls how VPN traffic is routed between Security Gateways within a community. To route traffic to a host behind a Security Gateway, you must first define the VPN domain for that Security Gateway. Configuration for VPN routing is done with SmartConsole or in the VPN routing configuration files on the Security Gateways.

In this figure, one of the host machines behind Security Gateway A tries to connect to a host computer behind Security Gateway B. For technical or policy reasons, Security Gateway A cannot establish a VPN tunnel with Security Gateway B. With VPN Routing, Security Gateways A and B can establish VPN tunnels through Security Gateway C.

Item	Description
A	Security Gateway A
B	Security Gateway B
C	Security Gateway C

VPN Routing and Access Control

VPN routing connections are subject to the same access control rules as any other connection. If VPN routing is correctly configured but a Security Policy rule exists that does not allow the connection, the connection is dropped. For example: a Security Gateway has a rule which forbids all FTP traffic from inside the internal network to anywhere outside. When a peer Security Gateway opens an FTP connection with this Security Gateway, the connection is dropped.

For VPN routing to succeed, a single rule in the Security Policy Rule Base must cover traffic in both directions, inbound and outbound, and on the central Security Gateway. To configure this rule, see Configuring the 'Accept VPN Traffic Rule.

Configuring VPN Routing in Domain Based VPN

Configure most common VPN routing scenarios through a VPN star community in SmartConsole.

You can also configure VPN routing between Security Gateways in the Security Management Server configuration file $FWDIR/conf/vpn_route.conf.

You can only configure VPN routing between Security Gateways that belong to a VPN community.

Configuring VPN Routing for Security Gateways in SmartConsole

To configure a VPN Routing in a star community in SmartConsole:

1. On the Star Community window, in the:
   1. Center Gateways section, select the Security Gateway that functions as the "Hub".
   2. Satellite Gateways section, select Security Gateways as the "spokes", or satellites.
2. On the VPN Routing page, Enable VPN routing for satellites section, select one of these options:
   • To center and to other Satellites through center - This allows connectivity between the Security Gateways, for example if the spoke Security Gateways have dynamically assigned IP addresses, and the Hub is a Security Gateway with a static IP address.
   • To center, or through the center to other satellites, to internet and other VPN targets - This allows connectivity between the Security Gateways as well as the ability to inspect all communication passing through the Hub to the Internet.
3. Create an appropriate Access Control Policy rule. Remember: one rule must cover traffic in both directions.
4. NAT the satellite Security Gateways on the Hub if the Hub is used to route connections from Satellites to the Internet.

Configuration in the VPN Configuration File

For more granular control over VPN routing, edit the vpn_route.conf file in the conf directory of the Security Management Server.

The configuration file, vpn_route.conf, is a text file that contains the name of network objects. The format is: Destination, Next hop, Install on Security Gateway (with tabbed spaces separating the elements).

Consider a simple VPN routing scenario consisting of Center gateway (hub) and two Satellite gateways (spokes). All machines are controlled from the same Security Management Server, and all the Security Gateways are members of the same VPN community. Only Telnet and FTP services are to be encrypted between the Satellites and routed through the Center:

Although this can be done easily in a VPN star community, the same goal can be achieved by editing vpn_route.conf:

Destination	Next hop router interface	Install on
Spoke_B_VPN_Dom	Hub_C	Spoke_A
Spoke_A_VPN_Dom	Hub_C	Spoke_B

In this instance, Spoke_B_VPN_Dom is the name of the network object group that contains spoke B's VPN domain. Hub C is the name of the Security Gateway enabled for VPN routing. Spoke_A_VPN_Dom is the name of the network object that represents Spoke A's encryption domain. For an example of how the file appears:

Configuring the 'Accept VPN Traffic Rule'

In SmartConsole:

1. Double click on a Star or Meshed Community.
2. On the Encrypted Traffic page, select Accept all encrypted traffic.
3. In a Star community, choose between accepting encrypted traffic on Both center and satellite gateways or Satellite gateways only.
4. Click OK.

Configuring Multiple Hubs

Consider two Hubs, A and B. Hub A has two spokes, spoke_A1, and spoke_A2. Hub B has a single spoke, spoke_B. In addition, Hub A is managed from Security Management Server A, while Hub B is managed via Security Management Server B:

For the two VPN star communities, based around Hubs A and B:

• Spokes A1 and A2 need to route all traffic going outside of the VPN community through Hub A
• Spokes A1 and A2 also need to route all traffic to one another through Hub A, the center of their star community
• Spoke B needs to route all traffic outside of its star community through Hub B

A_community is the VPN community of A plus the spokes belonging to A. B_community is the VPN community. Hubs_community is the VPN community of Hub_A and Hub_B.

Configuring VPN Routing and Access Control on Security Management Server A

The vpn_route.conf file on Security Management Server 1 looks like this:

Destination	Next hop router interface	Install on
Spoke_B_VPN_Dom	Hub_A	A_Spokes
Spoke_A1_VPN_Dom	Hub_A	Spoke_A2
Spoke_A2_VPN_Dom	Hub_A	Spoke _A1
Spoke_B_VPN_Dom	Hub_B	Hub_A

Spokes A1 and A2 are combined into the network group object "A_spokes". The appropriate rule in the Security Policy Rule Base looks like this:

Source	Destination	VPN	Service	Action
Any	Any	A_Community B_Community Hubs_Community	Any	Accept

Configuring VPN Routing and Access Control on Security Management Server B

The vpn_route.conf file on Security Management Server 2 looks like this:

Destination	Next hop router interface	Install On
Spoke_A1_VPN_Dom	Hub_B	Spoke_B
Spoke_A2_VPN_Dom	Hub_B	Spoke_B
Spoke_A1_VPN_Dom	Hub_A	Hub_B
Spoke_A2_VPN_Dom	Hub_A	Hub_B

The appropriate rule in the Security Policy Rule Base looks like this:

Source	Destination	VPN	Service	Action
Any	Any	B_Community A_Community Hubs_Community	Any	Accept

For both vpn_route.conf files:

• "A_Community" is a star VPN community comprised of Hub_A, Spoke_A1, and Spoke_A2
• "B_Community" is a star VPN community comprised of Hub_B and Spoke_B
• "Hubs-Community" is a meshed VPN community comprised of Hub_A and Hub_B (it could also be a star community with the central Security Gateways meshed).