Objective
Create a FortiGate VLAN end to end with an 802.1Q subinterface, IP addressing, optional DHCP, address objects, firewall policies, switch trunking, and validation from a pilot client.
Prerequisites
- Known addressing, VLAN, routing and firewall context for the affected flow.
- A representative test client and the exact protocol or port involved.
- Administrative access appropriate to the system being changed or diagnosed.
- A clearly identified scope: affected users, systems, addresses, services and the time of the observed problem.
- A maintenance or test window when the procedure can affect production traffic or availability.
- A copy of the current configuration or other recovery material before any irreversible action.
Step-by-step procedure
Establish the baseline and scope
Before changing anything, reproduce the issue or document the requested change on a representative system. Record the affected users or services, exact time, current configuration, recent changes and a known-good comparison point. This baseline is the reference used to decide whether each later step improves the situation.
- The scope and current state are documented well enough to reproduce or verify the procedure.
An 802.1Q subinterface
Implement this requirement in a controlled scope: an 802.1Q subinterface. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
IP addressing
Implement this requirement in a controlled scope: IP addressing. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Optional DHCP
Implement this requirement in a controlled scope: optional DHCP. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Address objects
Implement this requirement in a controlled scope: address objects. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Firewall policies
Implement this requirement in a controlled scope: firewall policies. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Switch trunking
Implement this requirement in a controlled scope: switch trunking. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Validation from a pilot client
Implement this requirement in a controlled scope: validation from a pilot client. Capture the previous value or configuration first, make the smallest change that satisfies the design, and validate the effective state rather than assuming that a saved setting is active. If the expected result is not obtained, stop, restore the previous state, and reassess before expanding the change.
- Evidence for this area is explicit, reproducible and consistent with the intended design.
Validate the complete service
Repeat the original user, system or application workflow from the real source and verify the complete result, not only one command or one local check. Confirm that logs and monitoring show the expected behavior and that no temporary debug, bypass, test account, rule or maintenance setting remains enabled.
- The end-to-end service works or the remaining failure is isolated to a clearly identified component.
Technical commands from the original procedure
These technical blocks are preserved byte-for-byte from the historical procedure and kept in their original order. Review names, addresses, paths and parameters before use.
show system interfaceget router info routing-table allconfig system interface
edit "<VLAN-NAME>"
set vdom "root"
set interface "<PARENT-TRUNK>"
set type vlan
set vlanid <VLAN-ID>
set ip <GATEWAY-IP> <NETMASK>
set allowaccess ping
next
endconfig firewall address
edit "<VLAN-NAME>_NET"
set subnet <NETWORK-IP> <NETMASK>
next
endconfig system dhcp server
edit <ID>
set interface "<VLAN-NAME>"
set default-gateway <GATEWAY-IP>
set netmask <NETMASK>
config ip-range
edit 1
set start-ip <START-IP>
set end-ip <END-IP>
next
end
next
endconfig firewall policy
edit 0
set name "<VLAN-NAME>-to-Internet"
set srcintf "<VLAN-NAME>"
set dstintf "<WAN-INTERFACE>"
set srcaddr "<VLAN-NAME>_NET"
set dstaddr "all"
set action accept
set schedule "always"
set service "DNS" "HTTP" "HTTPS"
set nat enable
set logtraffic all
next
endipconfig /allipconfig /releaseipconfig /renewping <GATEWAY-IP>nslookup <INTERNAL-NAME>Test-NetConnection <DESTINATION> -Port <TCP-PORT>diagnose debug resetdiagnose debug flow filter cleardiagnose debug flow filter saddr <CLIENT-IP>diagnose debug flow show function-name enablediagnose debug enablediagnose debug flow trace start 50diagnose debug flow trace stopdiagnose debug disablediagnose debug resetValidation
The procedure is validated when:
- The original symptom or change request has been tested end to end.
- The effective configuration matches the intended design and no unexplained error remains in the relevant logs.
- Temporary troubleshooting controls have been removed and monitoring remains normal.
- The result, evidence and any follow-up action are documented.
Rollback
- Restore the configuration, policy, binding, route, credential assignment or service state recorded in the baseline when the change does not meet its success criteria.
- Remove temporary rules, test objects and diagnostic settings that were introduced only for the procedure.
- After rollback, repeat the minimum health checks to confirm that the previous service level has been restored.
Troubleshooting / common errors
- A successful ping does not prove that the application protocol is allowed or listening.
- When packet and policy evidence disagree, capture the same test flow at more than one point in the path.
- If the result changes between tests, compare source, destination, identity, time and policy context before changing additional settings.
- If a command succeeds but the application still fails, continue at the next protocol or application layer instead of widening access.
- If the expected evidence is missing, verify that logging, auditing and the test path actually cover the failing component.
- If the change does not improve the measured symptom, restore the previous state and reassess the working hypothesis.