├── README.md └── FOS-Naming-Conventions.md /README.md: -------------------------------------------------------------------------------- 1 | # naming-conventions 2 | Naming convention guideline documents 3 | -------------------------------------------------------------------------------- /FOS-Naming-Conventions.md: -------------------------------------------------------------------------------- 1 | # Purpose 2 | ## Preamble 3 | Firewalls, by their nature, are very complex devices. FortiGates are arguably the most complex firewalls of all, because they can perform so many functions beyond just the traditional NGFW capabilities, including SD-WAN, dynamic routing, traffic shaping, server load-balancing, Wireless LAN Controller, Switch Controller, DNS server, etc., all with multi-tenant capabilities for MSSPs. Given all of these capabiltiies, FortiGates are used in MANY different use-cases beyond just an NGFW, including ISFW, cloud firewall, air-gapped firewall for OT networks, edge router, CGNAT gateway, VPN concentrator, CPE device for ISPs, etc. Sometimes these use-cases are lumped together into the same FortiGate, and sometimes they're split into multiple FortiGates. 4 | 5 | This complexity posses major challenges for firewall administrators, because mistakes in configuration can introduce serious security risks. The more complex the firewall configuration becomes, the greater the risk of mistakes becomes. An essential strategy to help mitigate the complexity of the firewall configuration is to use consistent, semantically-meaningful naming conventions, that can apply universally to all use cases. Such naming conventions will greatly improve readability, thus reducing the chances for human-error, especially when multiple administrators work on the same firewall configurations. Even when a single administrator manages a firewall, someday that administrator will move on and administration duties will pass on to a new administrator. RTNG (Remember the Next-Guy/Gal) is an important motto to live by. 6 | 7 | What follows is a naming convention guide for FortiOS that has evolved out of many years of practice in MSP/CSP/ISP engagements, across many verticals and involving complex governence relationships, often including multi-tenancy, as well as integrations with many 3rd-party systems, including automation systems like Ansible. Use whatever parts of it you find useful, and adapt to your situation as necessary. Your mileage may vary. N.B. That I have not updated this guide since FOS 7.0. I plan to make updates in the future to include new object types. Feedback is always appreciated. 8 | 9 | ## Semantic Meaningfulness and Object-Oriented Design 10 | FortiOS is object-oriented, by design. Whereas some other firewall systems allow the administrator to choose between literals or objects, FortiOS requires the use of objects in almost all cases. This design choice by Fortinet forces FortiGate administrators to use objects for almost all of the configuration, which is a good thing. Objects are much more semantically meaningful than literalls, as objects can be named according to their use-case, which enhances human readability. There is a reason the world adopted the use of DNS. We humans communicate much more effectively using names rather than numbers. Named objects serve a similar purpose. 11 | 12 | When an administrator is used to working in literals, they will sometimes try to circumvent the object-oriented nature of FortiOS by naming their objects by their literal value. Imagine an IP address object whose value is 192.168.1.0/24. If you name this object `192.168.1.0_24`, then you've added no semantic value to the object, which does nothing to aid in human-readability. Instead, if you name that object `users_subnet`, now administrators know that this subnet is where users reside. Some administrators will claim that they want to "see" the actual IP address value of their objects, but every object in the FortiOS GUI can be hovered over to display its content, which will show the IP address. Furthermore, the various search functions within the FortiOS GUI allow you to search by both object names and object values, so it is easy to find objects when you know their values rather than their names. 13 | 14 | Objects are also much more flexible and dynamic. For example: If an administrator could choose to use literal values for an IP address that is used in a static route, a firewall policy, and an IPsec Security Association (aka "Phase-2 Selector"), any changes to that IP address would have to be done in three places. But if an object is used instead of literals, the administrator would only need to change the IP address value of that object, and the change will be reflected everywhere else that object is used in the configuration. 15 | 16 | There are a few places where FortiOS allows administrators to choose between literals vs objects. These include static routes and IPsec Security Association (aka "Phase-2 Selector"). Use of literals here should be avoided, for the above stated reasons. 17 | 18 | # Guiding Principles 19 | -------------------- 20 | 21 | ## String Length Limitations 22 | FortiOS has some limitations regarding string lengths of object names, so try to use shorter names or abbreviations, where possible, with the comment fields being used for additional elaborations where needed. This could pose challanges in some scenarios. For example, in many of the conventions in this document, I recommend to use the FQDN in the object name, but some FQDNs might be too long. In these cases, you should use the just the hostname in the object name, and then the FQDN can be moved to the comment field. 23 | 24 | ## Case Sensitivity 25 | ForitOS runs on Linux, and Linux is case sensitive, so do not mix upper and lower case. The preference should be for all object names to be lower case, except for objects that are by default all upper case, such as service objects, so new/custom service objects should also be all upper case. Having consistent case sensitivty will save you headaches, especially when working at the CLI. 26 | 27 | ## Avoiding White Space 28 | White space can create difficulties for parsers for many automation, documentation, and logging systems, so spaces should never be used in object names, and instead dashes should be used to separate words. This way, you'll never have to bother with the various complexities around escaping white spaces. 29 | 30 | ## Avoiding Special Character 31 | Special characters can also create difficulties for parsers for many systems so the only special characters that should be used in object names are dashes and underscores, and never characters like ``! @ # $ % ^ & * ( ) ~ + =`` etc., even when FortiOS itself allows it. 32 | 33 | ## Mutability 34 | FortiOS uses UUIDs for most object types, which allows their object names to easily be changed. A few object types, however, cannot be changed once they are created. These can create challanges in scenarios where semantic naming changes. Imagine a scenario where a company called ACME gets aquired by another company, WidgCo, and the WidgCo CEO wants all ACME assets to be renamed WidgCo. For most object types in FortiOS, this will be easy to accomplish. But for a few object types that can't be renamed, they would have to be deleted and re-created, which would cause downtime. 35 | 36 | Therefore, unchangable names (e.g. interfaces) should be named in such a way that they never need to be changed, so they should be named according to their objective essence (which cannot change) rather than their use case (which can change), and the alias field (which is changeable) can then be used to describe its current use case. For names which can easily be changed (e.g. address objects) they should be named according to their use case or their FQDN. 37 | 38 | ## Object Type Distinctions 39 | There can be many different types of objects that share the same use-case or same FQDN, and so would share the same name, based on the above principles, but sharing the same name may be impossible in FortiOS in some cases, and even when possible, will still be confusing for humans. Therefore, each name should be suffixed by its object type, separated by an underscore. 40 | 41 | > E.g. 42 | - Imagine a webserver whose FQDN is `web01.example.local`, and who has a private IP address of `192.168.1.11`, and a public IP address of `4.4.4.4`, with a 1-to-1 VIP object performing NAT. 43 | - In this case, the private IP address object would be named `web01.example.local_priv` (for "private IP"), whereas the VIP object would be named `web01.example.local_vip`. 44 | - Additionally, you might need a MAC address object for the same server, which would be named `web01.example.local_mac`. 45 | - If you are doing Deep SSL Inspection to proect this web server, its SSL Inspection Profile would be named `web01.example.local_ssl` 46 | - If you need a custome WAF Profile to further proect this web server, its WAF Inspection Profile would be named `web01.example.local_waf` 47 | 48 | - Numbering: Multiple instances of the same object type for the same use case should be suffixed with a number that increments from 1. If you expect to never need more than 9 of an object, this can be a 1-digit number, but if you may need up to 99 of an object, it should be a 2-digit number, etc. 49 | > E.g. If `web01.example.local` needed two different private IP addresses objects (such as if it were dual-homed), these would be named `web01.example.local_priv01` and `web01.example.local_priv02` 50 | 51 | - Object type groups: Group names should also be suffixed with their type, but will be of the plural form, indicating a collection of more than one of that object. 52 | > E.g. A group of `_priv` objects would be named `_privs`. A group of `_vip` objects would be named `_vips`. A group of `_mac` objects would be named `_macs`. Etc. 53 | 54 | In the below specifications, I've tried to stick to the above principles as much as possible, and everything else is just arbitrary conventions that have served me well in a wide range of scenarios. Your mileage may vary. 55 | 56 | ------------------------- 57 | 58 | # Conventions 59 | ---------------------------- 60 | 61 | ## Interfaces 62 | ------------------- 63 | 64 | ### Loopback Interface: 65 | - Name: loN, where "lo" means "loopback" (like in Cisco terminology) and N is the number of the loopback interface, which increments from 1 66 | - Alias: _loopback, where use case is what this loopback will be used for. 67 | > E.g. if you just had a single loop back for all management function, then the alias for `lo1` would be `mgmt_loopback`, but if you were going to have different loopbacks for different management functions, you might have something like `lo1:ntp_loopback`, `lo2:dns_loopback`, `lo3:bgp_loopback`, etc. 68 | 69 | ### LACP 802.3ad Aggregate Interface 70 | - Name: poN, where "po" means "port channel" (like in Cisco terminology) and N is the number of the port channel, which increments from 1 71 | - Alias: _trunk, where use case is what this trunk will be used for, and `_trunk` is Fortinet's teminology for a LACP Aggregate 72 | > E.g. `po1` might have an alias of `core_trunk` 73 | 74 | ### Hardware Switch Interface: 75 | - Name: swN, where "sw" means "switch" and N is the number of the port channel, which increments from 1 76 | - Alias: `_switch`, where use case is what this switch will be used for 77 | > E.g. `sw1` might have an alias of `lan_switch` 78 | 79 | > Tip: Consider disabling all unused physical ports on the FortiGate (for both security and stability reasons). Put all of them into a special switch object named sw0 with alias `disabled_switch`, and then just disable that whole switch object. This also visually cleans up the interface table in the GUI, especially for FortiGate models with lots of physical interfaces. 80 | 81 | ### Software switch: 82 | - Never use these, because they can't do hardware acceleration. 83 | - The only time to use a software switch is if you have a FortiGate that can't support hardware switches, in which case, you should try to just use a LACP Aggregate to a physical switch to do your switching. If you must use a software switch, just follow the same naming convention for a hardware switch. 84 | 85 | ### Physical interface: 86 | - Physical interfaces cannot be renamed, but also they should never be used in your configuration, because they are completely inflexible and will create reference hell for you if you ever need to add/change the underlying physical interfaces. 87 | - Instead, always create either a LACP Aggregate or a Hardware Switch Interface to add your physical interfaces to, even if you only need a single interface today. 88 | 89 | ### NPU VDOM Link: 90 | - Name: these are hard-coded as npuN-vlinkM, where N is the number of NPUs, incrementing from 0, and M is the vlink number (either 0 or 1). 91 | - Alias: These cannot have aliases 92 | > N.B. we will not be using the NPU VDOM Links themselves, but instead will be using 802.1q VLAN sub-interfaces on the VDOM links, so that we can have up to 4096 hardware-accelerated VDOM links per NPUs 93 | 94 | ### Software VDOM Links: 95 | - Do not use these, because they cannot be hardware accelerated 96 | 97 | ### VLAN Interfaces: 98 | - Name: ````.VVVV, where ```` is the base interface of which this VLAN interface is sub-interface, and VVVV is the 4-digit VLAN ID according to 802.1q 99 | - Alias: ``_vlan`` 100 | > E.g. 101 | > - `po1.0002` might have an alias for `inf_vlan` (where inf means infrastructure, such as servers and management IPs of network infrastructure) 102 | > - `po1.0003` might have an alias of `user_vlan` (where corporate users will reside) 103 | > - `po1.0004` might have an alias for `voip_vlan` (where Voice-over-IP handset will reside) 104 | > - `po1.0005` might have an alias of `guest_vlan` (where guest Wi-Fi users will reside) 105 | > - `po1.0006` might have an alias of `iot_vlan` (where Internet of Things devices will reside, such as printers, cameras, building automation sensors, and other low-security headless devices) 106 | > - `po1.0007` might have an alias of `dmz_vlan` (where internet-accessible servers will be isolated from non-internet accessible servers) 107 | > - Alternatively, if you're using a hardware switch instead of LACP Aggregate, `sw1.0002` might have an alias for `inf_vlan`, etc, as above 108 | > - `npu0-vlink0.0002` might have an alias of `_vlink` while `npu0-vlink1.0002` might have an alias of `_vlink` (thus linking vdom01 with vdom02) 109 | 110 | ### SSID Interfaces: 111 | - Name: `ssidN`, where `N` is the number of SSID interface, which increments from 1 112 | - Alias: ``_ssid``, where use case is what this SSID will be used for 113 | > E.g. `ssid1` might have an alias of `corp_ssid`, and `ssid2` might have an alias of `guest_ssid` 114 | 115 | ### IPsec VPN Phase-1 Interfaces 116 | - Name: ``_tun1``, where "tun" means "tunnel" and number is the number of the tunnel that increments from 1 117 | - Alias: As of FortiOS 6.4, IPsec VPN Phase-1 Interfaces cannot have aliases, which is why the use-case is in the name instead, so the use-case name must be relatively short/abbreviated 118 | 119 | ### Zones: 120 | - Name: `_zone` 121 | - Alias: Zones cannot have aliases as of FortiOS 6.4, but you can use the comments field for additional elaboration if needed 122 | > E.g. 123 | > - `inside_zone` might be the name of for the zone that will collect all of the "inside" interfaces protected behind this FortiGate 124 | > - `wan_zone` might be the name for the (SD-WAN) zone that will collect all of the "wan" interfaces connected to this FortiGate 125 | > - `tun_zone` might be the name for the (SD-WAN) zone that will collect all of the "tunnel" IPsec interfaces connected to this FortiGate 126 | - N.B. All interfaces that will have IPv4/6 firewall policies applied must be added to a zone, such that all policies will be zone-based and not interface-based, which will greatly enhance policy consolidation, and make future interface changes/additions much easier and quicker 127 | 128 | ---------------------------- 129 | 130 | ## Address Objects 131 | 132 | ### Device/MAC Objects: 133 | - Name: `_mac` 134 | - Comments can be used for additional elaboration 135 | 136 | ### Subnet Objects: 137 | - For a /32 in the RFC 1918 space 138 | - Name: `_priv`, or `_privNN` if more than one `_priv` will be needed for that same FQDN 139 | - For a /32 outside of the RFC 1918 space 140 | - Name: `_pub` or `_pubNN` if more than one `_pub` will be needed for that same FQDN 141 | - For prefix shorter than /32 142 | - Name: `_subnet`, or `_subnetNN` if more than one `_subnet` will be needed for that same use-case 143 | - Comments can be used for additional elaboration 144 | 145 | ### FQDN Objects: 146 | - Name: `_fqdn` 147 | - Comments can be used for additional elaboration 148 | 149 | ### GeoIP Objects: 150 | - Name: `_geo` 151 | 152 | ### IP Range Objects: 153 | - Name: `_range` 154 | - Comments can be used for additional elaboration 155 | - N.B. Do not use a `_range` object when a `_subnet` object could be used instead 156 | 157 | ### Custom ISDB Objects: 158 | - Name: `_isdb` 159 | 160 | ### VIP Objects of type static-nat: 161 | - For a 1-to-1 Destination NAT: 162 | - Name: `_vip` 163 | > E.g. `web01.example.com_vip` would forward all ports to the server whose FQDN is `web01.example.com` 164 | - For a N-to-N Destination NAT range: 165 | - Name: `_vip` 166 | - For a 1-to-M Destination PAT: 167 | - Name: `-_vip` 168 | > E.g. `web01.example.com-ssh_vip` for port 22 and `web01.example.com-http_vip` for port 80 169 | 170 | ### Address Group Objects 171 | - Name: `_s`, where the "s" indicates plurality, hence a group of multiple objects 172 | > E.g. 173 | > - `company-asn_subnets` might contain all of the subnets for the company's ASN such as company-asn_subnet01 and company-asn_subnet02 174 | > - `ban_geos` might include all of the Geo IP objects that you want to block, such china_geo and iran_geo 175 | > - `sslvpn_geos` might include all of the Geo IP object for which you want to allow SSL VPN connections 176 | > - `web01.example.com_vips` might contain both web01.example.com-ssh_vip and web01.example.com-http_vip 177 | > - `hairpin_vips` might contain all of the VIP objects for which you want to allow hairpin NAT 178 | > - `collab_isdbs` might contain the ISDB objects for Zoom, Teams, WebEx, Slack, etc 179 | - N.B. Groups should always be preferred over individual objects for creating policies and routes, (even if a group only contains one object member initially) as this makes it easier to facilitate changes/additions in the future 180 | 181 | -------------------- 182 | 183 | ## Special Address Objects 184 | 185 | ### VIP Objects of type server-load-balance (aka Virtual Servers in the GUI): 186 | - Name: `:_vlb`, where "vlb" means virtual load balancer 187 | > E.g. 188 | > - You might have `web-clus01:80_vlb` to load-balance HTTP traffic to `web01.example.com` and `web02.example.com` 189 | > - You might have `web-clus01:443_vlb` to load-balance HTTPS traffic to `web01.example.com` and `web02.example.com` 190 | 191 | ### IP Pools (aka Source NAT objects) 192 | - For an overload pool: 193 | - Name: `_overload` 194 | > E.g. 195 | > - `user_overload` might be the overload pool for the corporate users 196 | > - `guest_overload` might be the overload pool for guest Wi-Fi users 197 | - For a 1-to-1 pool: 198 | - Name: `_1-to-1` 199 | > E.g. 200 | > - If you had two web servers that you wanted to assign two particular public IP addresses, you might have `web01.example.com_1-to-1` and `web02.example.com_1-to-1` 201 | > - If you were assigning a contiguous range of public IP addresses to all your servers, you might have `servers_1-to-1` 202 | 203 | - As of FortiOS 6.4, neither VIP Objects nor IP Pools can be added to groups 204 | 205 | --------------------------------- 206 | 207 | ## Service Objects 208 | 209 | ### Single Service Object 210 | - Name: `` in all caps, because all of the default service objects are in all caps 211 | - Special case: alternate ports for defauly service should be prefixed with `-ALTNN`, where `NN` is a two-digit number incrementing from 01 212 | > E.g. `HTTPS_ALT01` could be TCP/8443, and `HTTPS-ALT02` could be TCP 9443, etc 213 | 214 | ### Service Group Objects: 215 | - Name: `_services`, lower case 216 | > E.g. 217 | > - `web_services` might contain HTTP, HTTPS, and ALL_ICMP 218 | > - `webmin_services` might contain SSH, HTTP, HTTPS, and ALL_ICMP (where "webmin" is short for web administration) 219 | - N.B. Service groups should be preferred in policies to facilitate easier changes/additions 220 | - N.B. `ALL_ICMP` should generally be added to most service groups to allow for easier troubleshooting and better functionality of services like PMTUD, although security considerations in some cases might warrant restrictions on some ICMP types and codes 221 | 222 | ------------------------------ 223 | 224 | ## Security Profiles 225 | 226 | ### Antivirus: 227 | - Name: `_av` 228 | > E.g. You might have both `flow_av` and `proxy_av` 229 | 230 | ### Web Filter: 231 | - Name: `_wf` 232 | > E.g. You might have both `corp_wf` and `guest_wf` 233 | 234 | ### DNS Filter: 235 | - Name: `_df` 236 | > E.g. You might have both `corp_df` and `guest_df` 237 | 238 | ### Data Leak Prevention (DLP) 239 | - Name: `_dlp` 240 | > E.g. You might have both `pci_dlp` and `pii_dlp` 241 | 242 | ### Application Control: 243 | - Name: `_ac` 244 | > E.g. You might have both `corp_ac` and `guest_ac` 245 | 246 | ### Intrusion Prevention System (IPS): 247 | - Name: `_ips` 248 | > E.g. You might have both `client_ips` (to protect clients that connect outbound to internet) and `win-server-iis_ips` (to protect a Windows IIS server) as well as `lin-server-appache_ips` (to protect a Linux Apache server), etc. 249 | - N.B. Using as specific of an IPS filter as possible for a given traffic flow will greatly improve the efficiency of the IPS Engine's processing 250 | 251 | ### WAF: 252 | - Name: `_waf` 253 | > E.g. 254 | > - You might have `iis_waf` and `apache_waf,` with different configurations for general protection of IIS and Apache, respectively 255 | > - You might have `web01.example.com_waf` and `web02.example.com_waf,` with different configurations specific to the two different web servers that you need to protect 256 | 257 | ### SSL Inspection: 258 | - Name: `_ssl` 259 | > E.g. 260 | > - For basic outbound certificate inspection, you might have `client-cert_ssl` 261 | > - For deep SSL inspection outbound, you might have `client-deep_ssl` 262 | > - For deep SSL inspection inbound protecting a single server (or multiple servers with SNI in FortiOS 7.0 or higher), you might have `web01.example.com_ssl` 263 | 264 | ### Protocol Options: 265 | - Name: `_prot` 266 | > E.g. you might have both `default_prot` and `comfort-clients_prot` 267 | 268 | ------------------------------- 269 | 270 | ## Firewall Policies 271 | 272 | ### For an allow policy: 273 | - Name: `[this]>[that]`, where `[this]` is the name of the source object and `[that]` is the name of the destination object. 274 | - If you have multiple policies with the same or similar destinations, but different services, suffix them with `_[service-group]` 275 | > E.g. 276 | > - `lan_subnets>wan` would allow all subnets on the LAN to get out to the internet 277 | > - `corp_subnets>dc01.example.com_adds` would allow the corporate subnets access Domain Controller on Active Directory Directory Services ports 278 | > - `guest_subnets>dc01.example.com_dns` would allow guest subnets access Domain Controller only for DNS 279 | ### For a deny policy: 280 | - Name: `[this]>[that]_deny`, where `[this]` is the name of the source and `[that]` is the name of the destination 281 | > E.g. `lan_subnets>ban-geos_deny` 282 | 283 | ------------------------------- 284 | 285 | ## DDoS Policies 286 | 287 | ### For an monitor-only DDoS policy: 288 | - Name: `[this]>[that]_monitor`, where `[this]` is the name of the source object and `[that]` is the name of the destination object. 289 | > E.g. `lan_subnets>wan_monitor` would monitor for any DDoS attacks originating from your LAN subnets out to the internet 290 | 291 | ### For a block DDoS policy: 292 | - Name: `[this]>[that]_block`, where `[this]` is the name of the source object and `[that]` is the name of the destination object. 293 | > E.g. `wan>pub-subnets_block` would block any DDoS attacks originating from the internet targeting your public subnets 294 | N.B. Because DDoS policies cannot be applied to SD-WAN zones, if you have multiple WAN interfaces that need DDoS protections, you'll need multiple DDoS policies. 295 | > E.g. `wan1>pub-subnets_block` and `wan2>pub-subnets_block` 296 | 297 | ------------------------------- 298 | 299 | ## Traffic Shaping 300 | 301 | ### Traffic Shaping Profiles 302 | - Name: `_shaping-prof` 303 | - N.B. Class ID names should be equal to the FortiGuard Application Categories, one Class ID per Category 304 | 305 | ### Traffic Shaping Policies 306 | - Name: `` (which should be the same as ``) for application category Traffic Shaping Policies 307 | - Name: `` for special use-case Traffic Shaping Policies 308 | 309 | ### Traffic Shapers 310 | - N.B. I almost never use Traffic Shapers anymore after Traffic Shaping Profiles were introduced in FOS 6.4. 311 | - This is because Traffic Shaping Profiles are much more dynamic, since they can use bandwidth percentages, which are crucial in SD-WAN configurations, where wan1 and wan2 often have different upload/download bandwidth values. Using static Traffic Shapers, you would need different Shapers for wan1 and wan2, and maybe even for wan1-upload, wan1-download, wan2-upload, wan2-download if they have asymetric bandwidth. Using static Traffic Shapers in a such a scenario could exponentially increase the number of objects you have to create and manage, whereas a Traffic Shaping Profiles can handle all of that complexity in a single object. 312 | - Furthermore, imagine a scenario where wan1 initially has a subscribbed bandwidth of 100x10, but then you have your ISP upgrade your subscribbed bandwindth to 200x20. If you used static Traffic Shapers, you would have to go through and edit all of your Traffic Shaper objects relevant to wan1 and double their max/guarntee values in order to actually realize your bandwidth upgrade. But if you used a Traffic Shaping Profile instead, the only change you would have to make would be to edit the Estimated Bandwidth values on the `wan1` interface object, which will allow the Traffic Shaping Profile to re-calculate the appropriate percentages. 313 | - The only exception to this rule would be if you need to enforce a specific static bandwidth max/guarantee for a certain traffic flow. An example use-case for such a need would be an ISP who is using FortiGates as their CPE. Such an ISP might have a contract to deliver exactly 100 Mbps x 100 Mbps to their customer. In this case, a static Traffic Shaper is required. 314 | - Name: `_shaper` 315 | > E.g. `acme-subscribbed_shaper` would enforce the subscribbed bandwidth for ACME Corp, who is an ISP customer 316 | 317 | ------------------------------- 318 | 319 | ## SD-WAN 320 | 321 | ### Performance SLAs 322 | - As of FortiOS 7.0, dashes are not allowed in the name of SD-WAN Performance SLA objects, so if an FQDN contains dashes, you will have to use an underscore. 323 | - Name: `` 324 | > E.g. 325 | > - `update.fortiguard.net_ping_sla` would check ICMP peformance to update.fortiguard.net using Ping 326 | > - `google.com_http_sla` would check web performance to google.com using HTTP 327 | > - `cloudflare_dns` would check DNS performance to Cloudflare's DNS servers at 1.1.1.1 and 1.0.0.1 328 | 329 | ### SD-WAN Rules 330 | - As of FortiOS 7.0, the `>` symbol is not allowed in the name of SD-WAN Rules, so we wont be able to follow exactly the same convention we used for Firewall Policies 331 | - Name: `[this]_to_[that]`, where `[this]` is the name of the source and `[that]` is the name of the destination. 332 | - E.g. `lan_to_google` might route all traffic from LAN to Google's cloud services 333 | 334 | ### SD-WAN Zones 335 | - The default SD-WAN zone object is named "virtual-wan-link". That doesn't follow any of our conventions. 336 | - Name: `_sdwz` (where "sdwz" is an abbreviation for "SD-WAN Zone") 337 | > E.g. 338 | > - For your underlay WAN links, you might have `underlay_sdwz`, where "underlay" is the MEF terminology for the physical WAN link you get from your ISP) 339 | > - For your overlay WAN links, you might have `overlay_sdwz`, where "overlay" is the MEF terminology for the IPsec tunnels you build on top of your underlays 340 | 341 | ------------------------------- 342 | 343 | ## User and Authentication Objects 344 | 345 | ### User Group: 346 | - Name: `_users` 347 | ### LDAP Server: 348 | - Name: `_ldap` 349 | ### RADIUS Server: 350 | - Name: `_radius` 351 | 352 | ------------------------------- 353 | 354 | ## WiFi Controller 355 | 356 | ### FortiAP Name 357 | - Name: `hostname` 358 | > E.g. You might have `ap01`, `ap02`, etc 359 | - N.B. You can use the Description field to provide more description, like the physical location of the switch, such as "Building 2, Room 307, Rack 4, U27" 360 | 361 | ### FortiAP Group 362 | - Name: `_ap-grp` 363 | 364 | FortiAP Profiles 365 | - Name: `_ap-prof` 366 | - If you need more than one AP profile for the same FortiAP models to support different use-cases (such as dual-band vs single-band operation), try `` 367 | 368 | ### SSIDs 369 | - See entry for SSIDs under the Interfaces section of this document 370 | 371 | ### MPSK Group 372 | - Name: `_mpsk-grp` 373 | 374 | ### WiFi Maps 375 | - Name: 376 | > E.g. `123main-f0_wifi-map` would be the basement of the building at 123 Main, `123main-f1_wifi-map` would be the ground floor of the same building 377 | 378 | ### WIDS 379 | - Name: `_wids` 380 | 381 | ------------------------------- 382 | 383 | ## Switch Controller 384 | 385 | ### FortiSwitch Name 386 | - Name: `hostname` 387 | > E.g. You might have `core-sw01`, `core-sw02`, `dis-sw01`, `dis-sw02`, `acc-sw01`, `acc-sw02`, etc 388 | - N.B. You can use the Description field to provide more description, like the physical location of the switch, such as "Building 2, Room 307, Rack 4, U27" 389 | 390 | ### FortiSwitch Profile 391 | - Name: `use-case_switch-prof` 392 | 393 | ### FortiSwitch Trunks 394 | - Name: `trNN`, where NN is a two-digit number that increments from 01 395 | - N.B. You can use the Description field to provide addition details, such as the use-case 396 | 397 | ### LLDP Profiles 398 | - Name: `_lldp` 399 | > E.g. You might have `voip_lldp` and `cam_lldp` 400 | 401 | ### QoS Policies 402 | - Name: `_qos` 403 | > E.g. You might have `voip_qos` and `cam_qos` 404 | 405 | ### Security Policies (802.1X) 406 | - Name: `_d1x` 407 | 408 | ### Dynamic Port Policies (802.1X) 409 | - Name: `_dpp` 410 | 411 | ### NAC Policies 412 | - Name: `_nac` 413 | 414 | ------------------------------- 415 | 416 | ## DNS Database 417 | - Name: `zone-fqdn_dns-database` 418 | > E.g. You might have `ad.acme.com_dns-database`, which a shadow secondary DNS server getting zone transfers for the ad.acme.com zone from dc01.ad.acme.com, for DNS resiliency 419 | 420 | ------------------------------- 421 | 422 | ## Automation Stitches 423 | 424 | ### Trigger 425 | - Name: `_trigger` 426 | 427 | ### Action 428 | - Name: `_` 429 | > E.g. 430 | > - For a script that cycles POE to revive a down AP, you might have `poe-cycle-ap01_script` 431 | > - For an email that alerts on loss of FortiAnalyzer connectivity, you might have `fgt-faz-conncection-lost_email` 432 | 433 | ### Stitch 434 | - Name: `_stitch` 435 | 436 | ### Link-Monitor 437 | - Name: `_link-mon` 438 | 439 | ------------------------------- 440 | 441 | ## External Connectors 442 | 443 | ### IP Address Threat Feed 444 | - Name: `_ip-list` 445 | 446 | ### Domain Name Threat Feed 447 | - Name: `_url-list` 448 | 449 | ### Malware Hash Threat Feed 450 | - Name: `_hash-list` 451 | 452 | ------------------------------- 453 | 454 | --------------------------------------------------------------------------------