Defining VPN security policies
This section explains how to specify the source and destination IP addresses of traffic transmitted through an IPsec VPN, and how to define appropriate security policies. The following topics are included in this section:
- Defining policy addresses
- Defining VPN security policies
Defining policy addresses
A VPN tunnel has two end points. These end points may be VPN peers such as two FortiGate gateways. Encrypted packets are transmitted between the end points. At each end of the VPN tunnel, a VPN peer intercepts encrypted packets, decrypts the packets, and forwards the decrypted IP packets to the intended destination.
You need to define firewall addresses for the private networks behind each peer. You will use these addresses as the source or destination address depending on the security policy.
Example topology for the following policies
- In a gateway-to-gateway, hub-and-spoke, dynamic DNS, redundant-tunnel, or transparent configuration, you need to define a policy address for the private IP address of the network behind the remote VPN peer (for example,192.168.10.0/255.255.255.0 or 192.168.10.0/24).
- In a peer-to-peer configuration, you need to define a policy address for the private IP address of a server or host behind the remote VPN peer (for example, 172.16.5.1/255.255.255.255 or 172.16.5.1/32 or 172.16.5.1).
For a FortiGate dialup server in a dialup-client or Internet-browsing configuration:
- If you are not using VIP addresses, or if the FortiGate dialup server assigns VIP addresses to FortiClient dialup clients through FortiGate DHCP relay, select the predefined destination address “all” in the security policy to refer to the dialup clients
- If you assign VIP addresses to FortiClient dialup clients manually, you need to define a policy address for the VIP address assigned to the dialup client (for example, 10.254.254.1/32), or a subnet address from which the VIP addresses are assigned (for example, 10.254.254.0/24 or 10.254.254.0/255.255.255.0).
- For a FortiGate dialup client in a dialup-client or Internet-browsing configuration, you need to define a policy address for the private IP address of a host, server, or network behind the FortiGate dialup server.
To define a security IP address
1. Go to Policy & Objects > Addresses and select Create New.
2. In the Name field, type a descriptive name that represents the network, server(s), or host(s).
3. In Type, select Subnet.
4. In the Subnet/IP Range field, type the corresponding IP address and subnet mask.
For a subnet you could use the format 172.16.5.0/24 or its equivalent 172.16.5.0/255.255.255.0. For a server or host it would likely be 172.16.5.1/32. Alternately you can use an IP address range such as 192.168.10.[80-100] or 192.168.10.80-192.168.10.100.
5. Select OK.
Defining VPN security policies
Security policies allow IP traffic to pass between interfaces on a FortiGate unit. You can limit communication to particular traffic by specifying source address and destination addresses. Then only traffic from those addresses will be allowed.
Policy-based and route-based VPNs require different security policies.
- A policy-based VPN requires an IPsec security policy. You specify the interface to the private network, the interface to the remote peer and the VPN tunnel. A single policy can enable traffic inbound, outbound, or in both directions.
- A route-based VPN requires an Accept security policy for each direction. As source and destination interfaces, you specify the interface to the private network and the virtual IPsec interface (Phase 1 configuration) of the VPN. The IPsec interface is the destination interface for the outbound policy and the source interface for the inbound policy. One security policy must be configured for each direction of each VPN interface.
There are examples of security policies for both policy-based and route-based VPNs throughout this guide. See Dynamic DNS configuration on page 1688.
If the security policy, which grants the VPN Connection is limited to certain services, DHCP must be included, otherwise the client won’t be able to retrieve a lease from the FortiGate’s (IPsec) DHCP server, because the DHCP Request (coming out of the tun- nel) will be blocked.
Defining an IPsec security policy for a policy-based VPN
An IPsec security policy enables the transmission and reception of encrypted packets, specifies the permitted direction of VPN traffic, and selects the VPN tunnel. In most cases, a single policy is needed to control both inbound and outbound IP traffic through a VPN tunnel.
Allow traffic to be initiated from the remote site
In addition to these operations, security policies specify which IP addresses can initiate a tunnel. by default, traffic from the local private network initiates the tunnel. When the Allow traffic to be initiated form the remote site option is selected, traffic from a dialup client or computers on the remote network initiates the tunnel. Both can be enabled at the same time for bi-directional initiation of the tunnel.
Outbound and inbound NAT
When a FortiGate unit operates in NAT mode, you can also enable inbound or outbound NAT. Outbound NAT may be performed on outbound encrypted packets, or on IP packets before they are sent through the tunnel.
Inbound NAT is performed on IP packets emerging from the tunnel. By default, these options are not selected in security policies.
When used in conjunction with the natip CLI attribute (see the “config firewall” chapter of the FortiGate CLI Reference), outbound NAT enables you to change the source addresses of IP packets before they go into the tunnel. This feature is often used to resolve ambiguous routing when two or more of the private networks making up a VPN have the same or overlapping IP addresses. .
When inbound NAT is enabled, inbound encrypted packets are intercepted and decrypted, and the source IP addresses of the decrypted packets are translated into the IP address of the FortiGate interface to the local private network before they are routed to the private network. If the computers on the local private network can communicate only with devices on the local private network (that is, the FortiGate interface to the private network is not the default gateway) and the remote client (or remote private network) does not have an IP address in the same network address space as the local private network, enable inbound NAT.
Source and destination addresses
Most security policies control outbound IP traffic. A VPN outbound policy usually has a source address originating on the private network behind the local FortiGate unit, and a destination address belonging to a dialup VPN client or a network behind the remote VPN peer. The source address that you choose for the security policy identifies from where outbound cleartext IP packets may originate, and also defines the local IP address or addresses that a remote server or client will be allowed to access through the VPN tunnel. The destination address that you choose identifies where IP packets must be forwarded after they are decrypted at the far end of the tunnel, and determines the IP address or addresses that the local network will be able to access at the far end of the tunnel.
Enabling other policy features
You can fine-tune a policy for services such as HTTP, FTP, and POP3; enable logging, traffic shaping, antivirus protection, web filtering, email filtering, file transfer, and email services throughout the VPN; and optionally allow connections according to a predefined schedule.
As an option, differentiated services (diffserv or DSCP) can be enabled in the security policy through CLI commands. For more information on this feature, see the Traffic Shaping handbook chapter, or the “firewall” chapter of the FortiGate CLI Reference.
When a remote server or client attempts to connect to the private network behind a FortiGate gateway, the security policy intercepts the connection attempt and starts the VPN tunnel. The FortiGate unit uses the remote gateway specified in its Phase 1 tunnel configuration to reply to the remote peer. When the remote peer receives a reply, it checks its own security policy, including the tunnel configuration, to determine which communications are permitted. As long as one or more services are allowed through the VPN tunnel, the two peers begin to negotiate the tunnel. To follow this negotiation in the web-based manager, go to Monitor > IPsec Monitor. There you will find a list of the VPN tunnels, their status, and the data flow both incoming and outgoing.
Before you begin
Before you define the IPsec policy, you must:
- Define the IP source and destination addresses. See Defining VPN security policies on page 1650.
- Specify the Phase 1 authentication parameters. See Phase 1 parameters on page 1624.
- Specify the Phase 2 parameters. See Phase 2 parameters on page 1642.
To define an IPsec security policy
1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and set the following options:
Incoming Interface Select the local interface to the internal (private) network.
Source Address Select the name that corresponds to the local network, server(s), or host(s) from which IP packets may originate.
Outgoing Interface Select the local interface to the external (public) network.
Destination Address Select the name that corresponds to the remote network, server(s), or host (s) to which IP packets may be delivered.
Schedule Keep the default setting (always) unless changes are needed to meet spe- cific requirements.
Service Keep the default setting (ANY) unless changes are needed to meet your specific requirements.
VPN Tunnel Select Use Existing and select the tunnel from the drop-down list.
Allo traffic to be initiated from the remote site
Select if traffic from the remote network will be allowed to initiate the tun- nel.
3. You may enable UTM features, and/or event logging, or select advanced settings to authenticate a user group, or shape traffic. For more information, see the Firewall handbook chapter.
4. Select OK.
5. Place the policy in the policy list above any other policies having similar source and destination addresses.
Defining multiple IPsec policies for the same tunnel
You must define at least one IPsec policy for each VPN tunnel. If the same remote server or client requires access to more than one network behind a local FortiGate unit, the FortiGate unit must be configured with an IPsec policy for each network. Multiple policies may be required to configure redundant connections to a remote destination or control access to different services at different times.
To ensure a secure connection, the FortiGate unit must evaluate IPSEC policies before ACCEPT and DENY security policies. Because the FortiGate unit reads policies starting at the top of the list, you must move all IPsec policies to the top of the list. When you define multiple IPsec policies for the same tunnel, you must reorder the IPsec policies that apply to the tunnel so that specific constraints can be evaluated before general constraints.
Adding multiple IPsec policies for the same VPN tunnel can cause conflicts if the policies specify similar source and destination addresses but have different settings for the same service. When policies overlap in this manner, the system may apply the wrong IPsec policy or the tunnel may fail.
For example, if you create two equivalent IPsec policies for two different tunnels, it does not matter which one comes first in the list of IPsec policies — the system will select the correct policy based on the specified source and destination addresses. If you create two different IPsec policies for the same tunnel (that is, the two policies treat traffic differently depending on the nature of the connection request), you might have to reorder the IPsec policies to ensure that the system selects the correct IPsec policy. Reordering is especially important when the source and destination addresses in both policies are similar (for example, if one policy specifies a subset of the IP addresses in another policy). In this case, place the IPsec policy having the most specific constraints at the top of the list so that it can be evaluated first.
Defining security policies for a route-based VPN
When you define a route-based VPN, you create a virtual IPsec interface on the physical interface that connects to the remote peer. You create ordinary Accept security policies to enable traffic between the IPsec interface and the interface that connects to the private network. This makes configuration simpler than for policy-based VPNs, which require IPsec security policies.
To define security policies for a route-based VPN
1. Go to Policy & Objects > IPv4 Policy.
2. Select Create New and leave the Policy Type as Firewall, and the Policy Subtype as Address.
3. Define an ACCEPT security policy to permit communications between the local private network and the private network behind the remote peer. Enter these settings in particular:
Incoming Interface Select the interface that connects to the private network behind this FortiGate unit.
Source Address Select the address name that you defined for the private network behind this FortiGate unit.
Outgoing Interface Select the IPsec Interface you configured.
Destination Address Select the address name that you defined for the private network behind the remote peer.
Action Select ACCEPT.
Enable NAT Disable.
To permit the remote client to initiate communication, you need to define a security policy for communication in that direction.
4. Select Create New and leave the Policy Type as Firewall, and the Policy Subtype as Address
5. Enter these settings in particular:
Incoming Interface Select the IPsec Interface you configured.
Source Address Select the address name that you defined for the private network behind the remote peer.
Outgoing Interface Select the interface that connects to the private network behind this FortiGate unit.
Destination Address Select the address name that you defined for the private network behind this FortiGate unit.
Action Select ACCEPT.
Enable NAT Disable.
Having trouble configuring your Fortinet hardware or have some questions you need answered? Ask your questions in the comments below!!! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!