Basic site-to-site VPN

IPsec VPN in an HA environment

This recipe provides sample configuration of site-to-site IPsec VPN in an HA environment. You must enable two options to ensure IPsec VPN traffic does not interrupt during an HA failover:

• session-pickup under HA settings
• ha-sync-esp-seqno under IPsec phase1-interface settings The following shows the sample network topology for this recipe:

You can configure IPsec VPN in an HA environment using the FortiOS GUI or CLI.

In this examples below, the VPN name for HQ1 is “to_HQ2”, and the VPN name for HQ2 is “to_HQ1”.

To configure IPsec VPN in an HA environment on the GUI:

1. Set up HA as described in the HA topics.
2. Set up IPsec VPN on HQ1 (the HA cluster):
   1. Go to VPN > IPsec Wizard and configure the following settings for VPN Setup:
      1. Enter a proper VPN name.
      2. For Template Type, choose Site to Site. For Remote Device Type, select FortiGate. iv. For NAT Configuration, set No NAT Between Sites.
      3. Click Next.
   2. Configure the following settings for Authentication:
      172. For Remote Device, select IP Address. In the IP address field, enter 172.16.202.1. iii. In the Outgoing Interface field, enter port1.
      173. For Authentication Method, select Pre-shared Key.
      174. In the Pre-shared Key field, enter an example key.
      175. Click Next.
      176. Configure the following settings for Policy & Routing:
   3. From the Local Interface dropdown menu, select the desired local interface.
   4. Configure the Local Subnets as 10.1.100.0/24.

• Configure the Remote Subnets as 172.16.101.0/24.

1. Click Create.
2. Set up IPsec VPN on HQ2:

1. Go to VPN > IPsec Wizard and configure the following settings for VPN Setup:
   1. Enter a proper VPN name.
   2. For Template Type, choose Site to Site. For Remote Device Type, select FortiGate. iv. For NAT Configuration, set No NAT Between Sites.
   3. Click Next.
2. Configure the following settings for Authentication:
   172. For Remote Device, select IP Address. In the IP address field, enter 172.16.200.1. iii. In the Outgoing Interface field, enter port13.
   173. For Authentication Method, select Pre-shared Key.
   174. In the Pre-shared Key field, enter an example key.
   175. Click Next.
3. Configure the following settings for Policy & Routing:
   9. From the Local Interface dropdown menu, select the desired local interface. In this example, it is port9.
   10. Configure the Local Subnets as 172.16.101.0. Configure the Remote Subnets as 10.1.100.0 iv. Click Create.

To configure IPsec VPN in an HA environment using the CLI:

1. Configure HA. In this example, two FortiGates work in active-passive mode. The HA heartbeat interfaces are WAN1 and WAN2:

config system ha set group-name “FGT-HA” set mode a-p set password sample set hbdev “wan1” 50 “wan2” 50 set session-pickup enable set priority 200 set override-wait-time 10

end

2. Configure the WAN interface and default route. The WAN interface is the interface connected to the ISP. It can work in static mode (as shown in the example), DHCP, or PPPoE mode. The IPsec tunnel is established over the WAN interface.
3. Configure HQ1:

config system interface edit “port1” set vdom “root”

set ip 172.16.200.1 255.255.255.0

next end config router static edit 1 set gateway 172.16.200.3 set device “port1”

next

end

1. Configure HQ2:

config system interface edit “port25” set vdom “root”

set ip 172.16.202.1 255.255.255.0

next

end

config router static edit 1 set gateway 172.16.202.2 set device “port25”

next

end

3. Configure the internal (protected subnet) interface. The internal interface connects to corporate internal network.

Traffic from this interface routes out the IPsec VPN tunnel. a. Configure HQ1:

config system interface edit “dmz” set vdom “root”

set ip 10.1.100.1 255.255.255.0

next

end

1. Configure HQ2:

config system interface edit “port9” set vdom “root”

set ip 172.16.101.1 255.255.255.0

next

end

4. Configure the IPsec phase1-interface. In this example, PSK is used as the authentication method. Signature authentication is also an option. Configure HQ1:

config vpn ipsec phase1-interface edit “to_HQ2” set interface “port1” set peertype any set net-device enable set ha-sync-esp-seqno enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.16.202.1 set psksecret sample

next

end

1. Configure HQ2:

config vpn ipsec phase1-interface edit “to_HQ1” set interface “port25” set peertype any set net-device enable

set ha-sync-esp-seqno enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.16.200.1 set psksecret sample

next

5. Configure the IPsec phase2-interface:
   1. Configure HQ1:

config vpn ipsec phase2-interface edit “to_HQ2” set phase1name “to_HQ2”

set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305

set auto-negotiate enable

next

end

1. Configure HQ2:

config vpn ipsec phase2-interface edit “to_HQ1” set phase1name “to_HQ1”

set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256 aes128gcm aes256gcm chacha20poly1305

set auto-negotiate enable

next

end

6. Configure static routes. Two static routes are added to reach the remote protected subnet. The blackhole route is important to ensure that IPsec traffic does not match the default route when the IPsec tunnel is down. Configure HQ1:

config router static edit 2 set dst 172.16.101.0 255.255.255.0 set device “to_HQ2”

next edit 3 set dst 172.16.101.0 255.255.255.0 set blackhole enable set distance 254

next

end

1. Configure HQ2:

config router static edit 2 set dst 10.1.100.0 255.255.255.0 set device “to_HQ1”

next edit 3 set dst 10.1.100.0 255.255.255.0 set blackhole enable set distance 254

next

end

7. Configure two firewall policies to allow bi-directional IPsec traffic flow over the IPsec tunnel: a. Configure HQ1:

config firewall policy edit 1 set name “inbound”

set srcintf “to_HQ2” set dstintf “dmz” set srcaddr “172.16.101.0” set dstaddr “10.1.100.0” set action accept set schedule “always” set service “ALL”

next edit 2 set name “outbound” set srcintf “dmz” set dstintf “to_HQ2” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next

end

1. Configure HQ2:

config firewall policy edit 1 set name “inbound” set srcintf “to_HQ1” set dstintf “port9” set srcaddr “10.1.1.00.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next edit 2 set name “outbound” set srcintf “port9” set dstintf “to_HQ1” set srcaddr “172.16.101.0” set dstaddr “10.1.100.0” set action accept set schedule “always” set service “ALL”

next

end

8. Run diagnose commands. These diagnose commands are useful to check IPsec phase1/phase2 interface statuses, including the sequence number on the secondary FortiGate. The diagnose debug application ike -1 command is the key to figure out why the IPsec tunnel failed to establish.
9. Run the HQ1 # diagnose vpn ike gateway list command. The system should return the following:

vd: root/0 name: to_HQ2 version: 1 interface: port1 11 addr: 172.16.200.1:500 -> 172.16.202.1:500

created: 5s ago

IKE SA: created 1/1 established 1/1 time 0/0/0 ms

IPsec SA: created 2/2 established 2/2 time 0/0/0 ms

id/spi: 12 6e8d0532e7fe8d84/3694ac323138a024 direction: responder status:

established 5-5s ago = 0ms proposal: aes128-sha256 key: b3efb46d0d385aff-

7bb9ee241362ee8d lifetime/rekey: 86400/86124 DPD sent/recv: 00000000/00000000

1. Run the HQ1 # diagnose vpn tunnel list command. The system should return the following: list all ipsec tunnel in vd 0

name=to_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0

bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_ dev frag-rfc accept_traffic=1

proxyid_num=1 child_num=0 refcnt=11 ilast=7 olast=87 ad=/0 stat: rxp=0 txp=0 rxb=0 txb=0

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=to_HQ2 proto=0 sa=1 ref=2 serial=1 auto-negotiate src: 0:0.0.0.0/0.0.0.0:0 dst: 0:0.0.0.0/0.0.0.0:0 SA: ref=3 options=18227 type=00 soft=0 mtu=1438 expire=42927/0B replaywin=2048

seqno=1 esn=0 replaywin_lastseq=00000000 itn=0

life: type=01 bytes=0/0 timeout=42930/43200 dec: spi=ef9ca700 esp=aes key=16 a2c6584bf654d4f956497b3436f1cfc7

ah=sha1 key=20 82c5e734bce81e6f18418328e2a11aeb7baa021b

enc: spi=791e898e esp=aes key=16 0dbb4588ba2665c6962491e85a4a8d5a ah=sha1 key=20 2054b318d2568a8b12119120f20ecac97ab730b3

dec:pkts/bytes=0/0, enc:pkts/bytes=0/0

ESP seqno synced to primary FortiGate every five minutes, and big gap between primary and secondary to ensure that no packet is dropped after HA failover caused by tcp-replay. Check ESP sequence number synced on secondary FortiGate.

1. Run the HQ1 # execute ha manage 0 admin command:
2. Run the HQ1-Slave # diagnose vpn tunnel list The system should return the following:

list all ipsec tunnel in vd 0

name=to_HQ2 ver=1 serial=1 172.16.200.1:0->172.16.202.1:0

bound_if=11 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/528 options[0210]=create_ dev frag-rfc accept_traffic=1

proxyid_num=1 child_num=0 refcnt=11 ilast=13 olast=274 ad=/0 stat: rxp=0 txp=0 rxb=0 txb=0

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=to_HQ2 proto=0 sa=1 ref=2 serial=1 auto-negotiate src: 0:0.0.0.0/0.0.0.0:0 dst: 0:0.0.0.0/0.0.0.0:0 SA: ref=3 options=27 type=00 soft=0 mtu=1280 expire=42740/0B replaywin=2048

seqno=47868c01 esn=0 replaywin_lastseq=00000000 itn=0

life: type=01 bytes=0/0 timeout=42930/43200 dec: spi=ef9ca700 esp=aes key=16 a2c6584bf654d4f956497b3436f1cfc7

ah=sha1 key=20 82c5e734bce81e6f18418328e2a11aeb7baa021b

enc: spi=791e898e esp=aes key=16 0dbb4588ba2665c6962491e85a4a8d5a ah=sha1 key=20 2054b318d2568a8b12119120f20ecac97ab730b3

dec:pkts/bytes=0/0, enc:pkts/bytes=0/0

SSL Inspection

Certificate inspection

FortiGate supports certificate inspection. The default configuration has a built-in certificate-inspection profile which you can use directly. When you use certificate inspection, the FortiGate only inspects the header information of the packets.

If you do not want to deep scan for privacy reasons but you want to control web site access, you can use certificateinspection.

Inspect non-standard HTTPS ports

The built-in certificate-inspection profile is read-only and only listens on port 443. If you want to make changes, you must create a new certificate inspection profile.

If you know the non-standard port that the web server uses, such as port 8443, you can add this port to the HTTPS field.

If you do not know which port is used in the HTTPS web server, you can select Inspect All Ports.

Block untrusted or allow invalid certificate

The default setting in the certificate-inspection profile is to block invalid certificates and allow untrusted certificates.

For example, the server certificate has expired but you still want to access this server until you have a new server certificate. But because certificate inspection cannot do an exemption, you have to allow the invalid certificate in your SSL profile. This means you need to create a new certificate inspection profile using the built-in read-only certificateinspection.

Deep inspection

You typically apply deep inspection to outbound policies where destinations are unknown. You can configure address and web category white lists to bypass SSL deep inspection.

Reasons for using deep inspection

While Hypertext Transfer Protocol Secure (HTTPS) offers protection on the Internet by applying Secure Sockets Layer (SSL) encryption to web traffic, encrypted traffic can be used to get around your network’s normal defenses.

For example, you might download a file containing a virus during an e-commerce session, or you might receive a phishing email containing a seemingly harmless download that, when launched, creates an encrypted session to a command and control (C&C) server and downloads malware onto your computer. Because the sessions in these attacks are encrypted, they might get past your network’s security measures.

When you use deep inspection, the FortiGate impersonates the recipient of the originating SSL session, then decrypts and inspects the content to find threats and block them. It then re-encrypts the content and sends it to the real recipient.

Deep inspection not only protects you from attacks that use HTTPS, it also protects you from other commonly-used SSL-encrypted protocols such as SMTPS, POP3S, IMAPS, and FTPS.

Browser messages when using deep inspection

When FortiGate re-encrypts the content, it uses a certificate stored on the FortiGate such as Fortinet_CA_SSL, Fortinet_CA_Untrusted, or your own CA certificate that you uploaded.

Because there is no Fortinet_CA_SSL in the browser trusted CA list, the browser displays an untrusted certificate warning when it receives a FortiGate re-signed server certificate. To stop the warning messages, trust the FortiGatetrusted CA Fortinet_CA_SSL and import it into your browser.

After importing Fortinet_CA_SSL into your browser, if you still get messages about untrusted certificate, it must be due to Fortinet_CA_Untrusted. Never import the Fortinet_CA_Untrusted certificate into your browser.

To import Fortinet_CA_SSL into your browser:

1. On the FortiGate, go to Security Profiles > SSL/SSH Inspection and select deep-inspection.
2. The default CA Certificate is Fortinet_CA_SSL.
3. Select Download Certificate.
4. On the client PC, double-click the certificate file and select Open.
5. Select Install Certificate to launch the Certificate Import Wizard and use the wizard to install the certificate into the Trusted Root Certificate Authorities

If a security warning appears, select Yes to install the certificate.

Exempt web sites from deep inspection

If you do not want to apply deep inspection for privacy or other reasons, you can exempt the session by address, category, or white list.

If you know the address of the server you want to exempt, you can exempt that address. You can exempt specific address type including IP address, IP address range, IP subnet, FQDN, wildcard-FQDN, and geography.

If you want to exempt all bank web sites, an easy way is to exempt the Finance and Banking category which includes all finance and bank web sites identified in FortiGuard.

If you want to exempt commonly trusted web sites, you can bypass the SSL white list in the SSL/SSH profile. The white list includes common web sites trusted by FortiGuard. Simply enable Reputable Websites.

Protecting SSL Server

You typically use the FortiGate Protecting SSL Server profile as an inbound policy for clients on the Internet accessing the server on the internal side of the FortiGate.

Protecting SSL Server uses a server certificate to protect a single server.

If you do not want a client in the Internet accessing your internal server directly and you want FortiGate to simulate your real server, you can use Protecting SSL Server.

To upload a server certificate into FortiGate and use that certificate in the SSL/SSH Inspection Profile:

1. Go to System > Certificates.
2. Select Import > Local Certificate and upload the certificate.
3. Go to Security Profiles > SSL/SSH Inspection and select Protecting SSL Server.

When you apply this Protecting SSL Server profile in a policy, FortiGate will send the server certificate to the client as your server does.

 

Flow mode inspection use case

It is recommended that flow inspection is applied to policies that prioritize traffic throughput, such as allowing connections to be made towards a streaming or file server.

You have an application server which accepts connections from users for the daily quiz show app, HQ. Each HQ session sees 500,000+ participants, and speed is very important because participants have less than 10 seconds to answer the quiz show questions.

In this scenario, a flow inspection policy is recommended to prioritize throughput. The success of the application depends on providing reliable service for large numbers of concurrent users. We will apply an IPS sensor to this policy to protect the server from external DOS attacks.

Proxy mode inspection use case

Because proxy mode provides the most thorough inspection, it is recommended that you apply proxy inspection to policies where preventing a data leak or malicious content is critical.

The following scenarios demonstrate common use cases for proxy inspection.

Scenario 1

Your organization deals with sensitive data on a regular basis and a data leak would significantly harm your business. At the same time, you wish to protect your employees from malicious content, such as viruses and phishing emails, which could be used to gain access to your network and the sensitive data on your systems.

In this scenario, a proxy inspection policy is recommended to prioritize network security. We want traffic inspection to be as thorough as possible to avoid any data leaks from exiting the LAN and any malicious content from entering it. On this policy, we will apply the virus filter, DLP filter, web filter, and email filter all operating in proxy mode.

Scenario 2

You have a corporate mail server in your domain, which is used by your employees for everyday business activities. You want to protect your employees from phishing emails and viruses. At the same time, you want to also protect your web servers from external attacks.

In this scenario, a proxy inspection policy is recommended to prioritize the safety of employee emails. Applying the antivirus and email filter in this mode allows us to most reliably filter out any malware and spam emails received by the mail servers via SMTP or MAPI. The IPS sensor can be used to prevent DOS attacks on the mail servers.

Inspection mode differences for Web Filter

This section identifies the behavioral differences between Web Filter operating in flow and proxy inspection.

Feature comparison between Web Filter inspection modes

The following table indicates which Web Filter features are supported by their designated inspection modes.

	FortiGuard CategoryBased Fil- ter	Category Usage Quota	Override Blocked Categories	File Filter	Search Engines	Static URL Filter	Rating Option	Proxy Option
Proxy	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Flow	Yes (1)	No	Yes (2)	No	No	Yes	Yes	No

1. Local Category and Remote Category filters do not support the warning and authenticate actions.
2. Local Category and Remote Category filters cannot be overridden.

Inspection mode differences for Email Filter

This section identifies the behavioral differences between Email Filter operating in flow and proxy inspection.

Feature comparison between Email Filter inspection modes

The following table indicates which Email Filters are supported by their designated inspection modes.

	SMTP	POP3	IMAP	MAPI
Proxy	Yes	Yes	Yes	Yes
Flow	Yes	Yes	Yes	No

Feature comparison between Email Filter inspection modes

The following tables indicate which Email Filters are supported by the specified inspection modes for local filtering and FortiGuard-assisted filtering.

Local Filtering	Banned Word Check	Black/ White List		HELO/ EHLO DNS Check		Return Address DNS Check	DNSBL/ ORBL Check	MIME Header Check		File Filter
Proxy	Yes	Yes		Yes		Yes	Yes	Yes		Yes
Flow	Yes	No		No		No	No	Yes		No
FortiGuard-Assisted Filtering	Phishing URL Check		Anti-Spam Black List Check		Submit Spam to FortiGuard		Spam Email Checksum Check		Spam URL Check
Proxy	Yes		Yes		Yes		Yes		Yes
Flow	No		No		No		No		No