I have read every article on the internet on this topic and worked with Fortinet TAC for 2 days. All of the articles say you can secure the public IP of the Fortigate by putting the public IP in the Host IP section for the common name in the CSR. Done this, does not work. Once the wildcard is rekeyed for the subdomain it shows the top level domain in the cert and that it is applied on the IP login but the browser still says not secure. I have tried this with the SAN as the DNS name for the site, and it secures the DNS name for the site but not the IP. Has anyone successfully done this and how, and why would Fortinet documentation say this can be done if it can't (this is what TAC says and would not escalate)?
Ok if my customer is good with just securing the DNS name is there a way to block 443 access then to firewall on the WAN interface? Today they use 10443 for admin access on the WAN interface. I have put in local in policy to block 443 on the WAN interface but telnet test to 443 still works. Am I missing something?
Local in policy if it is well configured should block the access as expected.
Should be like that.
config firewall local-in-policy
edit 1
set intf "wan1"
set srcaddr "all"
set dstaddr "1.2.3.4"
set service "HTTPS"
set schedule "always"
set action deny
next
end
Ok here is the weirdest thing. I have applied that exact Local In you showed on both firewalls and only 1 is blocking the connection to 443.
This one works
config firewall local-in-policy
edit 2
set uuid 2c381c5e-e4cd-51ef-fc7a-6cfcc55b8019
set intf "wan1"
set srcaddr "all"
set srcaddr-negate disable
set dstaddr "wan1-IP"
set internet-service-src disable
set dstaddr-negate disable
set action deny
set service "HTTPS"
set service-negate disable
set schedule "always"
set status enable
set comments ''
This one does not
config firewall local-in-policy
edit 2
set uuid 78d309cc-e4c6-51ef-d267-3c77db370faf
set intf "wan1"
set srcaddr "all"
set srcaddr-negate disable
set dstaddr "wan1-IP"
set internet-service-src disable
set dstaddr-negate disable
set action deny
set service "HTTPS"
set service-negate disable
set schedule "always"
set status enable
set comments ''
Am I missing something
Created on 02-07-2025 11:58 AM Edited on 02-07-2025 11:58 AM
And what the first rule (edit 1) looks like?
This is the two rules for each firewall
config firewall local-in-policy
edit 1
set uuid ae9f5406-9bbb-51ef-f6dd-2a8d82bb10ee
set intf "wan1"
set srcaddr "all"
set srcaddr-negate disable
set dstaddr "wan1-IP"
set internet-service-src disable
set dstaddr-negate disable
set action deny
set service "TIMESTAMP"
set service-negate disable
set schedule "always"
set status enable
set comments ''
next
edit 2
set uuid 78d309cc-e4c6-51ef-d267-3c77db370faf
set intf "wan1"
set srcaddr "all"
set srcaddr-negate disable
set dstaddr "wan1-IP"
set internet-service-src disable
set dstaddr-negate disable
set action deny
set service "HTTPS"
set service-negate disable
set schedule "always"
set status enable
set comments ''
next
end
It looks fine. So probably a bug. Which FortiOS version?
7.6.2 on both boxes
There is a bug in 7.6.2 that "may" have relationship with your issue.
1104649 | If a local-in policy, DoS policy, interface policy, multicast policy, TTL policy, or central SNAT map used an interface in version 7.4.5, 7.6.0 or any previous GA version that was part of the SD-WAN zone, these policies will be deleted or show empty values after upgrading to version 7.4.6 or 7.6.1. Workaround: After upgrading to 7.4.6 or 7.6.1 GA, users must manually recreate these policies and assign them to the appropriate SD-WAN zone. |
Try purge your local-in policies and recreate them again.
Hope it helps.
User | Count |
---|---|
2570 | |
1362 | |
796 | |
651 | |
455 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.