Good old Denied by forward policy check (policy 0)

[Fr34k11]

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

[rwpatterson]

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]

2 more things

1: check fwpolicy ordering for fwpolicy id 418

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

[Fr34k11]

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.

[ede_pfau]

You're right, the more specific route is chosen. And by definition the default route ("the route of last resort") is the least specific route of all. So IMHO the distance doesn't matter here at all.

You could do us a favor and post the routing table (not the definitions), i.e. "get router info rout all".