Fortinet Document Library

Version:

Version:


Table of Contents

Administration Guide

Download PDF
Copy Link

Blocking unwanted IKE negotiations and ESP packets with a local-in policy

It is not unusual to receive IPsec connection attempts or malicious IKE packets from all over the internet. Malicious parties use these probes to try to establish an IPsec tunnel in order to gain access to your private network. A good way to prevent this is to use local-in policies to deny such traffic.

Sometimes there are malicious attempts using crafted invalid ESP packets. These invalid attempts are automatically blocked by the FOS IPsec local-in handler when it checks the SPI value against the SAs of existing tunnels. The IPsec local-in handler processes the packet instead of the firewall's local-in handler. So when these attempts are blocked, you will notice an unknown SPI message in your VPN logs instead of being silently blocked by your local-in policy. These log messages are rate limited.

Sample log and alert email
Message meets Alert condition
date=2020-08-11 time=09:28:40 devname=toSite1 devid=FGT60Fxxxxxxxxxx logid="0101037131" type="event" subtype="vpn" level="error" vd="root" eventtime=1597163320747963100 tz="-0700" logdesc="IPsec ESP" msg="IPsec ESP" action="error" remip=131.62.25.102 locip=192.157.116.88 remport=40601 locport=500 outintf="wan1" cookies="N/A" user="N/A" group="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="N/A" status="esp_error" error_num="Received ESP packet with unknown SPI." spi="f6c9e2x1" seq="02000400"

Note that invalid SPIs may not always indicate malicious activity. For example, the SPI may not match during rekey, or when one unit flushes its tunnel SAs. Administrators should collect as much information as possible before making a conclusion.

To block undesirable IPsec connection attempts and IKE packets using a local-in policy:
  1. Configure an address group that excludes legitimate IPs:
    config firewall addrgrp
        edit "All_exceptions"
            set member "all"
            set exclude enable
            set exclude-member "remote-vpn"
        next
    end
  2. Create a local-in policy that blocks IKE traffic from the address group:
    config firewall local-in-policy
        edit 1
            set intf "wan1"
            set srcaddr "All_exceptions"
            set dstaddr "all"
            set service "IKE"
            set schedule "always"
        next
    end
    Note

    The default action is deny.

  3. Verify the traffic blocked by the local-in policy:
    # diagnose debug flow filter dport 500
    # diagnose debug flow trace start 10
    # diagnose debug enable
    
    id=20085 trace_id=290 func=print_pkt_detail line=5588 msg="vd-root:0 received a packet(proto=17, 10.10.10.13:500->10.10.10.1:500) from wan1. "
    id=20085 trace_id=290 func=init_ip_session_common line=5760 msg="allocate a new session-003442e7"
    id=20085 trace_id=290 func=vf_ip_route_input_common line=2598 msg="find a route: flag=84000000 gw-10.10.10.1 via root"
    id=20085 trace_id=290 func=fw_local_in_handler line=430 msg="iprope_in_check() check failed on policy 1, drop"

Blocking unwanted IKE negotiations and ESP packets with a local-in policy

It is not unusual to receive IPsec connection attempts or malicious IKE packets from all over the internet. Malicious parties use these probes to try to establish an IPsec tunnel in order to gain access to your private network. A good way to prevent this is to use local-in policies to deny such traffic.

Sometimes there are malicious attempts using crafted invalid ESP packets. These invalid attempts are automatically blocked by the FOS IPsec local-in handler when it checks the SPI value against the SAs of existing tunnels. The IPsec local-in handler processes the packet instead of the firewall's local-in handler. So when these attempts are blocked, you will notice an unknown SPI message in your VPN logs instead of being silently blocked by your local-in policy. These log messages are rate limited.

Sample log and alert email
Message meets Alert condition
date=2020-08-11 time=09:28:40 devname=toSite1 devid=FGT60Fxxxxxxxxxx logid="0101037131" type="event" subtype="vpn" level="error" vd="root" eventtime=1597163320747963100 tz="-0700" logdesc="IPsec ESP" msg="IPsec ESP" action="error" remip=131.62.25.102 locip=192.157.116.88 remport=40601 locport=500 outintf="wan1" cookies="N/A" user="N/A" group="N/A" xauthuser="N/A" xauthgroup="N/A" assignip=N/A vpntunnel="N/A" status="esp_error" error_num="Received ESP packet with unknown SPI." spi="f6c9e2x1" seq="02000400"

Note that invalid SPIs may not always indicate malicious activity. For example, the SPI may not match during rekey, or when one unit flushes its tunnel SAs. Administrators should collect as much information as possible before making a conclusion.

To block undesirable IPsec connection attempts and IKE packets using a local-in policy:
  1. Configure an address group that excludes legitimate IPs:
    config firewall addrgrp
        edit "All_exceptions"
            set member "all"
            set exclude enable
            set exclude-member "remote-vpn"
        next
    end
  2. Create a local-in policy that blocks IKE traffic from the address group:
    config firewall local-in-policy
        edit 1
            set intf "wan1"
            set srcaddr "All_exceptions"
            set dstaddr "all"
            set service "IKE"
            set schedule "always"
        next
    end
    Note

    The default action is deny.

  3. Verify the traffic blocked by the local-in policy:
    # diagnose debug flow filter dport 500
    # diagnose debug flow trace start 10
    # diagnose debug enable
    
    id=20085 trace_id=290 func=print_pkt_detail line=5588 msg="vd-root:0 received a packet(proto=17, 10.10.10.13:500->10.10.10.1:500) from wan1. "
    id=20085 trace_id=290 func=init_ip_session_common line=5760 msg="allocate a new session-003442e7"
    id=20085 trace_id=290 func=vf_ip_route_input_common line=2598 msg="find a route: flag=84000000 gw-10.10.10.1 via root"
    id=20085 trace_id=290 func=fw_local_in_handler line=430 msg="iprope_in_check() check failed on policy 1, drop"