Print Download PDF Send Feedback

Previous

Next

Route Based VPN

In This Section:

Overview of Route-based VPN

VPN Tunnel Interface (VTI)

Using Dynamic Routing Protocols

Configuring Numbered VTIs

VTIs in a Clustered Environment

Configuring VTIs in a Clustered Environment

Enabling Dynamic Routing Protocols on VTIs

Configuring VTIs in a Gaia Environment

Configuring Anti-Spoofing on VTIs

Configuring Unnumbered VTIs

Routing Multicast Packets Through VPN Tunnels

Overview of Route-based VPN

The use of VPN Tunnel Interfaces (VTI) is based on the idea that setting up a VTI between peer Security Gateways is similar to connecting them directly.

A VTI is an operating system level virtual interface that can be used as a Security Gateway to the VPN domain of the peer Security Gateway. Each VTI is associated with a single tunnel to a Security Gateway. The tunnel itself with all of its properties is defined, as before, by a VPN Community linking the two Security Gateways. Configure the peer Security Gateway with a corresponding VTI. The native IP routing mechanism on each Security Gateway can then direct traffic into the tunnel as it would for other interfaces.

All traffic destined to the VPN domain of a peer Security Gateway is routed through the "associated" VTI. This infrastructure allows dynamic routing protocols to use VTIs. A dynamic routing protocol daemon running on the Security Gateway can exchange routing information with a neighboring routing daemon running on the other end of an IPsec tunnel, which appears to be a single hop away.

Route Based VPN can only be implemented between two Security Gateways within the same community.

To deploy Route Based VPN, Directional Rules have to be configured in the Rule Base of the Security Management Server.

VPN Tunnel Interface (VTI)

A VPN Tunnel Interface is a virtual interface on a Security Gateway that is related to a VPN tunnel and connects to a remote peer. You create a VTI on each Security Gateway that connects to the VTI on a remote peer. Traffic routed from the local Security Gateway via the VTI is transferred encrypted to the associated peer Security Gateway.

In this scenario:

A virtual interface behaves like a point-to-point interface directly connected to the remote peer. Traffic between network hosts is routed into the VPN tunnel with the IP routing mechanism of the Operating System. Security Gateway objects are still required, as well as VPN communities (and access control policies) to define which tunnels are available. However, VPN encryption domains for each peer Security Gateway are no longer necessary. The decision whether or not to encrypt depends on whether the traffic is routed through a virtual interface. The routing changes dynamically if a dynamic routing protocol (OSPF/BGP) is available on the network.

When a connection that originates on GWb is routed through a VTI to GWc (or servers behind GWc) and is accepted by the implied rules, the connection leaves GWb in the clear with the local IP address of the VTI as the source IP address. If this IP address is not routable, return packets will be lost.

The solution for this issue is:

Having excluded those IP addresses from route-based VPN, it is still possible to have other connections encrypted to those addresses (i.e. when not passing on implied rules) by using domain based VPN definitions.

The VTI can be configured in two ways:

Numbered VTI

You configure a local and remote IP address for each numbered VPN Tunnel Interface (VTI). For each Security Gateway, you configure a local IP address, a remote address, and the local IP address source for outbound connections to the tunnel. The remote IP address must be the local IP address on the remote peer Security Gateway. More than one VTI can use the same IP Address, but they cannot use an existing physical interface IP address.

Unnumbered VTI

For unnumbered VTIs, you define a proxy interface for each Security Gateway. Each Security Gateway uses the proxy interface IP address as the source for outbound traffic. Unnumbered interfaces let you assign and manage one IP address for each interface. Proxy interfaces can be physical or loopback interfaces.

Using Dynamic Routing Protocols

VTIs allow the ability to use Dynamic Routing Protocols to exchange routing information between Security Gateways. The Dynamic Routing Protocols supported on Gaia are:

Configuring Numbered VTIs

Route Based VPN can only be implemented between two Security Gateways within the same community.

Enabling Route Based VPN

If you configure a Security Gateway for Domain Based VPN and Route Based VPN, Domain Based VPN takes precedence by default. To force Route Based VPN to take priority, you must create a dummy (empty) group and assign it to the VPN domain.

To force Route-Based VPN to take priority:

  1. In SmartConsole, from the left navigation panel, click Gateways & Servers.
  2. Open the Security Gateway / Cluster object.
  3. From the left tree, click Network Management > VPN Domain.
  4. Select Manually define.
  5. Click the [...] button.
  6. Click New > Group > Simple Group.
  7. Enter a Name.
  8. Click OK (leave this Group object empty).

Configuring Numbered VTIs

With the new VPN Command Line Interface (VPN Shell), the administrator creates a VPN Tunnel Interface on the enforcement module for each peer Security Gateway, and "associates" the interface with a peer Security Gateway. The VPN Tunnel Interface may be numbered or unnumbered. For more information on the VPN Shell, see VPN Shell.

Every numbered VTI is assigned a local IP Address and a remote IP Address. Prior to configuration, a range of IP Addresses must be configured to assign to the VTIs.

The gateways in this scenario are:

Device Type

Specific Computers

ClusterXL

Cluster GWA:

  • member_GWA1
  • member_GWA2

VPN peers

  • GWb
  • GWc

VTIs connect these gateways:

IP Configurations:

Device

Type of IP Address and Interface

IP Address / Netmask

Cluster GWA -

External Unique IP address of eth0

170.170.1.1/24

member_GWA1

External VIP address of eth0

170.170.1.10/24

 

IP address of Sync interface eth1

5.5.5.1/24

 

IP address of VTI vt-GWb

Local: 10.0.1.11, Remote: 10.0.0.2

 

VIP address of VTI vt-GWb

10.0.1.10

 

IP address of VTI vt-GWc

Local: 10.0.1.21, Remote: 10.0.0.3

 

VIP address of VTI vt-GWc

10.0.1.20

Cluster GWA -

External Unique IP address of eth0

170.170.1.2/24

member_GWA2

External VIP address of eth0

170.170.1.10/24

 

IP address of Sync interface eth1

5.5.5.2/24

 

IP address of VTI vt-GWb

Local: 10.0.1.12, Remote: 10.0.0.2

 

VIP address of VTI vt-GWb

10.0.1.10

 

IP address of VTI vt-GWc

Local: 10.0.1.22, Remote: 10.0.0.3

 

VIP address of VTI vt-GWc

10.0.1.20

GWb

External Unique IP address of eth0

180.180.1.1/24

 

IP address of VTI vt-ClusterGWa

Local: 10.0.0.2, Remote: 10.0.1.10

 

IP address of VTI vt-GWc

Local: 10.0.0.2, Remote: 10.0.0.3

GWc

External Unique IP address of eth0

190.190.1.1/24

 

IP address of VTI vt-ClusterGWa

Local: 10.0.0.3, Remote: 10.0.1.20

 

IP address of VTI vt-GWb

Local: 10.0.0.3, Remote: 10.0.0.2

VTIs in a Clustered Environment

When configuring numbered VTIs in a clustered environment, a number of issues need to be considered:

Configuring VTIs in a Clustered Environment

The following sample configurations use the same Security Gateway names and IP addresses used referred to in: Numbered VTIs

Configuring member_GWA1

--------- Access the VPN shell Command Line Interface

[member_GWa2]# vpn shell

? - This help

.. - Go up one level

quit - Quit

[interface ] - Manipulate tunnel interfaces

[show ] - Show internal data

[tunnels ] - Manipulate tunnel data

--------- Add vt-GWb

VPN shell:[/] > /interface/add/numbered 10.0.1.12 10.0.0.2 GWb

Interface 'vt-GWb' was added successfully to the system

--------- Add vt-GWc

VPN shell:[/] > /interface/add/numbered 10.0.1.22 10.0.0.3 GWc

Interface 'vt-GWc' was added successfully to the system

---------- Verify configuration

VPN shell:[/] > /show/interface/detailed all

vt-GWb Type:numbered MTU:1500

inet addr:10.0.1.12 P-t-P:10.0.0.2 Mask:255.255.255.255

Peer:GWb Peer ID:180.180.1.1 Status:attached

 

vt-GWc Type:numbered MTU:1500

inet addr:10.0.1.22 P-t-P:10.0.0.3 Mask:255.255.255.255

Peer:GWc Peer ID:190.190.1.1 Status:attached

 

VPN shell:[/] > /quit

[member_GWa2]# ifconfig vt-GWb

vt-GWb Link encap:IPIP Tunnel HWaddr

inet addr:10.0.1.12 P-t-P:10.0.0.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

 

[member_GWa2]# ifconfig vt-GWc

vt-GWc Link encap:IPIP Tunnel HWaddr

inet addr:10.0.1.22 P-t-P:10.0.0.3 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Configuring member_GWA2

--------- Access the VPN shell Command Line Interface

[member_GWa2]# vpn shell

? - This help

.. - Go up one level

quit - Quit .

[interface ] - Manipulate tunnel interfaces

[show ] - Show internal data

[tunnels ] - Manipulate tunnel data

--------- Add vt-GWb

VPN shell:[/] > /interface/add/numbered 10.0.1.12 10.0.0.2 GWb

Interface 'vt-GWb' was added successfully to the system

--------- Add vt-GWc

VPN shell:[/] > /interface/add/numbered 10.0.1.22 10.0.0.3 GWc

Interface 'vt-GWc' was added successfully to the system

---------- Verify configuration

VPN shell:[/] > /show/interface/detailed all

vt-GWb Type:numbered MTU:1500

inet addr:10.0.1.12 P-t-P:10.0.0.2 Mask:255.255.255.255

Peer:GWb Peer ID:180.180.1.1 Status:attached

 

vt-GWc Type:numbered MTU:1500

inet addr:10.0.1.22 P-t-P:10.0.0.3 Mask:255.255.255.255

Peer:GWc Peer ID:190.190.1.1 Status:attached

 

VPN shell:[/] > /quit

[member_GWa2]# ifconfig vt-GWb

vt-GWb Link encap:IPIP Tunnel HWaddr

inet addr:10.0.1.12 P-t-P:10.0.0.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

 

[member_GWa2]# ifconfig vt-GWc

vt-GWc Link encap:IPIP Tunnel HWaddr

inet addr:10.0.1.22 P-t-P:10.0.0.3 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

When configuring a VTI in a clustered environment and an interface name is not specified, a name is provided. The default name for a VTI is "vt-[peer Security Gateway name]". For example, if the peer Security Gateway's name is Server_2, the default name of the VTI is 'vt-Server_2'. For peer Security Gateways that have names that are longer than 12 characters, the default interface name is the last five characters plus a 7 byte hash of the peer name calculated to the give the interface a unique name.

After configuring the VTIs on the cluster members, you must configure in the SmartConsole the VIP of these VTIs.

In SmartConsole:

  1. In the Gateways & Servers view, edit the Check Point Cluster.
  2. In Network Management window, click Get Interfaces.

    The VTIs are shown in the Topology column as Point to point.

    Interfaces are members of the same VTI if these criteria match:

    • Remote peer name
    • Remote IP address
    • Interface name
  3. Configure the VTI VIP. Select the interface and click Edit. Edit the interface in the General page of the interface object.
  4. Click OK.
  5. Install the Access Control Policy.

Configuring GWb

--------- Access the VPN shell Command Line Interface

[GWb]# vpn shell

? - This help

.. - Go up one level

quit - Quit

[interface ] - Manipulate tunnel interfaces

[show ] - Show internal data

[tunnels ] - Manipulate tunnel data

--------- Add vt-GWa

VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.1.10 GWa

Interface 'vt-GWa' was added successfully to the system

--------- Add vt-GWc

VPN shell:[/] > /interface/add/numbered 10.0.0.2 10.0.0.3 GWc

Interface 'vt-GWc' was added successfully to the system

---------- Verify configuration

VPN shell:[/] > /show/interface/detailed all

vt-GWa Type:numbered MTU:1500

inet addr:10.0.0.2 P-t-P:10.0.1.10 Mask:255.255.255.255

Peer:GWa Peer ID:170.170.1.10 Status:attached

 

vt-GWc Type:numbered MTU:1500

inet addr:10.0.0.2 P-t-P:10.0.0.3 Mask:255.255.255.255

Peer:GWc Peer ID:190.190.1.1 Status:attached

 

VPN shell:[/] > /quit

[GWb]# ifconfig vt-GWa

vt-GWa Link encap:IPIP Tunnel HWaddr

inet addr:10.0.0.2 P-t-P:10.0.1.10 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

 

[GWb]# ifconfig vt-GWc

vt-GWc Link encap:IPIP Tunnel HWaddr

inet addr:10.0.0.2 P-t-P:10.0.0.3 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Configuring GWc

--------- Access the VPN shell Command Line Interface

[GWc]# vpn shell

? - This help

.. - Go up one level

quit - Quit

[interface ] - Manipulate tunnel interfaces

[show ] - Show internal data

[tunnels ] - Manipulate tunnel data

--------- Add vt-GWa

VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.1.20 GWa

Interface 'vt-GWa' was added successfully to the system

--------- Add vt-GWb

VPN shell:[/] > /interface/add/numbered 10.0.0.3 10.0.0.2 GWb

Interface 'vt-GWb' was added successfully to the system

---------- Verify configuration

VPN shell:[/] > /show/interface/detailed all

vt-GWa Type:numbered MTU:1500

inet addr:10.0.0.3 P-t-P:10.0.1.20 Mask:255.255.255.255

Peer:GWa Peer ID:170.170.1.10 Status:attached

 

vt-GWb Type:numbered MTU:1500

inet addr:10.0.0.3 P-t-P:10.0.0.2 Mask:255.255.255.255

Peer:GWb Peer ID:180.180.1.1 Status:attached

 

VPN shell:[/] > /quit

[GWc]# ifconfig vt-GWa

vt-GWa Link encap:IPIP Tunnel HWaddr

inet addr:10.0.0.3 P-t-P:10.0.1.20 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

 

[GWc]# ifconfig vt-GWb

vt-GWb Link encap:IPIP Tunnel HWaddr

inet addr:10.0.0.3 P-t-P:10.0.0.2 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:1 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:36 (36.0 b)

Enabling Dynamic Routing Protocols on VTIs

Example:

The following tables illustrate how the OSPF dynamic routing protocol is enabled on VTIs both for single members and for cluster members. Note that the network commands for single members and cluster members are not the same.

For more information on advanced routing commands and syntaxes, see the R80.30 Gaia Advanced Routing Administration Guide.

To learn about enabling dynamic routing protocols on VTIs in Gaia environments, see VPN Tunnel Interfaces in the R80.30 Gaia Administration Guide.

When peering with a Cisco GRE enabled device, a point to point GRE tunnel is required.

Use the following commands to configure the tunnel interface definition:

Dynamic Routing on member_GWA1

member_GWA1:0> set ospf area 0.0.0.0 on

member_GWA1:0> set router-id 170.170.1.10

member_GWA1:0> set ospf interface vt-GWb area 0.0.0.0 on

member_GWA1:0> set ospf interface vt-GWc area 0.0.0.0 on

member_GWA1:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on

member_GWA1:0> save config

member_GWA1:0> show configuration ospf

Dynamic Routing on member_GWA2

member_GWA2:0> set ospf area 0.0.0.0 on

member_GWA2:0> set router-id 170.170.1.10

member_GWA2:0> set ospf interface vt-GWb area 0.0.0.0 on

member_GWA2:0> set ospf interface vt-GWc area 0.0.0.0 on

member_GWA2:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on

member_GWA2:0> save config

member_GWA2:0> show configuration ospf

Dynamic Routing on GWb

GWb:0> set ospf area 0.0.0.0 on

GWb:0> set router-id 180.180.1.1

GWb:0> set ospf interface vt-ClusterGWa area 0.0.0.0 on

GWb:0> set ospf interface vt-GWc area 0.0.0.0 on

GWb:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on

GWb:0> save config

GWb:0> show configuration ospf

Dynamic Routing on GWc

GWc:0> set ospf area 0.0.0.0 on

GWc:0> set router-id 190.190.1.1

GWc:0> set ospf interface vt-ClusterGWa area 0.0.0.0 on

GWc:0> set ospf interface vt-GWb area 0.0.0.0 on

GWc:0> set route-redistribution to ospf2 from kernel all-ipv4-routes on

GWc:0> save config

GWc:0> show configuration ospf

Configuring VTIs in a Gaia Environment

To learn how to configure VTIs in Gaia environments, see VPN Tunnel Interfaces in the R80.30 Gaia Administration Guide.

Note - For VTIs between Gaia gateways and Cisco GRE gateways: You must manually configure hello/dead packet intervals at 10/40 on the Gaia gateway, or at 30/120 on the peer gateway. If not, OSPF will not get into Full state.

Configuring Anti-Spoofing on VTIs

In SmartConsole:

  1. In the Gateways & Servers view, edit a Check Point Security Gateway.
  2. Go to the Network Management page.
  3. Click Get Interfaces to read the interface information on the Security Gateway computer.
  4. Select an interface, and click Edit.
  5. In the Topology section of the General page, click Modify.
  6. In the IP Addresses behind peer Security Gateway that are within reach of this interface section, select:
    • Not Defined to accept all traffic.
    • Specific to choose a particular network. The IP addresses in this network will be the only addresses accepted by this interface.
  7. In the Perform Anti-Spoofing based on interface topology section, select Don't check packets from to ensure Anti-Spoofing checks do not take place for addresses from certain internal networks coming into the external interface. Define a network object that represents those internal networks with valid addresses, and from the drop-down list, select that network object.

    Objects selected in the Don't check packets from drop-down menu are disregarded by the Anti-Spoofing enforcement mechanism.

  8. Under Spoof Tracking select Log, and click OK.

Configuring Unnumbered VTIs

Working with unnumbered interfaces eliminates the need to assign two IP addresses per interface (the local IP, and the remote IP Address), and the need to synchronize this information among the peers.

If the VPN Tunnel Interface is unnumbered, local and remote IP addresses are not configured. This interface is associated with a proxy interface from which the virtual interface inherits an IP address. Traffic initiated by the Security Gateway and routed through the virtual interface will have the physical interface's IP Address as the source IP.

To configure unnumbered VTIs for Gaia:

  1. In Gaia Portal, select Interface Management > Network Interfaces.
  2. Click Add > VPN Tunnel.
  3. In the Add/Edit window that opens, configure these parameters:
    • VPN Tunnel ID - an integer from 1 to 99, and Gaia automatically adds vpnt prefix to the Tunnel ID
    • Remote Peer Name - alpha-numeric Peer ID, as defined for the Remote Peer Name in the VPN community. You must define the two peers in the VPN community before you define the VTI.
    • VPN Tunnel Type - select Unnumbered
    • Local Address - leave empty for unnumbered VTI
    • Remote Address - leave empty for unnumbered VTI
    • Physical Device - the name of the local peer interface (the loopback interface can also be configured as the local peer interface)

Routing Multicast Packets Through VPN Tunnels

Multicast is used to transmit a single message to a select group of recipients. IP Multicasting applications send one copy of each datagram (IP packet) and address it to a group of computers that want to receive it. This technique addresses datagrams to a group of receivers (at the multicast address) rather than to a single receiver (at a unicast address). The network is responsible for forwarding the datagrams to only those networks that need to receive them. PIM is required for this feature.

For more about Multicasting, see "Multicast Access Control" in the R80.30 Security Management Administration Guide.

Multicast traffic can be encrypted and forwarded across VPN tunnels that were configured with VPN tunnel interfaces (virtual interfaces associated with the same physical interface). All participant Security Gateways, both on the sending and receiving ends, must have a virtual interface for each VPN tunnel and a multicast routing protocol must be enabled on all participant Security Gateways.

For more about virtual interfaces, see Configuring a Virtual Interface Using the VPN Shell.

To enable multicast service on a Security Gateway functioning as a rendezvous point, add a rule to the security policy of that Security Gateway to allow only the specific multicast service to be accepted unencrypted, and to accept all other services only through the community. Corresponding Access Control rules enabling multicast protocols and services should be created on all participating Security Gateways. For example:

Source

Destination

VPN

Service

Action

Track

Multicast_
Gateways

Multicast_
Gateways

Any Traffic

igmp

pim

accept

log

Sample_Host

Multicast_Group_
Address

Sample_
Community

Multicast_
Service_Group

accept

log