Policy-Based and Route-Based VPNs: FortiGate unit VPNs can be policy-based or route-based. There is litle difference between the two types. In both cases, you specify Phase 1 and Phase 2 settings. However, there is a difference in implementation. A route-based VPN creates a virtual IPsec network interface that applies encryption or decryption as needed to any traffic that it carries. That is why route-based VPNs are also known as interface-based VPNs. A policy-based VPN is implemented through a special security policy that applies the encryption you specified in the Phase 1 and Phase 2 settings. Where possible, you should create route-based VPNs. Generally, route-based VPNs are more flexible and easier to configure than policy-based VPNs — by default they are treated as interfaces. Route-Based VPNs: For a route-based VPN, you create two security policies between the virtual IPsec interface and the interface that connects to the private network. In one policy, the virtual interface is the source. In the other policy, the virtual interface is the destination. This creates bidirectional policies that ensure traffic will flow in both directions over the VPN. A route-based VPN is also known as an interface-based VPN. Policy-Based VPNs: For a policy-based VPN, one security policy enables communication in both directions. You enable inbound and outbound traffic as needed within that policy or create multiple policies of this type to handle different types of traffic differently. For example, HTTPS traffic may not require the same level of scanning as FTP traffic. A policy-based VPN is also known as atunnel- mode VPN. Features Policy-based Route-based Both NAT and Yes NAT mode only transparent modes available L2TP-over-IPsec Yes Yes supported GRE-over-IPsec No Yes supported Security policy Requires a security policy with __| Requires only a simple requirements IPSEC action that specifies the _| security policy with ACCEPT VPN tunnel action Number of polici ‘One policy controls connections in | A separate policy is required VPN both directions for connections in each direction 1 | age Created by Ahmad Ali E-Mail: ahmadalimsc@ gmail.com , Mobile: 056 430 3717Overlay Controller VPN (OCVPN): Overlay Controller VPN (OCVPN) is a cloud-based solution to simplify IPsec VPN setup. When OCVPN is enabled, IPsec phase1 ‘interfaces, phase2 interfaces, static routes, and firewall policies are generated automatically on all FortiGate’s that belong to the same community network. A community network is defined as all FortiGate’s registered to FortiCare using the same FortiCare account. If the network topology changes on any FortiGate’s in the community (such as changing a public IP address in DHCP mode, adding or removing protected subnets, failing over in dual WAN), the IPsec-related configuration for all devices is updated with Cloud assistance in self-learning mode. No intervention is required. Black Hole Route: This route is active when the tunnel is down. By adding this route, the FortiGate is being told to drop the requests silently. So, there are no sessions added on the FortiGate and hence the ping test or the actual traffic or probes should return an immediate response when the tunnel is up. This also helps in making the network more secure because the traffic which is supposed to enter the encrypted tunnel is now not pushed to the default route (ISP) when the tunnel is down. it to a [dev/null interface in Linux. Edit Static Route Destination Subnet Internet Service 55 ToSite2_semote > Interface Administrative Distance @ |) 254 Comments VPN: ToSite2 (Created by VPN wizard) Status Cee VPN Template: Unlike the Palo Alto Firewall, the FortiGate firewall gives you templates, which help you to create an IPSectunnel by clicking Next, Next, etc. Unfortunately, pre-defined templates are only available for Cisco ASA and FortiGate Firewalls only not for other vender need to use Custom template. 2 [P age Created by Ahmad Ali E-Mail: ahmadalimsc@ gmail.com , Mobile: 056 430 3717Dead Peer Detection: Select a dead peer detection option. On Idle will attempt to reestablish VPN tunnels when a connection becomes idle. Use of periodic dead peer detection incurs extra overhead. When communicating to large numbers of IKE peers, you should consider using On Demand. Sometimes, due to routing issues or other difficulties, the communication link between a FortiGate unit and a VPN peer or client may go down. Packets could be lost if the connection is left to time out on its own. The FortiGate unit provides mechanism called Dead Peer Detection, sometimes referred to as gateway detection or ping server, to prevent this situation and reestablish IKE negotiations automatically before a connection times out: the active Phase 1 security associations are caught and renegotiated (rekeyed) before the Phase 1 encryption key expires. By default, Dead Peer Detection sends probe messages every five seconds by default. NAT Traversal: When an IP packet passes through a NAT device, the source or destination address in the IP header is modified. FortiGate units support NAT version 1 (encapsulate on port 500 with non- IKE marker), version 3 (encapsulate on port 4500 with non-ESP marker), and compatible versions. NAT cannot be performed on IPsec packets in ESP tunnel mode because the packets, do not contain a port number. As a result, the packets cannot be demultiplexed. To work around this, the FortiGate unit provides a way to protect IPsec packet headers from NAT modifications. When the Nat traversal option is enabled, outbound encrypted packets are wrapped inside a UDP IP header that contains a port number. This extra encapsulation allows NAT devices to change the port number without modifying the IPsec packet directly. To provide the extra layer of encapsulation on IPsec packets, the Nat-traversal option must be enabled whenever a NAT device exists between two FortiGate VPN peers or a FortiGate unit and a dialup client such as FortiClient. On the receiving end, the FortiGate unit or FortiClient removes the extra layer of encapsulation before decrypting the packet. Additionally, you can force IPsec to use NAT traversal. If NAT is set to Forced, the FortiGate will use a port value of zero when constructing the NAT discovery hash for the peer. This causes the peer to think itis behind a NAT device, and it will use UDP encapsulation for IPsec, even if no NAT is present. This approach maintains interoperability with any IPsec implementation that supports the NAT-T. NAT Keepalive Frequency: ‘When a NAT device performs network address translation on a flow of packets, the NAT device determines how long the new address will remain valid if the flow of traffic stops (for example, the connected VPN peer may be idle). The device may reclaim and reuse a NAT address when a connection remains idle for too long. To work around this, when you enable NAT traversal specify how often the FortiGate unit sends periodic keepalive packets through the NAT device in order to ensure that the NAT address mapping does not change during the lifetime of a session. To be effective, the keepalive interval must be smaller than the session lifetime value used by the NAT device. 3 |? age Created by Ahmad Ali E-Mail: ahmadalimsc@ gmail.com , Mobile: 056 430 3717xAuth Authentication: Extended authentication (xAuth) increases security by requiring the remote dialup client user to authenticate in a separate exchange at the end of Phase 1. XAuth draws on existing FortiGate User group definitions and uses established authentication mechanisms such as PAP, CHAP, RADIUS, and LDAP to authenticate dialup clients. You can configure a FortiGate unit to function either as an XAuth server or an XAuth client. If the server or client is attempting a connection using XAuth and the other end is not using XAuth, the failed connection attempts that are logged will not specify XAuth as the reason. 4 | 2 ge Created by Ahmad Ali E-Mail: ahimadalimsc@ gmail.com , Mobile: 056.430 3717