Skip to main content
slarabee
slarabee
New Member
November 21, 2016
Question

Fortigate 100A - VPN Connection Attempts

  • November 21, 2016
  • 2 replies
  • 4722 views

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

 

 

    2 replies

    63kk0
    63kk0
    Visitor III
    November 11, 2021

    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
    Staff & Editor
    Debbie_FTNT
    Staff & Editor
    November 17, 2021

    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.

    Terms & ConditionsAccessibility statement