Skip to main content
Fr34k11
Fr34k11
New Member
July 25, 2016
Question

Good old Denied by forward policy check (policy 0)

  • July 25, 2016
  • 4 replies
  • 12305 views

Hi all,

 

I have ran out of ideas, and I need some help :)

 

So I have two sites connecting to each other through a VPN. The VPN tunnel is up and running. So lets call them HQ and RS (remote site)

 

I'm trying to get to an IP 1.2.3.4 from RS, my breakout is through HQ.

Here is the output I get when I diagnose debug flow on HQ Firewall (the IP's are made up, I triple checked them to make sure I didn't incorrectly configure a route or something)

2016-07-25 16:28:55 id=20085 trace_id=1213 func=print_pkt_detail line=4420 msg="vd-INTERNAL received a packet(proto=1, [style="background-color: #00ff00;"]192.168.0.1[/style]:1->[style="background-color: #00ff00;"]1.2.3.4[/style]:8) from [style="background-color: #ffff00;"]RS1-P1[/style]. code=8, type=0, id=1, seq=2183." 2016-07-25 16:28:55 id=20085 trace_id=1213 func=init_ip_session_common line=4569 msg="allocate a new session-3a219fe1" 2016-07-25 16:28:55 id=20085 trace_id=1213 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-[style="background-color: #00ff00;"]10.10.10.10[/style] via [style="background-color: #00ffff;"]INTERNAL[/style]" 2016-07-25 16:28:55 id=20085 trace_id=1213 func=fw_forward_handler line=546 msg="Denied by forward policy check (policy 0)"

 

 

[style="background-color: #00ff00;"]10.10.10.10[/style] is an ASA and the traffic isn't getting there at all.

 

The IPsecs is setup in interface mode.

The VPN tunnel interfaces are in a zone and there is a policy for the zone.

config system zone     edit "[style="background-color: #00ffff;"]REMOTE_SITES[/style]"         set interface "RS1-P1" "RS2-P1" "RS3-P1"     next end

config firewall policy     edit 418         set srcintf "[style="background-color: #00ffff;"]REMOTE_SITES[/style]"         set dstintf "[style="background-color: #00ffff;"]INTERNAL[/style]"         set srcaddr "all"         set dstaddr "IP_[style="background-color: #00ff00;"]1.2.3.4[/style]"         set action accept         set schedule "always"         set service "ALL"     next end

 

Other info:

Fortigate 3000D in HA (A-P)

Firmware 5.2.4

You wont see a NAT, that is done elsewhere in the network and not relevant here.

 

Hope that is all, ask away if more info is needed, any help will be appreciated.

 

Thanks

    4 replies

    rwpatterson
    rwpatterson
    New Member
    July 25, 2016

    Did you create a static route to that site with a distance lower than your default gateway? That's the third part of any interface based IPSec tunnel. If you don't do that, the tunnel traffic will attempt to go out through your default gateway which won't work.

    emnoc
    emnoc
    New Member
    July 25, 2016

    2 more things

     

    1: check fwpolicy ordering for fwpolicy id 418

    2: ensure the vpn is open ( do you have SAs "bi-directional" )

     

     

     

    Fr34k11
    Fr34k11Author
    New Member
    July 26, 2016

    rwpatterson wrote:

    Did you create a static route to that site with a distance lower than your default gateway? That's the third part of any interface based IPSec tunnel. If you don't do that, the tunnel traffic will attempt to go out through your default gateway which won't work.

    Hmmm what will happen if the admin distance is the same? Does the static HAVE to be lower?

    If I recall correctly if you have two statics with the same admin distance the more specific route will be used.

    But with that said I don't know if that applies when one route is the default route. But hey it won't hurt to test :)

     

    emnoc wrote:

    2 more things

    1: check fwpolicy ordering for fwpolicy id 418

    2: ensure the vpn is open ( do you have SAs "bi-directional" )

    1: Yes I did check that, moved it to the top to test.

    2: Yip SA both ways are up.

     

    I don't think there is a problem with the VPN as such, more a routing/policy issue somewhere. It's probably very small and I'm just overlooking it.

     

    There are several of these remote sites and some of them are actually working so I'm investigating that right now. I'll add my findings shortly :)

     

    EDIT: Just to enlighten everyone here :)

    So after I did a step by step configuration check I found that the rule of the working site was using two objects, one incorrectly configured FQDN object and one correctly configured FQDN object. I just happen to use the incorrect one for the rule for the broken site... so yes like I said such a small thing.

    Terms & ConditionsAccessibility statement
    Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
    Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.
    Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!