Skip to main content
Andre_Backs
Andre_Backs
New Member
May 9, 2014
Question

newbie question: policy rules ordering

  • May 9, 2014
  • 2 replies
  • 9037 views
Hello all, I am new to the FortiOS, but familiar to Checkpoint NGX. Currently I am working on our new Fortigate 200D and migrating our current firewall settings to this box (It' s a hell of a job ) I was wondering though what the best ordering is for the firewall rules. obviously outgoing NAT rules go above more general rules. But e.g. should one group all incoming rules going to VIP-address before internal rules going to the nonnatted addresses, or is a grouping by, say, server more appropriate. something like: all -> vip-server_one all -> vip-server_two all -> vip-server_three all -> server_one all -> server_two all -> server_three or: all -> vip-server_one all -> server_one all -> vip-server_two all -> server_two all -> vip-server_three all -> server_three

    2 replies

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    May 9, 2014
    Hi, and welcome to the forums. I must admit I' m a bit puzzled by your question. By default, the policy table is displayed grouping interface pairs. A policy controls traffic between 2 interfaces. So this grouping seems natural. If you want to search through all policies at once you can switch the display to ' global' . This only holds true for one exception: if you use the ' any' interface anywhere then the grouped display will no longer be available. Generally one should avoid using ' any' to denote an interface. You should know in advance which path data is taking through your firewall. (OTOH, sniffing the ' any' interface quickly shows where traffic is coming in or going out if you don' t know!) Then...grouping inbound policies by destination...more or less this is to your liking. The general rule is that more specific policies must be defined above more general policies. Otherwise, the more specific policy can be shadowed. I personally have never had a situation where I had an incoming policy to a VIP, and another one to the real server' s address at the same time. Internal servers tend to have non-routeable addresses which prevents direct access from the WAN. One tip: if unsure you can add the ' Count' field to the policy table display, to see that and how much traffic hits a policy. In FOS v5, there even is a field with ' last seen' timestamp.
    Andre_Backs
    Andre_BacksAuthor
    New Member
    May 10, 2014
    Hi Ede, thanks for your answer. The grouped display doesn' t (yet) work for me since I have a lot of rules with the " any" interface. Part of this has to do with lazyness () as I don' t want to set up rules concerning traffic to a server for every interface seperately (I won' t bother you all with the specifics of my infrastructure) Part has also to do with a split brain DNS problem I have. Some of our clients connect via an IPSec tunnel and use a DNS server on the inside of our network (to resolve probiblio.nl to internal IP addresses) Occasionaly the tunnel drops its connection. DNS cache at the client side gets contaminated with an external IP address. After the tunnel is up again the servers no longer can be reached. The external IP address gets NATted and replies are routed back internaly. Accessing the VIP-addres from the inside interface seems to solve that problem (at least in my lab) But, it is a learning process. My major objective now is to do a one in one replacement of the Checkpoint without disrupting the rest of the infrastructure. In the future we may be able to make adjustments to clear things up.
    Dave_Hall
    Dave_Hall
    New Member
    May 9, 2014
    Hi Andre. Welcome to the forums. You may want to take a look at the FortiConverter as a possible aid in converting firewall rules from Checkpoint to FortiOS. Ede pretty much summons up creating firewall rules on the fgt. About 98% of the time you will be editing Firewall rules on the FortiOS from one interface to another. Regarding your question, I think (at least in our case) you will finds VIP policy rules defined on the outside interface -> inside while server address access rules on the inside interface going out.
    Andre_Backs
    Andre_BacksAuthor
    New Member
    May 10, 2014
    Hi Dave, we used the FortiConverter to make the initial migration from Checkpoint to Fortigate. Unfortunately Fortigate takes a different approach in handling of NAT rules. In Checkpoint I can separate the security policies from the NAT rules, making a NAT rule like below completely OK while limiting access at the security rule level. Fortigate however changes the NAT rule into a security rule, leving the server fully exposed to the internet
    Terms & ConditionsAccessibility statement