Fortigate 100A - VPN Connection Attempts

[slarabee]

Hello,

I have a problem with this error:

2016-11-20 21:44:11 device_id=FG100A2906501673 log_id=0101023003 type=event subtype=ipsec pri=error loc_ip=xx.xxx.xx.xxx loc_port=500 rem_ip=216.218.206.74 rem_port=13214 out_if=wan1 vpn_tunnel=unknown cookies=3e35c70729dfedef/0000000000000000 action=negotiate status=negotiate_error msg="Negotiate SA Error: No matching gateway for new phase 1 request."

I changed the outside address in the message to protect my clients gateway info.

It appears that someone on Hurricane Electric's network is trying to hack into the vpn on this 100A. I get the error a couple of times per night and it is not one of the client's vpn users.

The thing is I have blocked that subnet in the firewall:

edit "Hurricane Electric Block California Fresno"         set subnet 216.218.128.0 255.255.128.0

    edit 20         set srcintf "wan2"         set dstintf "internal"         set srcaddr "Hurricane Electric Block California Fresno"         set dstaddr "all"         set schedule "always"         set service "ANY"         set logtraffic enable

I don't understand why "set action deny" is not showing up in any of my denied blocks.

Here is the gui screenshot of the policy above:

Not sure what the problem is but when I block addresses or subnets the system still seems to allow connections.

Unopened ports are blocked by default so I have the system fairly secure but I do not want hacker wannabes trying to connect to my vpn.

TIA

Sean

[63kk0]

slarabee (Sean),

Apologies for the extremely late reply, but thought I would reply anyway since I had faced a similar problem several years ago.  Hopefully this will help another lost soul having this problem.  The solution is to use your "Hurricane Electric Block California Fresno" firewall address object in what is called a "local-in-policy". 

Not sure what FortiOS your 100A is running since that hardware went out of support years ago, but here is sample code from a FortiGate running 6.2 FortiOS.  Note, I have created address group "BlockSources" as a group of address groups because I have other groups of addresses in that group.  My example excluded all other groups than the one I have for Hurricane Electric address objects "HurricaneElectric_AS6939":

------------------------------------------------------------------------------------------------

config firewall address

    edit "HurricaneElectric_74.82.0.0-18"

        set comment "74.82.0.0/18 attempt from 74.82.47.22"

        set subnet 74.82.0.0 255.255.192.0

    next

    edit "HurricaneElectric_216.218.128.0"

        set comment "216.218.128.0/17"

        set subnet 216.218.128.0 255.255.128.0

    next

end

config firewall addrgrp

    edit "HurricaneElectric_AS6939"

        set member "HurricaneElectric_74.82.0.0-18" "HurricaneElectric_216.218.128.0"

        set comment "Hurricane Electric ASN 6939 https://scamalytics.com/i...hurricane-electric-llc"

    next

    edit "BlockSources"

        set member "HurricaneElectric_AS6939"

    next end config firewall local-in-policy

    edit 1

        set intf "wan1"

        set srcaddr "BlockSources"

        set dstaddr "all"

        set action deny

        set service "ALL_TCP" "ALL_UDP"

        set schedule "always"

        set status enable

        set comments "Block connection attempt sources on all ports wan"

    next

end

------------------------------------------------------------------------------------------------

Cheers!

63kk0

[Debbie_FTNT]

To elaborate on the above:
When a FortiGate receives traffic, first it checks if that traffic is intended for itself - does the traffic destination IP match an interface IP, secondary IP or virtual IP, basically.
If yes, then regular policies are irrelevant; they only apply for traffic through the FortiGate, not to it.
The solution is indeed to create a policy for traffic to the FortiGate itself (local-in policy) and set the action to deny there.