Embarrassing question: Denied by forward policy...

[mbrowndcm]

Hello, I would like to allow only one host access to DNS from internal1 to wan1. This host is 192.168.100.10. I have a policy allowing that qualified source, to the destination known DNS servers. However, I am getting " denied by forward policy" when the qualified traffic traverses the firewall. The policy that qualifies this DNS traffic is followed by a policy that stops DNS from 192.168.100.0/24. It' s quite clear this is what' s blocking the packets, but how do I create a policy that allows the traffic as I desire? Thanks, Matt

[rwpatterson]

Policies are checked from top to bottom. Make sure your more granular policies (single DNS host) is at the top while your broader policies (entire company' s web surfing) is at or near the bottom. First good policy gets the traffic. Also make sure NAT is enabled on all policies that terminate on the Internet. Check the traffic monitor on the dashboard to see if your traffic is using the desired policy.

[emnoc]

Hint You might have to use the re-order button and move the fwpolicy up towards the top.

[mbrowndcm]

Thanks guys. I was a bit embarrassed to ask such a trivial question, but what you gonna do?! I had ordered the list so that it was before a policy explicitly denying that destination address. This is why I was so confused: src int: internal1 & dst int: wan1 1) source 192.168.100.0/24, destination 192.168.130.0/24, ANY port == allow 2) source 192.168.100.0/24, destination 192.168.210.0/24, ANY port == allow 3) source 192.168.100.0/24, destination 192.168.211.0/24, ANY port == allow 4) source 192.168.100.0/24, destination 192.168.212.0/24, ANY port == allow 5) source 192.168.100.0/24, destination [group: FTP_allow], FTP == allow 6) source 192.168.100.10/32, destination [group: DNS_allow], DNS == allow 7) source 192.168.100.0/24, destination ANY, HTTP, HTTPS, PING == allow 8) source ANY, destination ANY, ANY port == deny DNS_allow == three public DNS servers, not within the ranges declared. The DNS policy was not allowing traffic. The FTP policy was/is allowing traffic. The only thing that' s really different is the source address, but it still boggles my mind a little. I' ll move it to before the first policy entry and see what happens. Thanks guys, Matt

[rwpatterson]

By the way, policy #8 is ambiguous. With no allow policy, nothing happens, so removing #8 will get you the same result. The only difference is if you wish to log, #8 will allow that (I believe).

[mbrowndcm]

thanks bob. By theory of placing " policy 6" where it is in the above policy order, shouldn' t that traffic be allowed? This is what had me confused. By your reply, I suppose that placing " policy 6" before " policy 1" will allow the traffic?

[emnoc]

yes fwpolicy #6 should be allow and anywhere else above #8, it would be allowed. You don' t have any thing specific that says block " that" .So it should work no matter where you placed it & along as it was above fwpolicy #8. So when it was failing did you run a diagnostic debug flow to see where it was failing at?

[mbrowndcm]

Yes sir, denied by " policy 7." I will put the policy to be the first and debug again. When the policy is placed as the first policy, i do not get denials! When the policy where is was placed as the above, i do not get denials! Maybe I was asleep the other night while I was adjusting. Thanks guys.

[emnoc]

7) source 192.168.100.0/24, destination ANY, HTTP, HTTPS, PING == allow I don' t see how policy #7 is going to deny anything in regards to src/dst/services of #6. Fwpolicies as mention before , are top to bottom, 1st match , and others are ignored, and inclusive deny any, if no match, is a given. Since #7 is matching only on src 192.168.100.0/24 to any with services HTTP HTTPs, ICMP how is it going to deny anything in regards to traffic via #6 ? 6) source 192.168.100.10/32, destination [group: DNS_allow], DNS == allow Which is a host specific policy for dot 10 host & to whatever group DNS_Allow and a ALLOWED policy. When you reorder you policies, you should run the minimal debug and it will show you exactly what' s being denied by that traffic type & match & fwpolicy. e.g diag debug enable /* enable debug */ diag debug flow filter ( look at the match options you have and select one , you have many choice from src/dst/port/etc......) /* set filters and matches that you want to follow *. diag debug flow console diag debug flow trace start 200 /* start the debug and will trace upto 200 lines , increase/decrease as necessary */ it' a a good ideal to disable after your done diag debug flow stop diag debug disable Good luck