Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Policies not kicking in?
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?
13 REPLIES 13
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Bob - self proclaimed posting junkie!See my Fortigate related scripts
at: http://fortigate.camerabob.com