sslvpn ssl.root management access

A client of mine,  had a specific security requirement for allowing remote management of a fortigate via SSLvpn remote access.


E.g of the network topology top view. Each remote nets are objects in the untrusted cloud space

Now the government agency they are working with wanted the following;

1: no direct ssh access
2: no direct telnet access ( that should be obvious but .....just in case )
3: no direct HTTP or HTTPs access ( the former protocol should be obvious to a security engineer as weak )
4: no ipsec vpn
5: A person must go thru a vpn to access the fortigate & by using ssl encryption


Now items #1,2,3 was simple we did not allowaccess ssh http https or telnet on our outside untrusted interface,  but item #5 caused a wake of numerous  round table discussions.

And knowing the gov, they wanted to install  a 30K solution with yet another appliance for vpn access & controls just for gaining access to a dozen or so fortigate appliances.

BTW, they needed  SSL access vrs IPSEC, due to a lot of foreign networks have a high degree of not allowing ipsec traffic to flow.


So I crafted a POC  & that I'm proud to say they bought after  careful  review.

Here's what I did;

1: I built a vpn group and assigned it a unique ipv4 pool that we also set into our trusthost

2: we assigned a ipv4 address to the ssl.root interface ( yeap it's a interface like any other interface , in fact it's a tunnel interface hence the /32 mask )

3: Next we allowed the approved access management ( ssh ) over this sslvpn

Now I want to point out the following;

>  This method is a little overkill for security , since we have ssh encryption encrypted into another encryption type ( SSL )

>  Also if any  sec-engineer screws up any sslvpn settings, they could disable the access

>   Also in our case the remote vpn was authenticated via radius, so the user needs to have 1> a radius access account 2> and the local system administration account

Once again .......overkill, but  than the average government wants overkill!

Now with strong crypto ciphers in the webvpn  portal, you can now protect a weaker access that might be vulnerable ( SSH )

Do you recall the past debian OpenSSH keys issues ?




Here's the ssl.root cfg

And just create a ssl vpns setting and a portal that has tunnel-mode and assign the group.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  *  * )=
        o 
       /  \