SSL renegotiation

Are you sure that command is available in V4 firmware? From V4.3.14:

  FORTIGATE $ conf firewall vip    FORTIGATE (vip) $ set  command parse error before ' set'     FORTIGATE (vip) $ edit " VIP_Definition"     FORTIGATE (VIP_Definition) $ set ssl-client-renegotiation    command parse error before ' ssl-client-renegotiation'   Command fail. Return code -61    FORTIGATE (VIP_Definition) $ set ?  id                         custom defined id  comment                    comments  type                       vip type: static NAT, load balance, server load balance  src-filter                 source IP filter (x.x.x.x/x x.x.x.x-y.y.y.y)  *extip                      start-external-IP [-end-external-IP]  *mappedip                   start-mapped-IP [-end mapped-IP]  *extintf                    external interface  arp-reply                  enable ARP reply  nat-source-vip             whether to force NAT as VIP when server goes out  portforward                enable port forward  gratuitous-arp-interval    interval between sending gratuitous arps (seconds)(0 to disable)  color                      Set GUI icon color.    FORTIGATE (VIP_Definition) $ end

Just curious (for both of you); is your Fortinet set up for SSL/TLS offloading? Those commands only become available after the Fortinet has been set up (and rebooted, if I recall correctly, in 4.0, don' t believe so in 5.0). Here is a discussion specific to disabling that due to a vulnerability... http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/ldb.134.29.html

I have over 200 forti-devices that get audited quarterly, so I can assist. 1) Are you sure it was the IP address of the Fortinet itself that failed SSL (and specifically port 443)? 2) If yes, do you have the admin/login page set to allow access from all IPs (unrestricted)? 3) Or have you remapped the login page' s HTTPS to another port, and VIP' d 443 into an internal device? I' d like to start by determining it is actually the Fortinet' s SSL implementation itself that is being flagged.

OK, that sounds like the ISP modem is in route mode, versus PassThrough, or the security group is scanning the wrong IP. 1) go into the firewall, on the left side, click Network, then Interface. Double click the word WAN1. Under addressing mode, is it set to Manual, DHCP, or PPPoE? 2) If it is Manual (or DHCP), is the IP address in there a 192.168.x.x, 10.x.x.x or 172.16.x.x IP address? If yes, the ISP modem is in route mode. You need to ask them to put it into passthrough mode, then either get the static IP address from them for the firewall and plug it into here, or get the PPPoE login info and also plug it into here. If no, is the IP address listed the IP address that got audited? If no, give the auditors the IP address you see in this screen. We have sometimes accidently given the scanners the gateway IP instead of our firewall, which typically fails miserably. Be aware, if you do make a change, you need to then go down to the lower left corner of the webpage, click the word Router, static route, and double click the 0.0.0.0/0.0.0.0 line. Change the gateway in there to whatever your ISP says needs to be your gateway (the exception to this is if they give you PPPoE information. There will be a check box in the WAN1 area to ' Retrieve default gateway from Server' check that. Let' s see what you discover.

Mmm, kk. I did re-read your last note, and saw it was 10443 failing, which is SSL VPN. Is that something you are offering employees? If so; 1) You will have to purchase and install a valid SSL Certificate, to pass all the Self-Signed fails. 2) Turn Strong Crypto on; config system global set strong-crypto enable end 4) What is running on 8080? Did you redirect the web page login for the firewall to 8080? By default, a Fortinet doesn' t have anything listening on 8080. 5) Have you allowed the firewall website to be reached unrestricted? If you go to System -Admin --Administrators Are there any Trusted Hosts listed, or is it just 0.0.0.0/0.0.0.0 If it is 0.0.0.0, you may want to consider locking that down to a very small subset of known IP ranges (e.g. the internal range, and possibly one public, if that public IP is a remote management location).

Hmm, we must be missing something simple. You are not doing Offload/loadbalancing, could you have a VOIP profile enabled for inbound? http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%25205.0%2520Help/Security.008.23.html I don' t recall that CLi (set ssl-client-renegotiation) being used anywhere else.

Unfortunately, this may be something you will need to call Fortinet TAC. Their SSL VPN for 4.0MR3 here http://docs-legacy.fortinet.com/fgt/handbook/40mr3/fortigate-sslvpn-40-mr3.pdf specifically calls this issue out on page 34; SSL offloading Configuring SSL offloading that allows or denies client renegotiation, is configured in the CLI. This feature helps to resolve the issues that affect all SSL and TLS servers that support renegotiation, identified by the Common Vulnerabilities and Exposures system in CVE-2009-3555. The IETF is currently working on a TLS protocol change that will permanently resolve the issue. The SSL offloading renegotiation feature is considered a workaround until the IETF permanently resolves the issue. The CLI command is ssl-client-renegotiation and is found in config firewall vip command. I built up a full SSLVPN on a 60C, 4.0MR3p15, and cannot enable that setting. Technically, they are missing a line between config firewall VIP and set ssl... You need to select an already created VIP profile, but even after I built one and assigned it, I was still not able to turn that feature on.