With FortiOS and this narrowed down the SSLVPN facilities, Fortinet offers two ways of handling incoming remote users connectivity. Either you'd come client-less and will be bound to the so called SSLVPN Web Portal or you'd have the FortiClient VPN Client installed (or the full FortiClient) and you'll reach the SSLVPN tunnel facility.
When configuring access for SSLVPN Web Portal mode, a few rules applies per default on FortiOS:
- The source IP address used by the FortiGate when accessing SSLVPN Web Portal is the IP address configured on the outgoing interface specified in the SSLVPN security policy.
- Once a user is authenticated and granted access to the Web Portal, the traffic from this user's session is not limited to the SSLVPN policy that was matched for authentication, and each flow generated by user X from group Y is matched against:
- the destination interface of SSLVPN policies
- the schedule of SSLVPN policies
- the service of SSLVPN policies
- the group of SSLVPN policies
Now that we've got a few rules on which to abide, let me show you a simple multi vDOMs based FortiGate setup and its intended behaviors:
In this scheme, let's assume that we would like to differentiate both, the SSLVPN Tunnel based connections as well as the SSLVPN Web Portal based connections. Furthermore, we would like to allow different Users/Users Groups in order to provide fine grained controlled access to resources.
For example, SSLVPN-Tunnel-OT users group would only be able to access their duties targeted systems seated within the vOT vDOM and this through tunnel mode. Same principles would apply to SSLVPN-WebPortal-IT users group (vIT) although from the Web Portal only and so on. However, we would like to give differentiated access according to the connection type; Tunnel or Web Portal.
In the example provided above, our SSLVPN concentrator is listening for inbound connectivity requests on a dedicated Loopback Interface within vRA vDOM and the traffic granting policies and vIP objects at vWAN & vRA vDOMs are already in place:
While this whole setup is linked together via EMAC-vLANs, we can see that our vWAN vDOM knows where to address requests towards 172.16.99.244 via an OSPF learned routing.
Below is our SSLVPN settings in our vRA vDOM:
As shown above, I'm using realms in order to differentiate connectivity. The default Realm is used here for the SSLVPN Web Portal access while the tunnel Realm is used for the SSLVPN tunneling with fat client connectivity.
For the purpose of this lab, the users setup is fairly simple and handled locally on the FortiGate. Nevertheless, a shift to more enterprise scalable user management and authentication systems like FortiAuthenticator would be a simple process.
Let me remind you our SSLVPN Web Portal default behaviors; users connecting through a client-less connection won't be attributed an internal IP. While in Web Portal mode, user sessions will be matched according the present ssl.vRA firewall policies and if matched, it's traffic will be source NAT'ed toward the policies outbound interface per default.
In this setup, this is a clear no go. The outbound interface for any SSLVPN traffic will always be my vRA vDOM EMAC-vLAN interface. Interface which is my linking point to all the present vDOMs and only path to reach anything beyond vRA itself. In this setup on vRA vDOM bound to the IP 10.99.99.244.
We do not want any productive traffic coming from or NAT'ed to our EMAC-vLAN IPs.
After some testings and a good remote session with a close friend, we could come up with a solution involving IP Range objects and IP Pools objects as well. Here is an overall view of the SSLVPN policies in place within vRA vDOM:
As seen above, we first sequence the Web Portal based policies, they will match 1st upon Web Portal based users policy matching process. Note as well the usage of the IP Ranges within "Source" - this will avoid the use of our EMAC-vLAN outbound IP as well as match the SSLVPN facility used, Web Portal or Tunnel
combined with our usage matching Source NAT IP Pool object.
The “ARP Reply” setting will force the FortiGate to answer ARP requests for these IP addresses. This is intended here on our Web Portal IP Pool, we want our vRA vDOM to ARP reply on this particular IP pool range in order for traffic to come back to our Web Portal based users.
Of course, both the SSLVPN IP Ranges are present in our routing tables and propagated through OSPF throughout the setup vDOMs (see the routing table entry from vWAN vDOM above - NET 10.10.143/10.10.144). These are static entries injected within vRA and redistributed through OSPF.
Finally, here is a short view of the granularity possible within each vDOMs towards SSLVPN inbound sessions (here seen from within the vOT vDOM). Currently both SSLVPN facilities have the same access, although as seen below, you could restrict Web Portal users to a few targeted hosts or vice versa.
Policies are shown here without Security Profiles although you're free to setup any of them and apply them according to your needs (AV/IPS/APPCONTROL/SSL Interception/WF...) and either apply those in the vRA vDOM or in the targeted vDOM inbound policies. I'd go for the 1st choice, closer to the traffic source.
A few screen shots of our results. Our "ot-user" connected through a fat client:
An ssh session to an OT vDOM terminated Linux host from a Tunnel based connection:
And finally, another ssh session this time from our Web Portal facility:
As seen above, we have successfully mapped different subnets to both our available SSLVPN facilities and can now narrow down what any users could do within both of the provided SSLVPN schemes. Thus, forcing the Source NAT on our Web Portal users to our will & avoiding the use of the EMAC-vLAN IP as our Source NAT IP for the Web Portal facility.
One point to note here is that Web Portal based SSLVPN connectivity can be resources hungry, plan your needs according to this Fortinet KB.
In the hope you found this article useful.
Thanks for the read, special thanks to LB on this one...
Cheers,
Obuno
Image credit: The Twentieth Century Fox Film Corporation, Ad Astra, 2019