Redundant hub and spoke VPN

This recipe provides sample configuration of hub and spoke IPsec VPN. The following applies for this scenario:

l The spokes have two WAN interfaces and two IPsec VPN tunnels for redundancy. l The secondary VPN tunnel is up only when the primary tunnel is down by dead peer detection.

The following shows the sample network topology for this recipe:

As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the CLI commands as shown below.

To configure redundant hub and spoke VPN using the FortiOS CLI:

1. Configure the hub:
2. Configure the WAN, internal interface, and static route:

config system interface edit “port13” set alias “WAN”

set ip 172.16.202.1 255.255.255.0

next edit “port9” set alias “Internal” set ip 172.16.101.1 255.255.255.0

next

end

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

next end

1. Configure the IPsec phase1-interface and phase2-interface:

config vpn ipsec phase1-interface edit “hub” set type dynamic set interface “port13” set peertype any set net-device enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set dpd on-idle set psksecret sample set dpd-retryinterval 60

next

end

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

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

next

end

1. Configure the firewall policy:

config firewall policy

edit 1 set name “spoke-hub” set srcintf “hub” set dstintf “port9” set srcaddr “all” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next edit 2 set name “spoke-spoke” set srcintf “hub” set dstintf “hub” set srcaddr “all” set dstaddr “all” set action accept set schedule “always” set service “ALL”

next

end

2. Configure the spokes:
3. Configure the WAN, internal interface, and static route:
4. Configure Spoke1:

config system interface edit “port1” set ip 172.16.200.1 255.255.255.0

next edit “wan1”

set mode dhcp set distance 10 set priority 100

next edit “dmz”

 

ip 10.1.100.1 255.255.255.0

end

config router static

edit 1 set gateway 172.16.200.2 set device “port1”

next

end

1. Configure Spoke2:

config system interface edit “wan1” set ip 172.16.200.3 255.255.255.0

next edit “wan2”

set mode dhcp set distance 10 set priority 100

next edit “lan1” set ip 192.168.4.1 255.255.255.0

next

end

config router static

edit 1 set gateway 172.16.200.2 set device “wan1”

next

end

1. Configure IPsec phase1-interface and phase2-interface:
2. Configure Spoke1:

config vpn ipsec phase1-interface edit “primary” set interface “port1” set peertype any set net-device enable

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

next

edit “secondary” set interface “wan1” set peertype any set net-device enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.16.202.1 set monitor “primary” set psksecret sample

next

end

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

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

set auto-negotiate enable

src-subnet 10.1.100.0 255.255.255.0

edit “secondary” set phase1name “secondary”

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

set auto-negotiate enable set src-subnet 10.1.100.0 255.255.255.0

next

end

1. Configure Spoke2:

config vpn ipsec phase1-interface edit “primary” set interface “wan1” set peertype any set net-device enable

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

next

edit “secondary” set interface “wan2” set peertype any set net-device enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.16.202.1 set monitor “primary” set psksecret sample

next

end

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

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

set auto-negotiate enable set src-subnet 192.168.4.0 255.255.255.0

next edit “secondary” set phase1name “secondary”

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

set auto-negotiate enable set src-subnet 192.168.4.0 255.255.255.0

next

end

1. Configure the firewall policy:
   1. Configure Spoke1:

config firewall policy edit 1 set srcintf “dmz” set dstintf “primary” “secondary” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always”

service “ALL”

end

1. Configure Spoke2:

config firewall policy edit 1 set srcintf “lan1” set dstintf “primary” “secondary” set srcaddr “192.168.4.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next

end

1. Configure the static route:
   1. Configure Spoke1:

config router static edit 3 set dst 172.16.101.0 255.255.255.0 set distance 1 set device “primary”

next edit 4 set dst 172.16.101.0 255.255.255.0 set distance 3 set device “secondary”

next

end

1. Configure Spoke2:

config router static edit 3 set dst 172.16.101.0 255.255.255.0 set distance 1 set device “primary”

next edit 4 set dst 172.16.101.0 255.255.255.0 set distance 3 set device “secondary”

next

end

3. Run diagnose and get commands:
4. Run the Spoke1 # diagnose vpn tunnel list command. The system should return the following: name=primary 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=15 ilast=0 olast=0 ad=/0 stat: rxp=1879 txp=1881 rxb=225480 txb=112860

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=1 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=primary proto=0 sa=1 ref=2 serial=2 auto-negotiate src: 0:10.1.100.0/255.255.255.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=41002/0B replaywin=2048 seqno=758 esn=0 replaywin_lastseq=00000758 itn=0

 

life: type=01 bytes=0/0 timeout=42901/43200 dec: spi=0908732f esp=aes key=16

20770dfe67ea22dd8ec32c44d84ef4d5 ah=sha1 key=20 edc89fc2ec06309ba13de95e7e486f9b795b8707

enc: spi=a1d9eed1 esp=aes key=16 8eeea2526fba062e680d941083c8b5d1 ah=sha1 key=20 f0f5deaf88b2a69046c3154e9f751739b3f411f5

dec:pkts/bytes=1879/112740, enc:pkts/bytes=1879/225480

name=secondary ver=1 serial=2 172.17.200.1:0->172.16.202.1:0

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

proxyid_num=1 child_num=0 refcnt=10 ilast=1892 olast=1892 ad=/0 stat: rxp=0 txp=0 rxb=0 txb=0

dpd: mode=on-demand on=0 idle=20000ms retry=3 count=0 seqno=0 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=secondary proto=0 sa=0 ref=2 serial=2 auto-negotiate src: 0:10.1.100.0/255.255.255.0:0 dst: 0:0.0.0.0/0.0.0.0:0

1. Run the Spoke1 # get router info routing-table static command. The system should return the following:

Routing table for VRF=0 …………….

S 172.16.101.0/24 [1/0] is directly connected, primary

IPsec aggregate to achieve redundancy and traffic load-balancing

The recipe gives a sample configuration of using IPsec aggregate to achieve redundancy and traffic load-balancing:

l Multiple site-to-site IPsec VPN (net-device disable) tunnel interfaces as member of ipsec-aggregate l Four load-balancing algorithms: round-robin (default), L3, L4, redundant The following shows the sample network topology for this recipe:

As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the CLI commands as shown below.

To configure IPsec aggregate to achieve redundancy and traffic load-balancing using the CLI:

1. Configure the WAN interface and static route. Each FortiGate has two WAN interfaces connected to different ISPs.

The ISP1 link is for the primary FortiGate and the IPS2 link is for the secondary FortiGate: a. Configure HQ1:

config system interface edit “port1” set alias to_ISP1

set ip 172.16.200.1 255.255.255.0

next edit “port2” set alias to_ISP2

set ip 172.17.200.1 255.255.255.0

next

end

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

next edit 2 set gateway 172.17.200.3 set device “port2” set priority 100

next

end

1. Configure HQ2:

config system interface edit “port25”

set alias to_ISP1

set ip 172.16.202.1 255.255.255.0

next edit “port26” set alias to_ISP2

set ip 172.17.202.1 255.255.255.0

next

end

config router static

edit 1 set gateway 172.16.202.2 set device “port25”

next edit 2 set gateway 172.17.202.2 set device “port26” set priority 100

next

end

2. Configure the internal (protected subnet) interface:
   1. Configure HQ1:

config system interface edit “dmz” set ip 10.1.100.1 255.255.255.0

next

end

1. Configure HQ2:

config system interface edit “port9” set ip 172.16.101.1 255.255.255.0

next

end

3. Configure the IPsec phase-1 and phase-2 interfaces. On each FortiGate, configure two site-to-site phase-1 interfaces with net-device disable:
   1. Configure HQ1:

config vpn ipsec phase1-interface edit “pri_HQ2” set interface “port1” set peertype any set net-device disable

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

next edit “sec_HQ2” set interface “port2” set peertype any set net-device disable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.17.202.1 set psksecret sample2

next end

config vpn ipsec phase2-interface edit “pri_HQ2”

set phase1name “pri_HQ2”

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

set auto-negotiate enable

next edit “sec_HQ2” set phase1name “sec_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 phase1-interface edit “pri_HQ1” set interface “port25” set peertype any set net-device disable

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

next edit “sec_HQ1” set interface “port26” set peertype any set net-device disable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.17.200.1 set psksecret sample2

next

end

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

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

set auto-negotiate enable

next edit “sec_HQ1” set phase1name “sec_HQ1”

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

set auto-negotiate enable

next

end

4. Configure ipsec-aggregate:
   1. Configure HQ1:

config system ipsec-aggregate edit “agg_HQ2” set member “pri_HQ2” “sec_HQ2”

next

end

1. Configure HQ2:

config system ipsec-aggregate edit “agg_HQ1” set member “pri_HQ” “sec_HQ1”

next

end

5. Configure the firewall policy:
   1. Configure HQ1:

config firewall policy edit 1 set name “inbound” set srcintf “agg_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 “agg_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 “agg_HQ1” set dstintf “port9” set srcaddr “10.1.100.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 “agg_HQ1” set srcaddr “172.16.101.0” set dstaddr “10.1.100.0” set action accept set schedule “always” set service “ALL”

next

end

6. Assign an IP address to the ipsec-aggregate In this example, OSPF runs over the ipsecaggregate interface. No IP address is required for the static route HQ1: a. Configure HQ1:

config system interface edit “agg_HQ2”

set ip 10.10.10.1 255.255.255.255

set remote-ip 10.10.10.2 255.255.255.255

next

end

1. Configure HQ2:

config system interface edit “agg_HQ1”

set ip 10.10.10.2 255.255.255.255

set remote-ip 10.10.10.1 255.255.255.255

next

end

7. Configure OSPF:
8. Configure HQ1:

config router ospf set router-id 1.1.1.1 config area edit 0.0.0.0 next

end config network

edit 1 set prefix 10.1.100.0 255.255.255.0

next edit 2 set prefix 10.10.10.0 255.255.255.0

next

end

end

1. Configure HQ2:

config router ospf set router-id 2.2.2.2 config area edit 0.0.0.0 next

end config network

edit 1 set prefix 172.16.101.0 255.255.255.0

next edit 2 set prefix 10.10.10.0 255.255.255.0

next

end

end

8. Run diagnose commands:
9. Run the diagnose vpn ike gateway list command. The system should return the following:

vd: root/0 name: pri_HQ2 version: 1 interface: port1 11

addr: 172.16.200.1:500 -> 172.16.202.1:500 created: 1520s ago

IKE SA: created 1/2 established 1/1 time 10/10/10 ms

IPsec SA: created 2/2 established 1/1 time 0/0/0 ms id/spi: 173 dcdede154681579b/e32f4c48c4349fc0 direction: responder status: established 1498-1498s ago = 10ms proposal: aes128-sha256 key: d7230a68d7b83def-588b94495cfa9d38 lifetime/rekey: 86400/84631 DPD sent/recv:

0000000d/00000006 vd: root/0 name: sec_HQ2 version: 1 interface: port2 12

addr: 172.17.200.1:500 -> 172.17.202.1:500

created: 1520s ago

IKE SA: created 1/2 established 1/1 time 10/10/10 ms

IPsec SA: created 2/2 established 1/1 time 0/0/0 ms id/spi: 174 a567bd7bf02a04b5/4251b6254660aee2 direction: responder status: established 1498-1498s ago = 10ms proposal: aes128-sha256 key:

9f44f500c28d8de6-febaae9d1e6a164c lifetime/rekey: 86400/84631 DPD sent/recv:

00000008/0000000c

1. Run the diagnose vpn tunnel list command. The system should return the following:

list all ipsec tunnel in vd 0

name=sec_HQ2 ver=1 serial=2 172.17.200.1:0->172.17.202.1:0

bound_if=5 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/512 options[0200]=frag-rfc run_state=1 accept_traffic=1

proxyid_num=1 child_num=0 refcnt=7 ilast=5 olast=5 ad=/0 stat: rxp=39 txp=40 rxb=5448 txb=2732

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=15 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=sec_HQ2 proto=0 sa=1 ref=2 serial=2 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=41230/0B replaywin=2048

seqno=29 esn=0 replaywin_lastseq=00000028 itn=0

life: type=01 bytes=0/0 timeout=42899/43200 dec: spi=1071b4f9 esp=aes key=16

1f4dbb78bea8e97650b52d8170b5ece7 ah=sha1 key=20 cd9bf2de0f49296cf489dd915d7baf6d78bc8f12

enc: spi=ec89b7ee esp=aes key=16 0546efecd0d1b9ba5944f635896e4404 ah=sha1 key=20 34599bc7dc25e1ce63ac9615bd50928ce0667dc8

dec:pkts/bytes=39/2796, enc:pkts/bytes=40/5456

name=pri_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/512 options[0200]=frag-rfc run_state=1 accept_traffic=1

proxyid_num=1 child_num=0 refcnt=5 ilast=15 olast=15 ad=/0 stat: rxp=38 txp=39 rxb=5152 txb=2768

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=20 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=pri_HQ2 proto=0 sa=1 ref=2 serial=2 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=41231/0B replaywin=2048

seqno=28 esn=0 replaywin_lastseq=00000027 itn=0

life: type=01 bytes=0/0 timeout=42900/43200 dec: spi=1071b4f8 esp=aes key=16

142cce377b3432ba41e64128ade6848c ah=sha1 key=20 20e64947e2397123f561584321adc0e7aa0c342d

enc: spi=ec89b7ed esp=aes key=16 2ec13622fd60dacce3d28ebe5fe7ab14 ah=sha1 key=20 c1787497508a87f40c73c0db0e835c70b3c3f42d

dec:pkts/bytes=38/2568, enc:pkts/bytes=39/5432

1. Run the diagnose sys ipsec-aggregate list The system should return the following:

agg_HQ2 algo=RR member=2 run_tally=2 members: pri_HQ2 sec_HQ2

1. Run the get router info ospf neighbor The system should return the following:

OSPF process 0, VRF 0:

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 1. Full/ – 00:00:34 10.10.10.2 agg1_HQ2

1. Run the get router info routing-table ospf The system should return the following:

Routing table for VRF=0

O 172.16.101.0/24 [110/20] via 10.10.10.2, agg1_HQ2 , 00:18:43

OSPF with IPsec VPN to achieve network redundancy

This recipe provides sample configuration of using OSPF with IPsec VPN to achieve network redundancy. Route selection is based on OSPF cost calculation. It is easy to achieve ECMP or primary/secondary routes by adjusting OSPF path cost.

The following shows the sample network topology for this recipe:

As only partial configuration can be completed from the GUI, it is recommended to achieve this configuration via the CLI commands as shown below.

To configure OSPF with IPsec VPN to achieve network redundancy using the CLI:

1. Configure the WAN interface and static route. Each FortiGate has two WAN interfaces connected to different ISPs.

The ISP1 link is for the primary FortiGate and the IPS2 link is for the secondary FortiGate: a. Configure HQ1:

config system interface edit “port1” set alias to_ISP1

set ip 172.16.200.1 255.255.255.0

next edit “port2” set alias to_ISP2

set ip 172.17.200.1 255.255.255.0

next

end

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

next edit 2 set gateway 172.17.200.3 set device “port2” set priority 100

next

end

1. Configure HQ2:

config system interface edit “port25” set alias to_ISP1

set ip 172.16.202.1 255.255.255.0

next edit “port26” set alias to_ISP2

set ip 172.17.202.1 255.255.255.0

next

end

config router static edit 1 set gateway 172.16.202.2

set device “port25”

next edit 2 set gateway 172.17.202.2 set device “port26” set priority 100

next

end

2. Configure the internal (protected subnet) interface:
   1. Configure HQ1:

config system interface edit “dmz” set ip 10.1.100.1 255.255.255.0

next

end

1. Configure HQ2:

config system interface edit “port9” set ip 172.16.101.1 255.255.255.0

next

end

3. Configure IPsec phase1-interface and phase-2 interface. On each FortiGate, configure two IPsec tunnels: a primary and a secondary: Configure HQ1:

config vpn ipsec phase1-interface edit “pri_HQ2” set interface “port1” set peertype any set net-device enable

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

next edit “sec_HQ2” set interface “port2” set peertype any set net-device enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.17.202.1 set psksecret sample2

next end

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

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

set auto-negotiate enable

next edit “sec_HQ2” set phase1name “sec_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 phase1-interface edit “pri_HQ1” set interface “port25” set peertype any set net-device enable

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

next edit “sec_HQ1” set interface “port26” set peertype any set net-device enable

set proposal aes128-sha256 aes256-sha256 aes128-sha1 aes256-sha1 set remote-gw 172.17.200.1 set psksecret sample2

next

end

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

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

set auto-negotiate enable

next edit “sec_HQ1” set phase1name “sec_HQ1”

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

set auto-negotiate enable

next

end

4. Configure an inbound and outbound firewall policy for each IPsec tunnel:
5. Configure HQ1:

config firewall policy

edit 1 set name “pri_inbound” set srcintf “pri_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 “pri_outbound” set srcintf “dmz” set dstintf “pri_HQ2” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL” next

edit 3

set name “sec_inbound” set srcintf “sec_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 4

set name “sec_outbound” set srcintf “dmz” set dstintf “sec_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 “pri_inbound” set srcintf “pri_HQ1” set dstintf “port9” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next edit 2

set name “pri_outbound” set srcintf “port9” set dstintf “pri_HQ1” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next edit 3

set name “sec_inbound” set srcintf “sec_HQ1” set dstintf “port9” set srcaddr “10.1.100.0” set dstaddr “172.16.101.0” set action accept set schedule “always” set service “ALL”

next edit 4

set name “sec_outbound” set srcintf “port9” set dstintf “sec_HQ1” set srcaddr “172.16.101.0” set dstaddr “10.1.100.0” set action accept set schedule “always” set service “ALL”

next

end

5. Assign an IP address to the IPsec tunnel interface:
6. Configure HQ1:

config system interface

edit “pri_HQ2”

set ip 10.10.10.1 255.255.255.255

set remote-ip 10.10.10.2 255.255.255.255

next edit “sec_HQ2”

set ip 10.10.11.1 255.255.255.255 set remote-ip 10.10.11.2 255.255.255.255

next

end

1. Configure HQ2:

config system interface

edit “pri_HQ1”

set ip 10.10.10.2 255.255.255.255

set remote-ip 10.10.10.1 255.255.255.255

next

edit “sec_HQ1”

set ip 10.10.11.2 255.255.255.255 set remote-ip 10.10.11.1 255.255.255.255

next

end

6. Configure OSPF:
7. Configure HQ1:

config router ospf

set router-id 1.1.1.1 config area

edit 0.0.0.0 next

end config ospf-interface

edit “pri_HQ2” set interface “pri_HQ2” set cost 10 set network-type point-to-point

next edit “sec_HQ2” set interface “sec_HQ2” set cost 20 set network-type point-to-point

next

end config network

edit 1 set prefix 10.10.10.0 255.255.255.0

next edit 2

set prefix 10.10.11.0 255.255.255.0

next edit 3 set prefix 10.1.100.0 255.255.255.0

next

end

end

1. Configure HQ2:

config router ospf set router-id 2.2.2.2 config area edit 0.0.0.0 next

end

config ospf-interface edit “pri_HQ1” set interface “pri_HQ1”

set cost 10

set network-type point-to-point

next edit “sec_HQ1” set interface “sec_HQ1”

set cost 20

set network-type point-to-point

next

end config network edit 1 set prefix 10.10.10.0 255.255.255.0

next edit 2 set prefix 10.10.11.0 255.255.255.0

next edit 3 set prefix 172.16.101.0 255.255.255.0

next

end

end

7. Run diagnose/get commands to check VPN and OSPF states:
8. Run the HQ1 # diagnose vpn ike gateway list command. The system should return the following:

vd: root/0 name: pri_HQ2 version: 1 interface: port1 11 addr: 172.16.200.1:500 -> 172.16.202.1:500 virtual-interface-addr: 10.10.10.1 -> 10.10.10.2 created: 1024s ago

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

IPsec SA: created 1/3 established 1/2 time 0/5/10 ms id/spi: 45 d184777257b4e692/e2432f834aaf5658 direction: responder status:

established 1024-1024s ago = 0ms proposal: aes128-sha256 key: 9ed41fb06c983344189538046f5ad204 lifetime/rekey: 86400/85105 DPD sent/recv: 00000003/00000000 vd: root/0

name: sec_HQ2 version: 1 interface: port2 12 addr: 172.17.200.1:500 -> 172.17.202.1:500 virtual-interface-addr: 10.10.11.1 -> 10.10.11.2 created: 346s ago

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

IPsec SA: created 1/1 established 1/1 time 0/10/15 ms id/spi: 48 d909ed68636b1ea5/163015e73ea050b8 direction: initiator status:

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

29db9fbafa256152 lifetime/rekey: 86400/86099 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=pri_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=14 ilast=2 olast=2 ad=/0 stat: rxp=102 txp=105 rxb=14064 txb=7816

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=3 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=pri_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=42254/0B replaywin=2048

seqno=6a esn=0 replaywin_lastseq=00000067 itn=0

life: type=01 bytes=0/0 timeout=42932/43200 dec: spi=1071b4ee esp=aes key=16

032036b24a4ec88da63896b86f3a01db ah=sha1 key=20 3962933e24c8da21c65c13bc2c6345d643199cdf

enc: spi=ec89b7e3 esp=aes key=16 92b1d85ef91faf695fca05843dd91626 ah=sha1 key=20 2de99d1376506313d9f32df6873902cf6c08e454

dec:pkts/bytes=102/7164, enc:pkts/bytes=105/14936

name=sec_HQ2 ver=1 serial=2 172.17.200.1:0->172.17.202.1:0

bound_if=12 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=14 ilast=3 olast=0 ad=/0 stat: rxp=110 txp=114 rxb=15152 txb=8428

dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=3 natt: mode=none draft=0 interval=0 remote_port=0 proxyid=sec_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=2 esn=0 replaywin_lastseq=00000002 itn=0

life: type=01 bytes=0/0 timeout=42931/43200 dec: spi=1071b4ef esp=aes key=16 bcdcabdb7d1c7c695d1f2e0f5441700a

ah=sha1 key=20 e7a0034589f82eb1af41efd59d0b2565fef8d5da

enc: spi=ec89b7e4 esp=aes key=16 234240b69e61f6bdee2b4cdec0f33bea ah=sha1 key=20 f9d4744a84d91e5ce05f5984737c2a691a3627e8

dec:pkts/bytes=1/68, enc:pkts/bytes=1/136

1. Run the HQ1 # get router info ospf neighbor The system should return the following:

OSPF process 0, VRF 0:

Neighbor ID Pri State Dead Time Address Interface

2.2.2.2 1. Full/ – 00:00:37 10.10.10.2 pri_HQ2

2.2.2.2 1. Full/ – 00:00:32 10.10.11.2 sec_HQ2

1. Run the HQ1 # get router info routing-table ospf The system should return the following:

Routing table for VRF=0

O 172.16.101.0/24 [110/20] via 10.10.10.2, pri_HQ2 , 00:03:21 In case the primary tunnel is down after route convergence.

1. Run the HQ1 # get router info routing-table ospf The system should return the following:

Routing table for VRF=0

O 172.16.101.0/24 [110/110] via 10.10.11.2, sec_HQ2 , 00:00:01

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.