Fortigate Fortios 5.0 SSL VPN Configuration
Posted by on March 21, 2014
The best information available for anything fortinet is always found at docs.fortinet.com. This entry will show the needed steps to create a SSL VPN via the web interface.
Creating the SSL VPN has many working parts that come together to make one of the best Remote access VPNs out there. In this example we are creating a Split tunnel VPN, and enabling Tunnel mode.
The SSL VPN is one of the best features of the device, it has an open license, so you can have as many people connect as the device hardware supports. No crazy licensing for SSL VPN as with Cisco and Sonicwall. You can also utilize the VPN to get select information to users based on their AD security group. For example if you have a business with users traveling all the time, you might have a certain portal for one group of users and have their internal bookmarks and file shares, and completely different portal for office staff users. Another great benifit is in the protocol itself, SSL is almost never blocked by outbound firewall policies. A lot of companies (hotels, hospitals) and educational institutions block IPSEC from leaving the network which stops your remote access VPN from connecting.
Steps:
1. Create Address object for SSL Subnet and Internal networks
2. Create route for new subnet
3. Create Users/User group for user authentication
4. Config the VPN Portal
5. Config the VPN settings
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
1. Create Address object for SSL Subnet and Internal networks
We will create an address object with the Subnet of our SSL VPN clients. I would recommend using a crazy private IP subnet as to not conflict with Home/work local subnets.
Then we need to create another object for our Protected subnet. This is our internal network that we want the remote user to be able to access. If there are multiple subnets it might be better to add an address object group.
2. Create route for new VPN subnet
Since the SSL VPN is a “interface” we will route our subnet across of it. Notice our device is ssl.root, and that removes our needed gateway.
3. Create Users/User group for user authentication
There are many different ways to configure authentication within the device. You can authenticate VPN users against LDAP, Radius, or local accounts. In this example I am just using local accounts, but using LDAP or Radius is a much better option. You can use just individual users, or groups to authenticate to within the VPN policy. I would go ahead and create a User group so that you can add any local, radius, or ldap users into it in the future.
I am creating a user group call SSL_VPN and in this case its just local. If I wanted to add a LDAP/Radius server to authenticate against, I could just add the remote server. If I wanted to get even more specific and say authenticate against a security group within LDAP I would just modify the remote server portion of the user group to add that.
4. Config the VPN Portal
The portal is the landing page of the SSL VPN. It is a great place to add book marks, shortcuts for RDP, or info for users. For example, we have an internal sharepoint site for users, by placing a link on the portal, users they just have to click and Whola, instant access. This is great because installing the VPN client which allows tunnel mode requires admin access to the PC. If a user is traveling or at a hotel they might not have this access. Other great uses are RDP session, and file shares. Both will launch in a Java applet window and allow you access to RDP/SMB.
We are using the “Full-access” Portal, this is just a name. I added the IP Pool for the clients to get tunnel addresses. You can customize the page to any specification. A note, you can also fully edit your VPN login page to reflect your company logo, etc. You can do this by adding in the feature under system – admin- features and enabling it.
5. Config the VPN settings
The VPN settings consists of the IP pool, Port used, encryption strength, and of course DNS/WINs servers. If you want to push your domain name so that DNS will resolve to this interface, its a CLI command. I will do another entry on it.
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
This is where we actually allow access from the internet to our VPN portal. It is also where we specify our Protected subnets, which are the subnets injected into the clients routing table. You can also specify what portal certain users will see. For example, if you had a group of teachers who needed to get to the Teacher portal, and an admins group that needs to have a different portal and ACL to get to all servers.
Notice we select VPN as type, then incoming interface. The Local protected subnets are what we are pushing into the routing table of our client.
Next create an new Authentication policy.
From here select your user group that we created earlier, if you want individual users select those as well. You can also enable UTM if you feel its needed.
Now just save all the settings
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
For the last step we need to create policies to allow traffic in both directions. By default all traffic is blocked between interfaces int he firewall. The SSL VPN is an interface, so we need to allow traffic to it.
Just create a policy with Source interface being ssl.root, and allow all traffic to your LAN (or however you see is best to secure) and then another policy from LAN to ssl.root.
Thats it! There are some optional configs dealing with Certs on both sides, and much stronger encryption methods.
Notes*
If you have a MPLS, or DMZ interface where you need VPN clients to access you will have to create another VPN policy going from WAN to – DMZ, or WAN to MPLS and just mirror the WAN-to-lan SSL VPN policy. You will also have to modify the protected subnets with that interfaces network. If anyone has trouble with this feel comment and I will explain better.
On top of that you will need to create more ssl.root to DMZ and DMZ to ssl.root policies to allow access between the interfaces.
Hallo,
I have trouble with ssl vpn. I havel multiple ssl portals and I have multiple policy witch ssl vpn.
When I connect via ssl vpn I get ip address 10.28.32.1 and I split route
10.28.1.0/24 via 10.28.32.1 dev ppp0
Ping to address 10.28.1.1 is OK:
$ ping 10.28.1.1
PING 10.28.1.1 (10.28.1.1) 56(84) bytes of data.
64 bytes from 10.28.1.1: icmp_seq=1 ttl=249 time=11.1 ms
64 bytes from 10.28.1.1: icmp_seq=2 ttl=249 time=6.13 ms
64 bytes from 10.28.1.1: icmp_seq=3 ttl=249 time=19.1 ms
But this traffic is translated by fortigate to address of internal interface:
# diag debug flow show console enable
show trace messages on console
# diag debug flow trace start 100
# diag debug enable
# id=13 trace_id=23 msg=”vd-CUST received a packet(proto=1, 10.28.32.1:26621->10.28.1.1:8) from ssl.CUST. code=8, type=0, id=26621, seq=1.”
id=13 trace_id=23 msg=”allocate a new session-008266b4″
id=13 trace_id=23 msg=”find a route: flags=00000000 gw-172.21.1.1 via internal”
id=13 trace_id=23 msg=”use addr/intf hash, len=3″
id=13 trace_id=23 msg=”find SNAT: IP-172.21.1.254, port-62464″
id=13 trace_id=23 msg=”Allowed by Policy-50: SNAT”
id=13 trace_id=23 msg=”SNAT 10.28.32.1->172.21.1.254:62464″
I do not understand, why fortigate translate this traffic?
# diagnose sniffer packet any ‘host 10.28.1.1’ 4
interfaces=[any]
filters=[host 10.28.1.1]
2.421885 ssl.CUST in 10.28.32.1 -> 10.28.1.1: icmp: echo request
2.422775 internal out 172.21.1.254 -> 10.28.1.1: icmp: echo request
2.427052 internal in 10.28.1.1 -> 172.21.1.254: icmp: echo reply
2.427159 ssl.CUST out 10.28.1.1 -> 10.28.32.1: icmp: echo reply
# config firewall policy
(50) # show
config firewall policy
edit 50
set srcintf “wan1_CUST”
set dstintf “internal”
set srcaddr “all”
set dstaddr “LAN_net-BRANCH”
set action ssl-vpn
set identity-based enable
config identity-based-policy
edit 1
set schedule “always”
set utm-status enable
set groups “Bilina_static”
set users “test”
set service “ALL”
set sslvpn-portal “VPN_IP_BRANCH”
set av-profile “default”
set ips-sensor “default”
set application-list “default”
set profile-protocol-options “default”
next
end
next
Hi Hobitt, I would love to give you a hand at resolving this. I noticed you said it was coming from interface ppp0. I am not for sure if this would be correct. My skype is justin.cottrell7. Add me and we can get this resolved.
Also, I see that you have your wan-lan SSL VPN policy, great. But I do not see a Internal to SSL.Root, and the policy SSL.Root to internal.
Hy cjcott01, I fixed it. You had right.
There was missing the policy from SSL. to internal. I added it.
Now the traffic from ssl vpn going through fortigate without NAT.
I had to add policy
edit 58
set srcintf “ssl.CUST”
set dstintf “internal”
set srcaddr “VPN_IP_BRANCH”
set dstaddr “LAN_net-BRANCH”
set action accept
set schedule “always”
set service “ALL”
next
I do not understand why fortigate must have two policy for this traffic? Both policy are similar:
When th epolicy 58 there isn’t, the traffic is NATed and traffic matched by policy id 50.
If added the policy id 58 the traffic is not NATed and matched by policy id 58.
This behavior is schizophrenic. :-)))
By Default (in most firewalls, and Fortigate) all traffic between interfaces is blocked. The SSL.Root is a logical interface. So, even though WAN-Lan sets up VPN, the SSL.Root interface has to have policies allowing traffic.
5.2 restructures this, and actually you only create Firewall policies to allow traffic. Makes things a little simpler. Let me know if I can help with anything else.
Hi cjcott01
I have followed your instructions but I can’t get the DNS to work.
The user can log in but when they try and access the internal Sharepoint by its name it fails.
But if you use the internal IP address it works.
Any ideas?
Are you using the portal? All dns from the portal is proxied by the FW. Are all settings under – system- network – dns correct?
Be glad to help get this resolved. We can do a remote screenshare.
Thanks cjcott01
It was the system DNS not pointing to an internal DNS server. Working now!
So the DNS settings in the SSL – Config will be for Tunnel mode then?
That is correct. The portal uses the same DNS as the firewall because it proxys all of the requests. In Tunnel mode you can send any DNS server or domain you want to, because it is a fully separate adapter on the clients pc. A cool option is enabling the DNS server on the fortigate, and doing DNS Doctoring for requests coming inside.
Is this article for Web VPN Portal or for use with Forticlient? thanks