Policies not kicking in?

[davidinark]

I wasn' t sure how to phrase the title, so here goes my scenario: We are using Google Apps for Education. We should not have any SMTP traffic going out of our network except from two servers. My current config looks like this (in relation to smtp traffic): (Inside -> Outside) Policy ID 20, Source (server2 ip), (with mask/range of 255.255.255.255/255.255.255.255) Destination 173.194.77.[108-109], schedule always, service SMTP, SMTPS action Accept Log YES Policy ID 17, Source (server1 ip) (with mask/range of 255.255.255.255/255.255.255.255) Destination 173.194.77.[108-109], schedule always, service SMTP, SMTPS action Accept Log YES Policy ID 15 source all destination all schedule always, service SMTP action DENY Log YES I also ran the CLI command on Policy 15 for " set match-vip enable" at one point. Frankly, I don' t remember why now - something about VIP' s different than firewall. Who knows at this point. Traffic from server1 IP *does* pass email to Gmail. The log shows Allowed through rule 17. And email is delivered. Traffic from server2 IP *does NOT* pass email. The log shows Denied because of rule 15. Email is not delivered. Why is my Rule 20 not taking precedence here? Shouldn' t Rule 20 override 15? I tried adding server2 ip to Rule 17, but server2 smtp still gets blocked by rule 15. It is almost as if the settings are taking effect or something. Any ideas/thoughts/etc?

[ede_pfau]

I assume you have NAT checked on all 3 outgoing policies. If server2 traffic is hitting policy 15 then policy 20 isn' t catching it. You can check only 3 parameters: source IP, destination IP and service. One mismatch in these would explain that behavior. And no, despite all ongoing rants about specific bugs in FortiOS 4.3, I do trust my Fortigate 100% that firewalling still works! If you really want to find out, look at the traffic from server2:

 diag deb ena 
 diag deb sniff packet internal ' host <server2_IP>and dst 173.194.77.108' 

Stop output with Ctrl-C.

[davidinark]

Oh, I am with you on firewalling! My Fortigate 300C kicks the crud out of the stupid ISA box I used to have! Yes, NAT is enabled on the ALLOW policies, but I don' t have an option for NAT on the DENY policy. Should I? When I try the commands, here is what happens: diag deb ena - returns command prompt, I figure that' s normal. diag deb sniff packet internal... - Command parse error before ' sniff' Command Fail. Return Code -61 If I try just sniff packet... - I get Unknown Action 0 BTW, I am running v4.0,build0521,120313 (MR3 Patch 6) Thanks again for your help!

[davidinark]

Okay, I figured out the syntax. Now I get this when running the sniff: interfaces=[internal] filters=[host 10.10.10.4 and dst 173.194.77.108] pcap_open_live: ioctl: No such device for internal I have no idea what it' s telling me. :) Thanks for your patience! UGH- Nevermind, I am an idiot on this one. Okay, I figured out what my internal connector is called... Running the scan and will post my findings. Thanks!

[davidinark]

Tried to send email from affected server. No mail sent, none received at user' s email address. Log shows violation of Rule 15. Results from Packet Sniff: 148.994312 10.10.10.4.1852 -> 173.194.77.108.25: syn 1723470748 151.987466 10.10.10.4.1852 -> 173.194.77.108.25: syn 1723470748 158.002669 10.10.10.4.1852 -> 173.194.77.108.25: syn 1723470748 159.031135 10.10.10.4.1855 -> 173.194.77.108.25: syn 2269883771 162.064765 10.10.10.4.1855 -> 173.194.77.108.25: syn 2269883771 168.064362 10.10.10.4.1855 -> 173.194.77.108.25: syn 2269883771 169.061341 10.10.10.4.1858 -> 173.194.77.108.25: syn 967794184 172.001478 10.10.10.4.1858 -> 173.194.77.108.25: syn 967794184 178.016644 10.10.10.4.1858 -> 173.194.77.108.25: syn 967794184 179.085474 10.10.10.4.1861 -> 173.194.77.108.25: syn 485634371 182.063279 10.10.10.4.1861 -> 173.194.77.108.25: syn 485634371 188.078646 10.10.10.4.1861 -> 173.194.77.108.25: syn 485634371 189.115875 10.10.10.4.1864 -> 173.194.77.108.25: syn 3562851942 192.015567 10.10.10.4.1864 -> 173.194.77.108.25: syn 3562851942 198.030731 10.10.10.4.1864 -> 173.194.77.108.25: syn 3562851942 199.151897 10.10.10.4.1879 -> 173.194.77.108.25: syn 667362977 202.186634 10.10.10.4.1879 -> 173.194.77.108.25: syn 667362977 208.201773 10.10.10.4.1879 -> 173.194.77.108.25: syn 667362977 209.177854 10.10.10.4.1882 -> 173.194.77.108.25: syn 3320836714 212.138999 10.10.10.4.1882 -> 173.194.77.108.25: syn 3320836714 218.169730 10.10.10.4.1882 -> 173.194.77.108.25: syn 3320836714 21 packets received by filter 0 packets dropped by kernel

[ede_pfau]

good progress! OK, have you checked the policy? If you only allow SMTPS for instance then it' s not matched. If all params look OK, sniff on your WAN interface (I won' t tell you the name of the interface...as I don' t know your model and setup). Sorry for the ' sniff' lazyness, if you hit TAB the CLI will auto-complete.

[davidinark]

Ah, good to know about the tab! The policy is set for both SMTP and SMTPS, just like the one that works. It is so weird. Hmm... I' ve put in the name of my external port, but for host/dst I am not sure what to use. I tried the same numbers as internal, but that didn' t show any traffic. So, then I tried the public IP of my external connection and the dst as gmail, but that didn' t do anything either. Nor did using the internal ip of the filter. So, I tried just using ' dst 173...' but that also did not show any traffic. I guess that makes sense, though. Because if the filter is blocking it, then I shouldn' t see any traffic on the external side, right? And, if that' s the case, I' m thinking I may need to take this to Fortinet since we can' t seem to make it work...

[rwpatterson]

Change the policy service to ' any' . Chances are you' re missing the correct port. Sniff the traffic if (when) it works, and see if it' s outside the SMTP, SMPTS service range.

[davidinark]

When I change it to ANY, it still gets tripped up by the DENY policy that is BELOW it in the list!! It is as if that IP or that rule is being ignored. LOL (I laugh so that I do not cry or take a hammer to the thing).

[rwpatterson]

Go to the ' Top Sessions' widget, click on ' Details' in the bottom. Click to filter the source IP, put in the server' s IP address. Kill all sessions to policy #15, then try sending again.