*Note – Just did this on a 300D running 5.6.2 code. CPU was running at 100% and the SSL VPN process was the culprit. The connection status would stall at 40%, then quit at 75%. Killing the process with the notes below worked great. Also, I am pretty sure that their is a reference in release notes of 5.6.2 about CPU going crazy due to a bug.
If the Mem goes to high, and the device drops to conserv mode. The SSL VPN may stop working correctly, or at all.
A quick reboot of the firewall will fix this issue, but restarting the VPN process will also fix it (given the mem dropped). You can also restart any process with these commands.
To restart the process:
get system performance top – to get the process ID (PID) of the SSL VPN
Looks like the PID of sslvpnd – 81
Next, we will kill the process with the kill command and use the level 11 – which restarts the process.
the command: dia sys kill <level> <PID>
dia sys kill 11 81
If you do the get sys per top command again, you will notice that the sslvpnd process now has a different PID.
I kept getting the error: Fatal: Received unexpected end-of-file from server
I googled for this a long time, and nothing. So a good answer: This meant that the flash was full, and there was not enough room to save the file. I removed the old images, and copied this one just fine.
Recently I and others have had an issue when using interface based VPNs on Fortigate, and remote Ruckus APs are on the other side of the VPN. For some reason these APs cannot register with the ZD – sometimes they never even show up. I can log into the remote APs, SSH, Web, Ping everything works they will just not register with the ZD.
When I see this the most the client has just updated to Fortinet 5.2 firmware, and is using Interface based VPNs instead of policy based.
Now back to the main goal of the entry – If you are using a interface based VPN with Fortinet specifically you might see your APs come up for a while, then drop. Another symptom I have seen is that you have your DHCP options, and DNS record set for the Zonedirector but the APs never show up. The underlying issue is that the interface based VPN will drop sometimes – the Fortigate may not even report the drop. During this time the the Logical VPN interface is no longer attached to the Fortigate, that means the route you set to push traffic over it to the remote subnet no longer exists. So a UDP session is opened to the internet – since there is no other place to send the traffic to. Once that happens the UDP stays active – Even though it should timeout.
So to fix the issue, Add a service for “Ruckus services” and add UDP and TCP ports 12223, and UDP and TCP port 12222. Then create a policy in the firewall to block traffic going to the WAN on those ports. This will make sure that remote sessions are never created to the internet interface. So if the tunnel drops you will not have to worry about this. You could also just create an address object for your remote subnet and create a policy blocking any traffic matching that object going to the WAN interface.
Here is the policy to block the traffic from leaving the WAN interface
Note – Make sure this policy is above any traffic that would be go from internal – to VPN.
After the policy is created to blog those ports – lets clear the sessions in the firewall. We can do this using the CLI command in the Fortigate:
Dia system session clear
So how did we figure this out? If you do a packet capture on the Fortigate matching the ZD or AP ip addresses, you will see registration attempts trying to go through the WAN interface, even though the VPN is up. Since UDP is connectionless, it never expects a response on the session, so it stays up. If you see the session going through your WAN interface, and your VPN is up, just kill that session. You will see your AP come up very quickly, but the same issue will happen if you don’t make sure the session is never created.
This has fixed the issue for a few clients having this problem.
First off the best documentation can be found at docs.fortinet.com
Fortigate has changed a lot in 5.2, one of the things that has been changed heavily is how to setup the SSL VPN. Some of the ways it has changed:
– Portal creation
– Settings
– Firewall policies (for interfaces)
So to enable and create needed policies for the SSL VPN to function we will create a scope 10.99.255.0/24 for our VPN subnet, and make sure our two local networks are being sent to the clients routing table VIA Split tunneling – our local subnets 10.32.250.0/24 and 10.32.251.0/24.
First lets create the address object for our SSL VPN clients
Portal Config
In the portal we can configure Split tunnel, IP Pools, bookmarks etc.
You also have options to save the password and the allow more than one instance of that user to login.
VPN Settings
Then we will start to configure settings for our VPN. Notice that it is much different than 5.0. We configure the port, VPN client addresses and who can access the VPN from here. Before it was in many different places. Also notice at the bottom there is the users who can log into this device, and what portal they will see. You can totally customize this so that domain admins get one portal and restricted users get another.
You will see that after you configure what is needed, there is a red line that comes up and says “default users not configured” if you only have one profile then modify this. If you have multiple portals then add the most specific first, then make the standard catch all this profile.
Firewall Policies
Next we need to create firewall policies to allow traffic to and from our VPN. This is also a big change from 5.0 where you would need to create a default WAN-LAN policy and have the service be SSL, here that is really done in the vpn-settings page.
So lets allow VPN traffic to our LAN and make sure we are using the network address objects that are specified in the Split tunnel policy under the portal. Adding the local subnets basically allows VPN clients to have access to those networks. You could use Any here, I chose to use my local subnets.
Then create the opposite of that policy to allow traffic from the lan to access the SSL VPN interface.
One more thing is needed – We need a route to that SSL VPN subnet.
That should be pretty much it. There are some considerations that should always be taken into account. For one, always evaluate the security that you need. In this example I did not add any UTM or restrictions to who can access the VPN, and to what servers/addresses. Something else – Notice that in the VPN-Settings page, if you are doing Forticlient registration, you need to make sure that option is checked so registration can be used on that interface. One of the other things to think about is the amount of time users stay logged into the VPN.
Apple Caching server is a very cool idea. I am not a big apple fan, so I don’t know exactly how it works. From what I have seen, you install the software on a server. Apple servers cache apps and files that many devices will ask for, therefore when one user downloads a file it caches it on the local servers. When another user coming from the same public IP address downloads that same file, it pulls it from the caching server thus eliminating the bandwidth need.
But how do you make sure Apple caching is working correctly in your network. By default everything should flow out of your default nat policy – but what if you have a bunch of different nats?
you want to make sure that your caching server and clients are seen by apple as the same IP address.
I do this this through a internal to wan policy and make sure that anything going to 17.0.0.0/8 (apple owns this whole block) and anything going to .apple.com goes out of the same policy.
you can do this with a Address object, and firewall policy to go out via that policy.
I run into this problem a lot. Someone has created a vlan on a cisco device by using the command –
int vlan 100
ip add 192.168.100.1 255.255.255.0
no shut
But nothing with the vlan is working after this. If you do a “show ip int br” does it shown int vlan 100 down? If so there are two causes to this.
The first is the vlan created? This is the most common problem I see.
Newer versions of firmware create the vlan when you create the interface, but older IOS did not. So even though you create the interface, you have not created the corresponding vlan yet.
You can diagnose this by – “show vlan br” – do you see the vlan?
You can create the vlan with the commands
config t
vlan 100
Cause 2 – there are no ports/trunks in the Vlan. The Vlan interface will not come up if there are no ports with up/up status associated with that vlan. Trunk ports that have up/up status will bring up all vlans that are allowed to go through the trunk. By default that is all vlans.
Steps needed to add a users, set up SSH authentication to point to Local database, and enable SSH on the outside interface.
config t
username Admin password password privilege 15
aaa authentication ssh console LOCAL
For telnet –
aaa authentication telnet console LOCAL
ssh outside 0.0.0.0 0.0.0.0 outside – Enables SSH from anywhere in the world – I would recommend only enabling SSH for networks that you need, for example your home network, or home ISP network.
The other day I had to configure a Static nat entry on a 8.2 ASA. It had been a while since I had done this since almost everything I work with is 8.3 and above. I thought I would make an entry for myself and maybe to help someone along the way.
Example – I have public IP 1.1.1.10 and I need to forward in port 443 to my internal server of 192.168.1.10. I have an access-list Outside-IN applied to my outside interface. Note if the 1.1.1.10 is my outside interface IP (lets say I have only one public IP) then we would use the interface key word
The Pac file can be used with the Explicit proxy of the Fortigate. The PAC file uses Java Script to modify the Explicit proxy to be able to do certain things. For example, if you do not want to use the proxy when going to certain websites/networks, or return different proxies. By returning different proxies you could theoretically load balance requests. I am using this pac file at a school where we proxy all Students Ipad traffic back to the fortigate for web filtering/logging.
The PAC function is FindProxyForURL(url, host). There are a number of functions available – A few are:
dnsDomainis() – Returns the domain name of the requested server
isNET() – This function will return true if the host is in the subnet you are specifying.
For example – (isInNet(host, “192.168.0.0”, “255.240.0.0”)) return “DIRECT”; – This would not proxy traffic for anything on the 192.168.0.0/16 subnet.
shExpmatch() – This will evaluate the URL you enter, and compare with the request. So for example
if (shExpMatch(host, “*.google.com”)) {return “DIRECT”;} – This would not proxy traffic goig to google.com
Below is an example of a Fortinet PAC file to bypass the proxy to many websites (return Direct) otherwise return the proxy.
—————
function FindProxyForURL(url, host) {
if (shExpMatch(host, “*.akadns.net”)) {return “DIRECT”;} if (shExpMatch(host, “*.akamai.net”)) {return “DIRECT”;} if (shExpMatch(host, “*.akamaiedge.net”)) {return “DIRECT”;} if (shExpMatch(host, “*.akamaihd.net”)) {return “DIRECT”;} if (shExpMatch(host, “*.amazon.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.amazonaws.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.apple.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.dropbox.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.edim.co”)) {return “DIRECT”;} if (shExpMatch(host, “*.edmodo.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.icloud.com”)) {return “DIRECT”;} if (shExpMatch(host, “*.ket.org”)) {return “DIRECT”;}
if (isInNet(dnsResolve(host), “10.11.0.0”, “255.255.0.0”)) { return “DIRECT”; — if the server is in my local subnet } if (isInNet(dnsResolve(host), “10.44.0.0”, “255.255.0.0”)) { return “DIRECT”; — or this subnet } else{ return “PROXY example:8888; PROXY example2:8888”; } }
Recent Comments