First, SSL offload mode "client<->FortiGate" means that the client <-> FortiGate path uses TLS, but the FortiGate <-> Server segment is plaintext HTTP. Since you're using port 443 for the real-servers, that suggests a mismatch. FortiGate is sending plaintext to your real-servers, while those servers probably(?) expect encrypted HTTPS.
You should either switch to SSL full-mode, or forward the traffic to plaintext HTTP port of your real-server(s) (if they are ready to process plaintext HTTP traffic).
Second, it is a bit strange that your two real-servers are the same IP and the same port. This feature is typically used to redirect traffic to different real-servers. If everything really goes to a single real-server in your scenario, then you should consider two other options that are even simpler:
1, Just a basic VIP (only if the realserver is supposed to terminate the TLS connection and has its own valid certificate)
2, The same HTTPs-type server-load-balance VIP, but leave the balancing method to "static" and use just a single real-server. (no need to duplicate it)
Since both websites are hosted on the same real server, there is no need for load balancer on your Fortigate. Your web server will serve the right content.
Do you really need to do deep inspection on the Fortigate? If so, don't use the factory certificate. Or at least ensure it is trusted by the clients and that the issuer of your real server certificate is trusted by Fortigate.
And on firewall policy created policy
Destination: Web server IP
Destination should be your "Websites" VIP object.
Still not able to access any of the websites. What have I missed?
You will need to provide a lot more details (specific browser error message, relevant Fortigate config snippets, PCAP, flow debug, WAD debug, etc.) if you seek a more specific answer.
The differentiation is relevant only for deciding to which real-server to send the traffic. In your screenshot the server is the exact same for both (identical IP:port for both), therefore there is no purpose to this differentiation.
If this was just a quickly stitched together example picture and you're actually using two different real-servers, then you can ignore this part of the advice.
Based on the information you provided, there are a few potential issues that could be preventing access to a website like . Here are some steps you can take to troubleshoot the problem:
Verify DNS resolution: Ensure that the DNS records for website1.com like https://sassastatuscheck350.co.za/ and website2.com are correctly configured and pointing to the public IP address of your FortiGate firewall. You can use online tools or command-line utilities like nslookup to check if the DNS resolution is working as expected.
Verify firewall configuration: Double-check the virtual server configuration on your FortiGate firewall. Make sure that the virtual servers are correctly set up to forward incoming HTTPS traffic to the internal IP address (192.168.1.10) of your web server. Ensure that the firewall policy associated with the virtual servers allows traffic from the WAN interface to the LAN interface on the specified destination port (HTTPS).
Check for any NAT-related issues: If you have NAT enabled on your FortiGate firewall, ensure that it is properly configured. If NAT is enabled, the NAT settings should translate the public IP address to the internal IP address of the web server. If NAT is disabled, the public IP address should directly reach the web server without any translation.
Verify IIS configuration: Ensure that the websites are correctly configured on your IIS server. Make sure that the bindings for each website specify the correct IP address (192.168.1.10) and that they are listening on port 443 for HTTPS traffic.
Check for local network connectivity: Ensure that there are no network connectivity issues between the FortiGate firewall (WAN interface) and the web server (LAN interface). You can try pinging the web server from the firewall to verify connectivity.
Verify SSL/TLS certificates: Ensure that the SSL/TLS certificates are correctly installed on the web server and are valid for the domain names (website1.com and website2.com). Invalid or expired certificates can cause connection errors.
Check for any additional security measures: If you have any additional security measures, such as IPS (Intrusion Prevention System) or firewall rules on the web server itself, make sure they are not blocking the incoming HTTPS traffic.
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.