The situation
FGT1 runs the policies from earlier labs: 3 (LAN-to-Internet) and 6 (Internet-to-WEB1, through the VIP). Requirements:
- Users: block security-risk, gambling and adult categories; warn on social media; block P2P and proxy apps; scan downloads; block attacks against clients.
- WEB1: block attacks against the web server, including inside HTTPS.
- Deep inspection for users is planned, but for now only after the CA is deployed to a pilot group.
- 1. Outbound: Web filter, DNS filter, app control, AV, IPS protect_client.
- 2. Inbound: IPS protect_http_server with inbound SSL inspection.
Task 1: outbound profiles on policy 3
Show the configuration
Create Staff-WF (categories as in the web filtering lesson) and Staff-AppCtrl (P2P and Proxy blocked), then:
config firewall policy
edit 3
set inspection-mode flow
set ssl-ssh-profile "certificate-inspection"
set webfilter-profile "Staff-WF"
set dnsfilter-profile "default"
set application-list "Staff-AppCtrl"
set av-profile "default"
set ips-sensor "protect_client"
set logtraffic all
next
endTask 2: inbound profiles on policy 6
Show the configuration
config firewall ssl-ssh-profile
edit "WEB1-inbound"
set server-cert-mode replace
set server-cert "WEB1-cert"
next
end
config firewall policy
edit 6
set ssl-ssh-profile "WEB1-inbound"
set ips-sensor "protect_http_server"
set av-profile "default"
next
endWEB1-cert is WEB1's own certificate and key, imported under System › Certificates. With it the FortiGate can decrypt inbound HTTPS to WEB1 without visitors seeing any warning.
Task 3: test and read the logs
- From PC1, open a site in a blocked category: you get the block page.
- Open a social media site: you get the warning page and can proceed.
- Download the EICAR test file over HTTP: the download is replaced by a block page.
- Check Log & Report › Security Events for each test.
Security Events (source 10.0.1.10)
| Time | Type | Detail | Action | Policy |
|---|---|---|---|---|
| 11:02:41 | Web Filter | Gambling | blocked | 3 |
| 11:03:05 | Web Filter | Social Networking | passthrough (warning) | 3 |
| 11:04:12 | AntiVirus | EICAR_TEST_FILE | blocked | 3 |
| 11:05:30 | Application Control | BitTorrent (P2P) | block | 3 |
Find the fault
Fault 1
Gambling sites still open for the finance team (10.0.1.60–10.0.1.69), but are blocked for everyone else.
Show diagnosis
The traffic log shows finance sessions matching policy 9, "Finance-Internet", which sits above policy 3 and has no web filter profile. Profiles apply per policy. Fix: add the same profiles to policy 9 (or merge it into policy 3 if it has no other reason to exist).
Fault 2
EICAR over HTTP is blocked, but the same file from an HTTPS site downloads without any event.
Show diagnosis
Policy 3 uses certificate-inspection, so the file inside HTTPS is never decrypted. This is expected until deep inspection is enabled. Fix: deploy the CA to the pilot group and use a deep-inspection profile on a pilot policy for them.
Fault 3
The pilot group gets certificate warnings on every HTTPS site after deep inspection is turned on.
Show diagnosis
Their PCs don't trust the CA the profile signs with: the GPO installed the CA certificate in the user "Personal" store, not "Trusted Root Certification Authorities". Fix: deploy it to the trusted root store (and to Firefox's own store, if used).
Fault 4
Every attempt to download a security tool vendor's update fails after deep inspection, with the update client reporting a TLS error. Browsing to the vendor's website works.
Show diagnosis
The update client pins its certificate and rejects the FortiGate's replacement. The browser accepts it because it trusts the FortiGate CA. Fix: exempt the update servers (an address or FQDN object, or the vendor's Internet Service entry) in the SSL inspection profile.
Check yourself
Profiles are on policy 3, but some users aren't filtered. What should you check first?
What lets IPS inspect HTTPS requests to WEB1 without visitors seeing certificate warnings?