Why limit to Authentication-based routing,can' t fortinet have Address-based and Device Identity routing on the policy tab itself rahter than putting it on the policy route tab would be very nice to have when your using/have multiple gateways
That we can define, from which network a admin interface will respond in general, independ if the admin account is allowed to access the admin interface form this network. this could be improved within the Local In Policy.
I would love so see hardware modules to add directly a VDSL2 modem for example to the box so I do not need a DSL router in front anymore. That' s one of they main reasons why enterprise customers buy the Juniper SRX instead of a Fortigate.
That would be awesome.
If we think on the NSA - it would be great if Fortinet would support some less widespread encryption protocols for VPN. Between Fortigate units and FortiClient it would work fine and that' s okay. I believe, the NSA is trained to crack AES, DES, SSL and other common cryptographic protocols day by day. But if we could use something different - maybe developed in-house by fortinet for example - thy would have a lot more trouble to decrypt that, because it' s not that common.
THAT would be outstanding in the market. For interoperation with other vendors, fortunate customers could use AES as well of course but within the Fortinet eco system it would be great to have alternatives. Maybe with an open API so that it is easy so implement new cryptographic protocols if necessary of when the customer has the necessary manpower and knowledge.
I' d like to see the ability to specificy Subnets or incoming interfaces that alwasy represent " On Net" for FCT registration. Right now if there is another L3 device between the FGT and the client they show up as " off net"