I needed to have a specific SSL VPN client to always have the same IP address. This is not overly simple as it seems it should be. I have read there are very neat ways to do it through FortiAuth, or Radius options – but Here I am just doing all Fortigate configuration.
I am using a local account on the firewall in this example, but it would work with an AD users without issues – you would just have to map the user directly and not use groups.
SO, in this example I have a Scan gun that needs to have a specific IP every time it connects. So an overview of the steps are:
Setup SSL VPN (Should be already done if you are trying this).
Have LDAP or Radius integration already setup if you are specifically using that.
Setup Address object that you need the device to get – For this example 10.200.253.241.
Create a user object either local, or LDAP/Radius. – In this example Bargun01.
Create a specific portal if needed just for this user.
Create group/portal matching in SSL Settings.
Create firewall policy allowing that client in.
Ok, first lets create our address object .
Next lets create our user object – We need to do a specific user object, because we only want one device to be logged in and match this policy.
Then lets create the portal specific for this device – which only needs access to one server. In this portal we will match the it to the individual IP object we created, and set the remote access server it needs. Notice that the source IP Pool is the specific IP we set – this is where all the real magic is.
Next lets match up our user to the portal.
One more thing to do – and that’s to setup our firewall policy! Notice that the user matches what we put in the portal. Very specific. That’s it.
I have been working with Fortigate for a long time now, one thing that bugged the life out of me (and most clients I work with) is that Fortigate’s SSL VPN feature would not allow you to specify certain settings per portal or group. For example DNS servers and Domain suffixes. Most firewall/router vendors have been able to do this for years and with no problem.
Starting in firmware 5.2.2 you can now specify individual DNS servers per portal! That’s right, if I have two different domains using the SSL VPN and I specify individual user groups and portals, now I can give each side their own specific DNS servers.
The DNS setting per portal is CLI only as of firmware 5.5.5 – I see this changing in future firmwares (Still has not changed in 5.4.1 either) . The modification is under the VPN – SSL – Web portal options. You can also specify individual WINS servers. This entry is written for someone who already has the SSL VPN up and working. Something to note is that these portal settings override the global DNS settings configured under
config vpn ssl web portal
edit “Sales-Portal” set tunnel-mode enable set ip-pools “VPN-Pool” set split-tunneling-routing-address “SSL-VPN-ROUTES” set dns-server1 10.60.134.5 —DNS Server 1 , Overrides global config set dns-server2 10.60.134.6 — DNS Server 2 , Overrides global config next
And there we have it! We then can of course associate the portal with a certain group of users, so for example Domain 1 get Domain 1’s server and same for Domain 2.
You can use a different IP address to answer for the SSL VPN.
Lets say that your interface IP (The default IP address that is used with the SSL VPN) already has HTTPS (443) forwarded in to a internal server, and you really want the SSL VPN port to be 443. You have an option.
You can add a secondary IP address under the WAN interface that does not have a reservation already for 443. Then use this IP address for the SSL VPN.
To do so:
Add your secondary IP address – Note this has to be a public address, given to you by your ISP..
Then go into the VPN settings and modify the port for what you want. Notice that the address it says will work is still the primary IP, even though the secondary will work just fine.
Anyconnect along with webvpn is Cisco’s SSL VPN and portal. It works great.
This is my homegrown template for implementing the Anyconnect VPN. There are somethings to note with it. 1. You need to update your VPN client for the OS you need from Cisco. I know there were many issues with Windows 8, and they all seem to be fixed with the new client. 2. This Template works great on 8.3 and above. The steps are made to work with a pretty vanilla config. If you already have a bunch of config it might take some tweaking to work with your other settings.
I will paste the whole config at the bottom of the entry and you can just copy, rename things and paste in. So, lets review what is needed to get anyconnect up and working, and what these parts actually do.
If anyone has anything to contribute feel free to comment.
1. So, lets create the subnets we want for our VPN. I am choosing to use 10.253.241.0/24 for my “Anyconnect” profile. I like to use objects my networks because you can reference them throughout your config and its a great way to keep organized. object network Anyconnect-Subnet subnet 10.253.241.0 255.255.255.0 object network Internal-Lan subnet 10.1.10.0 255.255.255.0
This created my Internal subnet, and Anyconnect Subnet.
2. Create a IP pool for your subnet (Remember, you can have multiple pools if you need to have multiple Groups/Portals)
.ip local pool Anyconnect-VPN-Pool 10.253.241.10-10.253.241.100 mask 255.255.255.0
3. I want to use split tunnel for my VPN users, so I will create an ACL for my internal LAN. Applying this will make any subnet in the ACL get pushed to the clients routing table. This means that only the needed subnets come across the VPN.
access-list Split-Tunnel standard permit 10.1.10.0 255.255.255.0
Speaking of the Split tunnel ACL, you could do a group in the ACL and if you add a lot of networks in your organization you could just drop the new network in the group and everything would get updated dynamically.
Next lets configure the Webvpn options. WebVPN? Whats that, weren’t we configuring Anyconnect? Well true, Anyconnect and WebVPN are completley different. Webvpn is the https://portal that you logged into. By logging into this page you can give the client links/bookmarks to internal resource, and give them a platform to download the Anyconnect client. Anyconnect is the actual VPN client that connects the user to internal resources. So lets get our Webvpn enabled and select the image we want to use. In this case its the newest windows image. Also note – I have the login page show the tunnel groups that are enabled. If I had multiple groups – lets say one for Traveling salesman and one for Internal Employees, each might have different bookmarks/links , different IP subnets, and different resources they are allowed to get to.
4. Now lets create the Group policy to use for our Anyconnect session. A Group Policy is “is a set of user-oriented attribute/value pairs for IPSec/SSL connections that are stored either internally (locally) on the device or externally on a RADIUS or LDAP server. A tunnel group uses a group policy that sets terms for user connections after the tunnel is established. ” – From Cisco. The Group policy allows use to specify a lot of settings that any tunnel using the GP will get. For example DNS servers, and the Split-Tunnel policy. group-policy Anyconnect internal group-policy Anyconnect attributes dns-server value 10.1.10.5 8.8.8.8 vpn-tunnel-protocol ssl-client ssl-clientless split-tunnel-policy tunnelspecified split-tunnel-network-list value Split-Tunnel
5. Next we will configure the Tunnel-group for this network. Tunnel groups contain a small number of attributes that pertain to creating the tunnel itself. Tunnel groups include a pointer to a group policy that defines user-oriented attributes. Some of these attributes are the DHCP Pool, what kind of encryption , etc.
The Fortigate SSL is an amazing feature, but when users do not log in that often to any internal resources their AD password may expire and the user will not know. What really stinks is if that user has to post data for the month, and logs in at midnight for an 8 a.m. deadline! Luckily Fortigate has the ability to push the LDAP password expiration notification to the user, and can even let them change the password through SSL VPN login.
Steps:
– Get SSL VPN up and going with LDAP Authentication – This has to be an LDAPS connection to change the password, and your account to query LDAP has to be a domain admin!!!
– In CLI modify the LDAP server to allow password expiration notification, and change.
First create or modify your LDAP server in the GUI, and make sure its set to use LDAPS. The image below should be a good guide. Remember, the service account you use to query LDAP does not have to be an admin account, but if you want to change passwords then it does have to be a Domain-Admin. A good idea is to always create a service account to use for the Fortinet to query LDAP. That way if your admin password changes it will not affect this this account.
After that is configured, and tests/querys successfully then lets drop down to CLI and get the following configured.
Config user ldap
edit “Server name”
set password-expiry-warning enable
set password-renewal enable
end
For a look at all the options see picture below:
And that’s it, after this LDAP will push those messages to the client when they log in.
Remember, that the LDAP connection has to use SSL (LDAPS) to change the password.
After setting up a SSL VPN tunnel, one of the biggest complaints I get is “I cannot get to my shares”. This is because the Domain suffix has not been pushed out to their tunnel interface. This is easy to remedy, but seems to be in CLI only.
Within cli you have many options under the ssl vpn config that are not presented in the GUI.
You can edit the VPN tunnel with the command:
config vpn ssl settings
Here are a list of all the settings:
as you can see, the dns-suffix is an option, as well as DNS servers.
The Suffix option is not presented in the GUI, but the dns servers are.
The command to set the suffix is:
set dns-suffix corp.local
end
Make sure your DNS servers are also set for your internal network and it should now work without a problem.
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.
Recent Comments